金丝雀部署 蓝绿部署_丰富多彩的部署：蓝绿色，金丝雀和滚动部署简介

金丝雀部署 蓝绿部署

在当今快节奏的世界中，使用持续集成和持续部署 （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值，以轻松识别应用程序的蓝色版本。

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

 # 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 数据兼容性 ，这适用于本文稍后部分讨论的所有策略。

金丝雀部署

Canary旨在以较小的增量步骤来部署应用程序，并且仅将其部署给一小部分人。 有几种可能的方法，最简单的方法是仅向新应用程序提供一定比例的流量（我将在OpenShift中演示如何做到），以提供更复杂的解决方案，例如功能切换 。 功能切换可让您根据特定条件（例如，性别，年龄，原籍国）来控制对某些功能的访问。 我知道，最先进的功能切换功能Gatekeeper是在Facebook上实现的。

^{金丝雀部署}

让我们尝试使用OpenShift实施canary部署。 首先，我们需要创建我们的应用程序。 同样，我们将为此使用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 

该应用程序的较新版本（称为canary）将类似地部署，但仅具有单个实例：

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 

我们要验证新版本的应用程序在“生产”环境中是否正常运行。 需要注意的是，我们只想向少量客户公开它（例如，收集反馈）。 为此，我们需要以这样一种方式配置路由，即只有一小部分传入流量被转发到应用程序的较新（canary）版本：

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控制台，在将少量流量发送到Canary版本后路由预览}

注意：在您部署了多少个副本与针对每个版本的流量百分比之间存在联系。 由于部署前的服务与路由划分结合用作负载平衡器，因此可以为您提供应用程序将获得的实际流量。 在我们的情况下，约为1.5％。

这种方法的最大优点是功能切换，特别是当您具有一个可以选择金丝雀部署的目标组时。 结合良好的用户行为分析工具，您将获得有关正在考虑向更广泛的受众部署的新功能的良好反馈。 与蓝绿色部署一样，canary遭受N-1数据兼容性的困扰，因为在任何时候我们都在运行多个版本的应用程序。

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

滚动部署

滚动部署是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个实例，尽管与具有相同环境的蓝绿色需求相比，它更容易实现。

结论

最后，我将给出最好的建议：没有一种适合所有人的方法。 充分理解方法和替代选项很重要。

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

最后，尽管我的文章仅着眼于这些策略中的每一个，但将它们组合起来以拥有最适合您的应用程序以及您所采用的组织和流程的最佳解决方案并没有错。

我将在俄勒冈州波特兰市的PyCon 2017（5月17日至25日）在PyCon 2017（3月17日至3月）上进行为时 3小时的研讨会（ 在Kubernetes / OpenShift中有效运行Python应用程序）中介绍此主题。

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

翻译自: https://opensource.com/article/17/5/colorful-deployments

金丝雀部署 蓝绿部署