共计 5776 个字符，预计需要花费 15 分钟才能阅读完成。
本篇内容主要讲解“docker 如何创建持续部署流水线”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让丸趣 TV 小编来带大家学习“docker 如何创建持续部署流水线”吧!
创建持续部署流水线
我们已经创建好了测试环境，在前文中我们也构建好了 CI 流水线，由它来创建应用、将应用打包进容器、进行集成测试。现在我们将来到本系列文章的最终章，拓展 CI 流水线来创建一个持续部署流水线。
发布 Docker 镜像
我们首先将打包的镜像发布到 Docker 存储库中。方便起见，我们使用了一个公共 DockerHub 仓库，不过，对于实际的开发项目，我们还是建议将 Docker 镜像 push 到私有库中。下面我们在 Jenkins 中创建一个新的 Free Style Project 任务，点击 New Item 按钮，把任务命名为 push-go-auth-image。完成了这些步骤后，你会进入到 Jenkins 任务配置页面，在这里你可以定义 push 你的 go-auth 镜像到 Dockerhub 所需要的步骤。
因为这是我们对前一章中构建的流水线的后续，因此该作业会有和 go-auth-integration-test 作业类似的配置。你需要首先设置的是 parameterized build 并且添加 GO_AUTH_VERSION 变量。
要 push 镜像，我们选择 Add build step 下拉菜单，然后选择 Execute shell 选项。在结果文本框中添加下面的命令。在这些命令中，我们将登陆到 DockerHub，并且 push 我们之前构建好的镜像。这里我们准备将其 push 到 usman/go-auth 仓库中，而你则需要把它推送到自己的 DockerHub 库中。
上一章提到，我们使用的是 git-flow 分支模型，其所有的功能分支都合并到“开发”分支中。为了能够不断地将发生的变更部署到集成环境中，我们需要一个简单的机制来生成基于开发分支的最新镜像。在打包过程中，我们使用 GO_AUTH_VERSION 来标记 docker 容器（例如，docker build -t usman/go-auth:${GO_AUTH_VERSION} ….）。在默认情况下，这个版本将会成为开发分支，但是本章后面我们将为我们的应用程序创建新发布，使用 CI/CD 流水线来构建、打包、测试，并把它们部署到我们的集成环境中。要注意的是，在这个方案中，我们总会覆盖我们开发分支的镜像（usman/go-auth:develop），这限制了我们引用历史构建以及执行回滚。你可以对流水线做一个简单的更改，把 Jenkins 构建编号添加到自身的版本名称上，比如 usman/go-auth:develop-14。
你需要指定你的 DockerHub 用户名、密码和电子邮件地址。你可以在每次运行时用参数构建的方式指定它们，也可以使用 Jenkins Mask Passwords Plugin 在主要的 Jenkins 配置中安全地定义它们，并将它们添加到构建中。要确保 Build Environment 中为你的作业启用了“Mask passwords（并且启用全局密码）”。
现在我们需要确保这个作业是在集成测试作业之后才触发的。要做到这一点，我们需要更新集成测试作业，以便使用当前的构建参数触发参数化构建。这意味着在每次成功运行集成测试作业后，我们会把测试好的镜像 push 到 DockerHub 上。
最后，我们需要在镜像成功 push 到 DockerHub 之后触发部署作业。就像我们为其他作业所做的一样，我们可以通过添加构建后操作来实现这一点。
部署到集成环境
我们将使用 Rancher Compose CLI 来停止运行的环境，从 DockerHub 获取最新的镜像，并重新启动环境（提醒一下，Updates API 还在发展，可能会发生变化。未来几周或者几个月内肯定会增加新的功能，因此请随时查看文档是否有更新项）。在我们创建 Jenkins 作业来实现持续部署之前，我们先手动完成这些步骤。
我们可以使用最简单的方法——停止所有服务（auth 服务、负载均衡器以及 mysql），提取最新的镜像并启动所有服务。然而，对于我们来说，我们只想更新应用程序，而并不想停止长时间运行的环境，这样就不太理想了。要更新我们的应用程序，我们首先要停止 auth-service。你可以在 Rancher Compose 使用 stop 命令完成操作。
这会停止运行 goauth 服务的所有容器，你可以在 Rancher UI 中打开堆栈来验证该服务的状态是否设置为 Inactive（不活跃）。接下来，我们要让 Rancher 拉取我们想要部署的镜像版本。现在，我们已经可以动态指定想要运行的版本，而无需每次都要更新模板了。如果你需要多次 push 相同的镜像版本，请添加 pull 开关，确保我们使用的是镜像版本的最新副本。
我们还可以通过下面的命令使用升级功能，零停机地实现环境的滚动更新。下一节中我们将进一步讨论滚动更新。在升级完成后，你可以使 –rollbach 命令或 –confirm-upgrade 来确认更改或者回滚到预览状态。
现在我们已经知道该如何运行我们的更新，我们在流水线中创建一个 Jenkins 作业来执行此操作。和之前一样，创建一个新的 freestyle 项目，命名为 deploy-integration。与其他的作业一样，它也是一个参数化构建，用 GO_AUTH_VERSION 作为字符串参数。接下来，我们要从上游的 build-go-auth 作业中复制工件。
最后，我们需要向 Execute Sheell 构建步骤中添加 Rancher Compose up 命令，这是我们在之前指定好的。需要注意，你还需要提前在 Jenkins 上设置 Rancher CLI，让它可以用于你在系统路径上的构建。执行 shell 步骤的内容和下面的代码片段相似。如果你有多个 Rancher Compose 节点，负载均衡器容器可能会在不同的主机上启动，你的 Route 53 记录集合就可能需要更新。
有了我们两个新的 Jenkins 作业，我们从上一章就开始构建的流水线现在看起来就像下图所示。每次对我们示例应用程序的 check-in 都会被编译，确保其没有出现语法错误并且能够通过自动化测试。然后，将这些变更打包，通过集成测试，最后再部署到手动测试中。下面的五个步骤为构建流水线提供了一个良好的基线模板，并且有助于将代码从开发阶段转移到测试和部署阶段上。拥有一个连续的部署流水线确保了代码不仅可以进过自动化系统的测试，而且还能快速提供给测试人员使用。除此之外它还能够作为生产部署自动化的模型，测试操作工具和代码，持续部署应用程序。
发布和部署一个新的版本
在我们将代码部署到持续的可测试环境中后，我们就会让 QA 团队测试对这些变更进行一段时间的测试。在他们确定代码已经就绪后，我们可以创建一个发布，随后将它部署到生产环境中。用 git-flow 发布的方式类似于特征分支（我们在前一章讨论过的工作方式），我们使用 gitflow release start [Release Name] 命令（如下所示）进行发布。这将创建一个新的名称来发布分支。在这个分支中，我们将执行一些内部的操作，比如增加版本号，做最后的修改。
完成这些后，我们运行 releasefinish 命令将发布分支合并到主分支中。这样，主分支总能反映出最新发布的代码。另外，每个发布都会加上标签，对每个发布的内容都能够有历史记录。如果我们不需要再进行其他的更改，我们就可以确定最终的发布了。
最后一步就是把发布 push 到远端仓库中
git push origin master git push –tags //pushes the v1 tag to remote repository
如果你使用的是 Github 来托管 git 库，现在应该会发现有一个新的版本了。我们还可以将与发布名称相匹配的版本镜像 push 到 DockerHub，这也是一个不错的选择。我们先运行第一项作业来触发我们的 CD 流水线。可能你还记得，我们为 CI 流水线设置了 GitParameter 插件，以便能够从 git 中获取与过滤器相匹配的所有标记。不过，这是对于默认的开发分支而言，当我们手动触发流水线时，我们可以从 git 标签中进行选择。例如，在下面我们为应用程序提供了两个版本。我们选择其中一个，启动集成和部署流水线。
然后，经过以下步骤，我们的应用程序 1.1 版本将会被部署到长时间运行的集成环境中，只需要点击几下就能实现。
从 git 中获取所选的发布
构建应用程序，运行单元测试
创建一个带有标签 v1.1 的新镜像（比如 usman/go-auth:v1.1）
运行集成测试
Push 镜像（usman/go-auth:v1.1）到 DockerHub
将该版本部署到我们的集成环境
部署策略
管理长时间运行的环境时会遇到很多挑战，其中之一就是尽可能在发布期间的停机时间要降至最短，最好为零。为了让这个过程可预测并且安全，需要做相当多的工作。自动化和质量保证确实可以大大提高发布的可预测性和安全性。不过即使是这样，失败也会发生，而且对任何优秀的运维团队来说，他们的目标都是在最小化影响的同时快速恢复。在本节中，我们将介绍一些部署长时间运行环境的策略以及它们的优缺点。
就地更新
第一个策略称为就地更新（In-placeupdates），顾名思义，它的思想就是复用应用程序环境，并且就地更新应用程序。这有时也称作是滚动部署。我们将使用我们目前讨论的示例应用程序（go-auth）。此外，我们假定你有用 Rancher 运行的服务。如果要就地更新，你可以使用下面的升级命令：
在用户看不到的地方，Rancher agent 会在每个运行 auth 服务容器的主机上获取新的镜像（–pull 会重新下载，尽管镜像已经存在）。之后代理会停止旧的容器，批量启动新的容器。你可以使用 –batch-size 标志来控制批处理的大小。此外，你还可以指定批更新之间的暂停时间间隔（–interval），使用足够大的时间间隔来验证新容器的行为是否按照预期运行，并且总体而言，服务是健康的。在默认情况下，旧的容器终止后，新的容器会在它们的位置上启动。或者你可以在 rancher-compose.yml 中设置 start_first 标志，告诉 Rancher 在启动新容器之前先停止旧容器。
如果对当前的更新不满意想要回滚，可以使用回滚标志来完成回滚。或者你想要继续进行更新，只需告诉 rancher 指定 confirm-update 标志完成更新即可。你也可以在原始的 up 命令中指定 confirm-update 标志一步完成这些操作。你还可以在 RancherUI 执行更新，从服务菜单（下图所示）中选择“upgrade”。
就地更新非常简单，不需要额外的资源来管理多个堆栈。然而，这种生产方式是存在缺点的。首先，对回滚更新进行细粒度控制大多很困难，就是说在故障发生的情况下它们往往是难以估计的。例如，处理部分故障和滚动更新会变得非常混乱。你需要知道在哪些节点上部署了更改，哪些没能部署，还有哪些仍在运行之前的版本。其次，你还需要保证所有的更新不仅是向后兼容，还能向前兼容，因为旧版本和新版本都是需要在相同的环境中同时运行的。最后，根据使用的情况，就地更新可能不实用。比如，如果老的客户端需要继续使用旧环境，而新的客户端需要向前滚。在这种情况下，使用我们今天要列出的方法分离客户端会更加容易。
蓝绿部署
就地更新的一个问题是缺少可预测性。为了克服这一问题，另一个部署策略是针对应用程序使用两个并行堆栈：一个处于活跃状态，另一个处于待机状态。要运行新版本，部署应用程序的最新版本到待机堆栈。当验证到新版本需要工作，将会从活动堆栈切换流量到备用堆栈上。这时，先前活跃的堆栈称为备用堆栈，反之亦然。该策略允许验证已经部署的代码、快速回滚（切换备用和重新激活），并还可以在需要时扩展两个堆栈的并发操作。这种策略通常被称为蓝绿部署。用我们的示例应用程序完成这样的部署，可以简单地在 Rancher 中创建两个堆栈：go-auth-blue 和 go-auth-green。此外，我们假设数据库不是这些堆栈的一部分，而是独立管理的。每个堆栈都会运行 goauth 和 auth-lb 服务。如果假设 go-auth-green 堆栈式活跃的，要执行更新，我们要做的就是将最新版本部署到蓝色堆栈中，执行验证并将流量切换到它这。
流量切换
有两个方法可用于执行流量切换，更改 DNS 记录来指向新堆栈，或者使用代理或负载均衡器，将流量路由到活动堆栈。下面我们会详细介绍这两个方法。
记录更新
一个简单的方法是更新 DNS 记录指向活动堆栈。这种方法的一个优点是，我们可以使用加权 DNS 记录将流量慢慢转换到新版本中。这也是执行 canary releases 的简单方法，对安全地在实时环境中进行更新或者做 A / B 测试非常有用。例如，我们可以将实验性的功能更部署到自己的功能堆栈（或活动堆栈），然后更新 DNS，仅将一小部分流量转发到新版本。如果新更新出现问题，我们可以逆转 DNS 记录回滚回来。此外，他比将所有流量从一个堆栈切换到另一个堆栈要安全得多，因为这样会覆盖掉新的堆栈。虽然简单，如果你希望所有流量能一次切换到新版本，DNS 记录更新就把 u 事最简洁的方法。根据 DNS 客户端不同，这些更改可能需要很长时间才能传播，从而导致和旧版本之间的大量通信，而不是直接了断切换。
使用反向代理
使用代理或负载均衡器，只需要将其更新成指向新堆栈就可以一次切换整个流量。这种方法在各种场景下都非常有用，例如非向后兼容的更新。要使用 Rancher 完成这一操作，我们首先要创建一个仅包含负载均衡器的堆栈。
接着，我们为负载均衡器指定一个端口，配置 SSL 并从下拉菜单中选择活动堆栈的负载均衡器作为 target service 来完成创建。本质上来说，我们将负载放到了负载均衡器上，它会在之后将流量路由到实际的服务节点。借助外部负载均衡器，你不需要更新每个版本的 DNS 记录。相反，你可以简单地更新外部负载均衡器指向已更新的堆栈。
到此，相信大家对“docker 如何创建持续部署流水线”有了更深的了解，不妨来实际操作一番吧！这里是丸趣 TV 网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
