在当前快节奏的世界中,使用持续集成和持续部署(CI/CD) 工作流似乎是保持软件测试和稳定性领先的唯一合理方法。大量文章涵盖了 CI/CD 的基础知识,在本文中,我将重点介绍如何在最新版本的 OpenShift 上实施三种流行的部署策略。要继续阅读本文,您可以从 GitHub](https://github.com/openshift/origin/releases)下载 OpenShift[的最新稳定版本(在撰写本文时,我使用的是 1.5.0 rc0 版本)并运行:

oc cluster up

第一次这需要一些时间,因为它将下载在您的机器上本地运行 OpenShift 集群所需的多个映像。完成此操作后,您应该会看到:

$ oc 集群起来

-- 检查 OpenShift 客户端 ... OK

-- 检查 Docker 客户端 ... OK

-- 检查 Docker 版本... OK

-- 检查现有的 OpenShift 容器 ... OK

-- 检查 openshift/origin:v1.5.0-rc.0 图像 ...

...

-- 服务器信息...

OpenShift 服务器已启动。

该服务器可通过 Web 控制台访问:

https://192.168.121.49:8443

您登录为:

用户:开发者

密码:开发者

以管理员身份登录:

oc 登录 -u 系统:管理员

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

编程和开发

• 红帽开发者博客

• 编程备忘单

• 免费试用:红帽学习订阅

• 电子书:Bash 编程简介

• Bash Shell 脚本备忘单

• 电子书:企业 Java 现代化

蓝绿部署

蓝绿部署简而言之,就是关于拥有两个相同的环境,在这两个环境之前有一个路由器或负载均衡器,可以让您将流量引导到适当的环境:

_ 蓝绿部署 _

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

# 此命令创建一个运行指定映像的 9 个副本的部署

oc 运行蓝色 --image\u003dopenshift/hello-openshift --replicas\u003d9

# 这会在部署配置中设置环境变量

oc set env dc/blue RESPONSE\u003d"Hello from Blue"

# 这会在集群内部公开部署

oc 暴露 dc/blue --port\u003d8080

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

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

# 这会暴露应用程序在集群外部可用

# 你好路由

oc 暴露 svc/blue --name\u003dbluegreen

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

oc 运行绿色 --image\u003dopenshift/hello-openshift --replicas\u003d9

oc set env dc/green RESPONSE\u003d"Hello from Green"

oc 暴露 dc/green --port\u003d8080

# 这在 hello 路由下附加了绿色服务,

# 较早创建,但整个流量变为蓝色

oc set route-backends bluegreen blue\u003d100 green\u003d0

我们的两个应用程序当前都在运行,但只有蓝色获得了全部流量。与此同时,绿色版本通过了所有必要的测试(集成、端到端等)。当我们对新版本正常工作感到满意时,我们可以翻转开关,将整个流量路由到绿色环境:

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

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

OpenShift web 控制台,切换到绿色环境后的路由预览

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

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

金丝雀部署

Canary是关于以小的增量步骤部署应用程序,并且只针对一小群人。有几种可能的方法,最简单的是只为新应用程序提供一定比例的流量(我将展示如何在 OpenShift 中做到这一点),以及更复杂的解决方案,例如功能切换。功能切换允许您根据特定标准(例如,性别、年龄、原籍国)限制对某些功能的访问。我所知道的最高级的功能切换,网守是在 Facebook 实现的。

金丝雀部署

让我们尝试使用 OpenShift 实现金丝雀部署。首先我们需要创建我们的应用程序。我们将再次为此目的使用 hello-openshift 图像:

oc run prod --image\u003dopenshift/hello-openshift --replicas\u003d9

oc set env dc/prod RESPONSE\u003d"来自 Prod 的你好"

oc 暴露 dc/prod --port\u003d8080

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

oc expose svc/prod

应用程序的较新版本(称为 canary)将以类似方式部署,但只有单个实例:

oc 运行金丝雀 --image\u003dopenshift/hello-openshift

oc set env dc/canary RESPONSE\u003d"Hello from Canary"

oc 暴露 dc/canary --port\u003d8080

oc set route-backends prod prod\u003d100 canary\u003d0

我们想验证新版本的应用程序是否在我们的“生产”环境中正常工作。需要注意的是,我们只想将其公开给少量客户——例如收集反馈。为此,我们需要以这样一种方式配置路由,即只有一小部分传入流量被转发到应用程序的较新(金丝雀)版本:

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%。

这种方法的最大优势是功能切换,尤其是当您有一个允许您选择金丝雀部署的目标组时。这与体面的用户行为分析工具相结合,将为您提供有关您正在考虑部署给更广泛受众的新功能的良好反馈。与蓝绿部署一样,canary 也受到 N-1 数据兼容性的影响,因为在任何时候我们都在运行多个版本的应用程序。

没有什么可以阻止您在任何时间点进行多个金丝雀部署。

滚动部署

滚动部署是 OpenShift 中的默认部署策略。简而言之,这个过程是关于用较新的实例慢慢替换当前正在运行的应用程序实例。这个过程最好用下面的动画来说明:

滚动部署

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

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

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

oc 运行滚动 --image\u003dopenshift/hello-openshift --replicas\u003d9

oc 暴露 dc/rolling --port 8080

oc 暴露 svc/滚动

一旦应用程序启动并运行,我们就可以触发新的部署。为此,我们将通过设置环境变量来更改部署的配置,这应该会触发新的部署。这是因为默认情况下所有部署都定义了一个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。