一旦团队实施了软件解决方案，就该查看该特定软件的运行情况了。要查看运行中的软件，您基本上需要在最终用户可用的环境中安装和运行该软件。这样的过程称为部署。

部署涉及很多事情。过去，只需将二进制文件复制到某个地方并运行它，可能会使用 FTP 服务器和 SSH 会话。

正如我们在本书前面所描述的，软件在语言、功能、功能和集成点方面发生了巨大变化。所有软件都使用各种协议和系统进行连接。因此，部署一个软件已经成为一个复杂的过程。

今天，特别是在微服务时代，软件分布在云端，每个组件都需要与其他组件交互；这意味着二进制文件的快速而肮脏的复制和粘贴不再是一个有效的选择。

软件需要灵活、适应业务变化、一致、可靠和高性能，并且需要快速响应新的业务需求。因此，软件必须没有错误，在将其部署到生产环境之前，您需要确保它从功能和基础架构的角度都可以正常工作，它与所涉及的其他系统完美集成，并且可以由 DevOps 团队管理。测试是成功的关键，管理整个过程的适当平台是强制性的。

如您所见，部署一段代码是一个复杂的过程，但幸运的是，您可以遵循许多工具和模式来自动化整个过程并确保您的软件没有错误。

幸运的是，我们有 OpenShift，它是管理此类流程的正确平台，利用容器部署中的微服务。

在本章中，我们将介绍以下主题：

• Continuous integration and continuous delivery
• Blue-green deployment
• Canary deployment
• A/B testing deployment
• Rolling deployment

持续集成 (CI) 和 持续交付 (CD)（最终部署）是用于构建、打包和部署您的应用。

这是描述 CI/CD 流程的图表：

本质上，开发团队将源代码提交到版本控制系统——希望是 GitHub 存储库； CI 工具会轮询最新版本的代码并构建应用程序。

构建还涉及单元测试和集成测试。有不同的框架可用于单元测试和集成测试。当然，这取决于您的运行时环境。例如，在 Java 中，您可以分别依赖 JUnit 和 Arquillian 进行单元测试和集成测试。

构建阶段还包括质量代码检查、发现反模式、优化、覆盖率、样式等。

一旦您通过测试获得绿灯，您实际上可以将您的应用程序发布到您的第一个环境，大部分时间是开发/测试。

通常，环境是开发、测试、用户验收测试(UAT)、预生产和生产。但这实际上取决于组织在成本控制和政策方面的情况。

但是，只要您拥有测试、UAT 和生产环境，您就有足够的环境来管理部署的生命周期。

正如您所想象的那样，CI 是您的应用程序被构建、测试和打包的阶段（无论包格式是什么——Web 应用程序、二进制文件、容器等等）。这个阶段事实上的标准工具是 Jenkins。

第一张 CD 代表持续交付，是您将最终工件交付到环境的阶段。持续意味着你的工件被交付，即从一个环境到另一个环境，直到预生产环境，或者至少在生产前的最后一个环境，然后需要手动升级——通常是经理批准部署到生产环境。

同样，Jenkins 在这个阶段提供了帮助，因为它可以通过依赖管道直接将应用程序从一个环境推广到另一个环境。

最后一张 CD 代表持续部署，它与持续交付完全相同，只是工件一旦构建，就会以自动化的方式直接从第一阶段环境提升到生产环境。

选择哪一种取决于哪一种适合您的组织。

但是，部署过程有四个黄金法则：

• Build the final artifact only once: What needs to be deployed from environment to environment must be exactly the same thing. To achieve such goals easily, OpenShift relies on Jenkins.
• Keep deployment the same: Always deploy in the same manner for each environment. Less configuration, better automation, less risk.
• Test, test, and test: Testing is essential for CI and CD. Testing must be part of the deployment process.
• Similar environments: Environments should differ only in terms of available resources. All software stack layers should be the same to minimize any differences that could eventually impact the stability and misconfiguration of your system. Clean and safe. Here as well, container technology is a godsend.

在以下部分中，我们将研究为不同目的部署应用程序的不同方法。

蓝绿部署是一种用于减少部署新版本应用程序的停机时间的技术。 Martin Fowler 在 2010 年初在他的网站 https://martinfowler.com/bliki/BlueGreenDeployment 上描述了这种技术.html。以下是从这个网站上摘录的一段话：

这是蓝绿部署的逻辑架构：

蓝绿部署的关键是要有一个能够按需从蓝环境切换到绿环境的路由或负载均衡器：

这肯定会带来一些好处，例如零停机时间和随时可用的回滚环境。另一方面，这个新环境在会话应用方面也将焕然一新，因此所有用户会话都将丢失。为了减轻这种损失，将应用程序设置为只读模式可能会有所帮助，或者等待所有会话耗尽。

但是，蓝绿部署是关于测试生产环境，而不是测试应用程序本身，这应该在测试和/或 UAT 中完成。

让我们用一个例子来尝试一个蓝绿部署：

1. First of all, if you don't have your OpenShift platform up and running, start it as follows:

oc cluster up

2. Once everything has started, open your browser and point it to https://127.0.0.1:8443/console/.

3. Log in as developer, and click on the Nginx icon in Browse Catalog, as follows:

4. In the pop-up wizard, click Next and fill in the next form, as shown in the following screenshot:

5. In the last step, the platform confirms the creation of the application, which is already being deployed in your project.

