彩色部署：蓝色-绿色、金丝雀和滚动部署简介

在当今快节奏的世界中，使用 持续集成 和 持续部署 (CI/CD) 工作流程似乎是保持软件测试和稳定性的唯一合理方法。大量文章介绍了 CI/CD 的基础知识，在本文中，我将重点解释如何在最新版本的 OpenShift 上实施三种流行的部署策略。为了配合本文，您可以从 GitHub 下载最新稳定版本的 OpenShift（在撰写本文时，我使用的是 1.5.0 rc0 版本）并运行

oc cluster up

第一次执行此操作会花费一些时间，因为它会下载运行 OpenShift 集群在本地计算机上所需的多个镜像。此操作完成后，您应该看到

$ oc cluster up
-- Checking OpenShift client ... OK
-- Checking Docker client ... OK
-- Checking Docker version ... OK
-- Checking for existing OpenShift container ... OK
-- Checking for openshift/origin:v1.5.0-rc.0 image ...
...
-- Server Information ...
   OpenShift server started.
   The server is accessible via web console at:
   	https://192.168.121.49:8443

   You are logged in as:
   	User: 	developer
   	Password: developer

   To login as administrator:
   	oc login -u system:admin

您可以使用上述凭据从命令行 (oc) 或从浏览器 (https://localhost:8443/) 访问您的集群。

蓝色-绿色部署

蓝色-绿色部署 简而言之，就是拥有两个相同的环境，前面有一个路由器或负载均衡器，允许您将流量定向到适当的环境

^{蓝色-绿色部署}

为了说明这种类型的部署，让我们创建九个蓝色应用程序的副本

# this command creates a deployment running 9 replicas of the specified image
oc run blue --image=openshift/hello-openshift --replicas=9 

# this sets the environment variable inside the deployment config
oc set env dc/blue RESPONSE="Hello from Blue" 

# this exposes the deployment internally in the cluster
oc expose dc/blue --port=8080

我们将使用 OpenShift 团队提供的 hello world 应用程序镜像。默认情况下，此镜像运行一个简单的 Web 服务器，返回“Hello world”文本，除非指定了 RESPONSE 环境变量，在这种情况下，将返回其值。因此，我们设置 RESPONSE 值以轻松识别我们的蓝色应用程序版本。

一旦应用程序启动并运行，我们必须将其对外公开。为此，我们将使用 路由，它也将在部署过程中用作我们应用程序两个不同版本之间的切换。

# this exposes the application to be available outside the cluster under 
# hello route
oc expose svc/blue --name=bluegreen 

现在是执行升级的时候了。我们必须创建一个与当前运行环境相同的环境。为了区分我们应用程序的两个版本，这次我们将 RESPONSE 设置为“Hello from Green”

oc run green --image=openshift/hello-openshift --replicas=9
oc set env dc/green RESPONSE="Hello from Green"
oc expose dc/green --port=8080

# this attaches green service under hello route, 
# created earlier but with the entire traffic coming to blue
oc set route-backends bluegreen blue=100 green=0 

我们的两个应用程序目前都在运行，但只有蓝色版本正在接收所有流量。同时，绿色版本将通过所有必要的测试（集成、端到端等）。当我们确信新版本运行正常时，我们可以拨动开关并将所有流量路由到绿色环境

oc set route-backends bluegreen blue=0 green=100

以上所有步骤都可以从 Web 控制台执行。以下是显示流量当前由绿色环境服务的屏幕截图

^{OpenShift Web 控制台，切换到绿色环境后的路由预览}

让我尝试总结一下蓝色-绿色部署策略。零停机时间是这种方法迄今为止最大的优势，因为切换几乎是瞬间完成的（这接近理想状态），使用户不会注意到他们的请求何时由新环境提供服务。不幸的是，与此同时，这可能会导致问题——由于从一台机器为流量提供服务物理切换到另一台机器，所有当前的事务和会话都将丢失。这绝对是在应用此方法时需要考虑的事情。

这种方法的另一个重要好处是测试在生产环境中执行。由于这种方法的性质，我们有一个完整的环境用于测试（再次，开发人员的理想世界），这使我们对应用程序按预期工作充满信心。在最坏的情况下，您可以轻松回滚到旧版本的应用程序。此策略的最后一个缺点是需要 N-1 数据兼容性，这适用于本文后面部分讨论的所有策略。

金丝雀部署

金丝雀 是关于以小的、增量的步骤部署应用程序，并且仅向一小部分人部署。有几种可能的方法，最简单的方法是仅将一部分流量发送到新应用程序（我将展示如何在 OpenShift 中执行此操作），更复杂的解决方案，例如 功能开关。功能开关允许您根据特定条件（例如，性别、年龄、原籍国）限制对某些功能的访问。我所知道的最先进的功能开关 gatekeeper 已在 Facebook 上实施。

^{金丝雀部署}

让我们尝试使用 OpenShift 实施金丝雀部署。首先，我们需要创建我们的应用程序。同样，我们将为此目的使用 hello-openshift 镜像

oc run prod --image=openshift/hello-openshift --replicas=9
oc set env dc/prod RESPONSE="Hello from Prod"
oc expose dc/prod --port=8080

我们需要公开我们的应用程序以便外部可以访问

oc expose svc/prod

较新版本的应用程序（称为金丝雀版本）的部署方式类似，但只有一个实例

oc run canary --image=openshift/hello-openshift
oc set env dc/canary RESPONSE="Hello from Canary"
oc expose dc/canary --port=8080
oc set route-backends prod prod=100 canary=0

我们想验证新版本的应用程序在我们的“生产”环境中是否正常工作。需要注意的是，我们只想将其暴露给少量客户端——例如，收集反馈。为此，我们需要配置路由，以便只有一小部分传入流量被转发到较新（金丝雀）版本的应用程序

oc set route-backends prod prod=90 canary=10

验证此新设置的最简单方法（如以下 OpenShift Web 控制台屏幕截图所示）是调用以下循环

while true; do curl http://prod-myproject.192.168.121.49.xip.io/; sleep .2; done

^{OpenShift Web 控制台，在将少量流量发送到金丝雀版本后的路由预览}

注意：您部署的副本数量与定向到每个版本的流量百分比之间存在关联。由于部署前面的服务充当负载均衡器并结合路由划分，因此这为您提供了应用程序将获得的实际流量。在我们的例子中，大约是 1.5%。

这种方法的最大优点是功能开关，特别是当您拥有一个允许您选择金丝雀部署的目标组的功能开关时。这与不错的用户行为分析工具相结合，将为您提供有关您正在考虑部署给更广泛受众的新功能的良好反馈。与蓝色-绿色部署一样，金丝雀部署也存在 N-1 数据兼容性问题，因为在任何时间点我们都在运行多个版本的应用程序。

没有任何东西阻止您在任何时间点拥有多个金丝雀部署。

滚动部署

滚动部署 是 OpenShift 中的默认部署策略。简而言之，此过程是关于用较新的实例缓慢替换当前正在运行的应用程序实例。以下动画最能说明此过程

^滚动部署

在左侧，我们有当前正在运行的应用程序版本。在右侧，我们有同一应用程序的较新版本。我们看到在任何时间点，我们都恰好有 N+1 个实例在运行。值得注意的是，只有当新的实例通过了 健康检查 后，旧的实例才会被删除。所有这些参数都可以在 OpenShift 的部署策略参数中轻松调整。

图 6. OpenShift Web 控制台中的滚动部署参数。

然后让我们创建我们的示例应用程序

oc run rolling --image=openshift/hello-openshift --replicas=9
oc expose dc/rolling --port 8080
oc expose svc/rolling

一旦应用程序启动并运行，我们就可以触发新的部署。为此，我们将通过设置环境变量来更改部署的配置，这将触发新的部署。这是因为默认情况下，所有部署都定义了 ConfigChange 触发器。

oc set env dc/rolling RESPONSE="Hello from new roll"

下面的屏幕截图是在滚动部署过程中拍摄的，但最好切换到 OpenShift 的 Web 控制台来查看实际过程

^{OpenShift Web 控制台中的滚动部署}

这种方法的主要优点包括增量推出和逐步验证应用程序，同时流量逐渐增加。另一方面，我们再次面临 N-1 兼容性问题，这对于所有持续部署方法来说都是一个主要问题。在执行此方法时，丢失的事务和用户注销也是需要考虑的事情。最后一个缺点是 N+1 实例要求，尽管与蓝色-绿色部署对拥有相同环境的需求相比，这更容易满足。

结论

我将以我得到的最好的建议来结束：没有一种万能的方法。充分理解该方法和替代方案非常重要。

此外，开发人员和运维团队在为您的应用程序选择正确的方法时密切合作非常重要。

最后，尽管我的文章侧重于单独介绍这些策略中的每一种，但将它们结合起来以获得最适合您的应用程序以及您的组织和您已到位的流程的最佳解决方案，这没有任何问题。

我将在我的三个小时的研讨会 在 Kubernetes/OpenShift 中有效运行 Python 应用程序 中介绍这个主题，该研讨会将在俄勒冈州波特兰的 PyCon 2017（5 月 17 日至 25 日） 举行。

如果您有任何问题或反馈，请在下面的评论中告诉我，或通过 Twitter 联系：@soltysh。