6. Click on the link labeled Continue to the project overview to see its overview and progress:

7. Once the application has been successfully deployed in the platform as a container in a pod, click on the route stating http://blue-green-app-myproject.127.0.0.1.nip.io, which should load our example application.

该页面应以蓝色显示一些文本，如下所示：

8. To simulate our new version of the application, and thus simulate a switch between the two versions—the blue (the one we just deployed) and the green (the one we are about to deploy)—go back to the catalog and select the Nginx icon, and click Next in the pop-up wizard.
9. This time, click on the Advanced options link and fill in the form, as follows:

与之前的部署不同，当然是名称，即blue-green-app-2。此外，部署现在指向我们的 Git 存储库的名为 green 的分支，因此我们不会为我们的应用程序自动创建路由。

这样，应用程序就不会暴露在外部。但是，如果不共享路由，用户将不会知道新 URL，但由于这是一项自动化任务，因此 URL 可以根据应用程序名称进行预测，好奇的用户可能会破坏您的新功能。出于这个原因，我们将禁用自动路由创建：

10. Once the application has been deployed, we can test how it behaves in the new environment, and once we are satisfied, we can proceed with the switchover.

为此，我们点击左侧的垂直菜单 Applications | Routes 然后点击名为 blue-green-app 的路由。

我们现在应该看到路线的详细信息，如下所示：

11. On the page, in the top-right corner, there is a drill-down menu called Actions; click on it and select Edit.

在 Edit 页面上，我们更改了路由的所有设置，甚至是指向的服务层，这是我们需要更改才能从蓝色环境切换的服务层到绿色环境，如以下屏幕截图所示：

12. Then, click Save, and refresh the page of our application. We should now see the web page displaying some text in green, as follows:

您当前应用程序的 URL 没有改变，新的精美版本终于上线了。

恭喜！您成功执行了蓝绿部署。

请记住，如果两个版本之间的数据模型发生了细微的变化，那么蓝绿部署应该以不同的方式完成，即将应用程序的蓝色版本设置为只读模式并等待它耗尽所有待处理的写入请求，然后切换到新的绿色版本。

Canary 部署是一种用于逐渐增加新版本应用程序负载的技术。

Danilo Sato 在 2014 年初描述了这种技术，Martin Fowler 的网站 https://martinfowler 对此进行了报道。 com/bliki/CanaryRelease.html。以下是从这个网站上摘录的一段话：

这是金丝雀部署的逻辑架构：

这里的关键点是缓慢增加应用程序的负载并监控其行为。这个过程可能需要几个小时或几天；这取决于您想要多快，以及您的用户需要适应这些新变化的时间。

从 OpenShift 的角度来看，蓝绿部署示例中所做的仍然有效。因此，如果您没有遵循 蓝绿部署 部分，请这样做，然后继续执行这些新说明：

1. In My Project, in the left-hand sidebar, click on Applications | Route and select the route named blue-green-app.
2. In the top-right corner of the page, click on the drill-down menu named Actions and select Edit.

向下滚动到页面底部，并启用 Split traffic across multiple services 在 Alternate Services 部分中的复选框， 如下：

3. Set Service to blue-green-app, set the Service Weights so that 10% of the load goes to blue-green-app-2 and that the 90% of the load goes to blue-green-app, and click the Save button at the bottom of the page.

路由页面现在应该以图形方式显示流量是如何划分的，如下所示：

4. Try to reload our page 10 times. If you see the page with green text once, you successfully performed a canary deployment.

一旦审计和监控工具满足您的组织需求，您可以逐渐增加负载，直到完全推出，这意味着只有 green 版本在线.

A/B 测试部署是一种用于测试应用程序功能的技术。

这意味着 A/B 测试适用于引入新界面或改变应用程序外观的前端应用程序。用户的反馈非常重要，因此直接在生产中进行是您可以拥有的最佳测试环境。用户的反应可以显示您所做的更改是否直观，您最终可以根据反馈调整您的软件。

从 OpenShift 的角度来看，这实际上与金丝雀部署相同，只是您将两个服务之间的权重分别设置为 50%：

所以，如果你没有遵循 第 8 章，微服务模式，请这样做，并为服务权重设置50%。

可以看到，在 OpenShift 中，实现这样的部署技术是非常容易的，因为它们都有路由组件为王。

滚动部署是一种用于逐渐用更新版本替换当前应用程序的技术。

这种部署技术可以让您在更新期间没有停机时间，但也要求您同时运行新旧版本的应用程序。这只有在数据模型兼容性的情况下才有可能。

以下是描述部署的开始、过程和最后阶段的三个图表。 首先，部署一个新版本应用的实例：

一旦应用程序的新版本可以使用，这意味着准备和健康检查成功通过，旧版本的一个实例将被安排销毁：

在最后阶段，一旦新版本应用程序的最后一个预期实例准备好使用，旧版本的最后一个实例就被销毁，只有新版本可用：

在本章中，我们介绍了您可以在 OpenShift 中采用的基本部署策略来部署微服务。

我们还描述了与 DevOps 相关的基本概念和用于通过环境发布软件的方法，使用 CI 和 CD，以及各种部署策略，如蓝绿、金丝雀、A/B 测试和滚动部署，描述了如何和何时使用最合适的技术。

在下一章中，我们将看到如何使用显示集群状态的指标来监控运行云原生微服务的平台。当然，监控部分将被 Prometheus 和 Grafana 等开源工具所利用。