经过亚马逊等公司十多年的实践,蓝绿是一种经过验证且安全的持续软件部署方法。

您的用户是否曾因发布错误而导致停机?您是否曾在周末被要求回滚升级?您是否通常必须在疯狂的时间醒来,因为那是您唯一可以关闭系统的时间?发布日会让你感到焦虑吗?

如果是这样,那没关系——你并不孤单——但不必如此。许多方法可以帮助我们进行安全部署,而无需停机或维护窗口。其中一种方法称为_blue-green_(或_blue/green_),这就是我们今天要学习的内容。

什么是蓝绿部署?

蓝绿部署是一种发布管理技术,可以降低风险并最大限度地减少停机时间。它使用两个生产环境(称为蓝色和绿色)来提供可靠的测试、持续的无中断升级和即时回滚。

蓝绿部署的起源

故事开始于 2005 年左右,有两个开发人员和一个问题。他们正在开发的电子商务网站出现了许多意想不到的错误。这些开发人员一丝不苟,并且有一个很好的测试套件,但由于某种原因,错误在雷达下飞行并进入生产阶段。整个情况给他们的客户带来了很多麻烦。

经过更深入的检查,他们找到了原因。他们注意到生产机器和测试机器之间存在太多差异。他们的测试在测试环境中通过,但代码在生产中部署时失败。

这些开发人员Daniel North 和 Jez Humble提出了一个非常规但绝妙的想法。他们将直接在生产中进行部署和测试。

现在我知道你在想什么。在生产中进行测试不是一个很大的禁忌吗?通常,是的。但是你看,这里的关键点是他们没有_覆盖_旧网站。相反,他们在同一个物理盒子中_并排_运行新的,因此用户不知道正在进行的部署。旧网站继续照常工作,而 Dan 和 Jez 则致力于发布。

部署是这样工作的。他们将包含最新版本的文件夹复制到生产机器中。然后他们使用一个单独的域启动了这个网站,并在那里进行了冒烟测试。一旦他们感到高兴,他们就会将 Apache Web 服务器指向新文件夹,收工,然后大概喝一杯啤酒。如果有任何问题,他们可以将 Web 服务器指向旧文件夹,修复错误,然后重试。这种策略极大地改进了错误检测,因为测试和生产环境现在是相同的。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--lR4cpPW_--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev- to-uploads.s3.amazonaws.com/i/xqgeq93km2z6f66z5ebp.png)

此时,他们在同一台机器上有两个环境:一个用于旧版本,另一个用于新版本。最初,他们想用字母来称呼它们:environment A、environment B 等等。但有人指出,人们倾向于认为 A 在某种程度上比 B 更好(也许这听起来太像“B 计划”)。他们最终决定使用没有自然顺序的颜色。因此,他们计划使用 blue、green 或 orange 之类的名称(他们避免使用 red,因为这意味着危险)。最后,事实证明他们只需要两个环境。于是蓝绿这个词就被创造出来了。

蓝绿部署如何工作?

有一些我们稍后将探讨的注意事项,蓝绿色几乎检查了所有框以获得理想的部署过程:

• 无缝:用户不应经历任何停机时间。

• 安全:失败的可能性很小。

• 完全可逆:我们可以撤消更改而不会产生不利影响。

蓝绿方法的基础是并行部署。为此,我们需要两个_独立但相同_的环境。我的意思是最一般的_环境_,包括服务器、虚拟机、容器、配置、数据库等等。有时我们可以使用不同的盒子。其他时候,我们可以使用在相同硬件上运行的单独虚拟机。或者它们可以是在单个设备中运行的不同容器。

以最纯粹的形式,蓝绿色要求我们复制应用程序所依赖的每一个资源。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--FKfYClxz--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev- to-uploads.s3.amazonaws.com/i/4hnrjwip7xi0jy29fp8x.png)

然而,在实践中,运行所有内容的备用副本并不总是有意义的。例如,让两个数据库保持同步非常困难。出于这个原因,我们经常发现具有共享组件的蓝绿色部署。

我们还需要一些在两个环境之间切换传入连接的方法。我们将用一个路由器符号来表示它。它可以是一个实际的路由器、一个负载平衡器、一个反向代理,或者像原来的情况一样,是一个 Web 服务器。

[](https://res.cloudinary.com/practicaldev/image/fetch/s---hGYn6oQ--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev -to-uploads.s3.amazonaws.com/i/7n3hr8spfa1mg0nfnse7.png)

蓝色和绿色轮流扮演生产角色。在任何给定时间,只有一个环境处于活动状态。比如说,蓝色是活跃的。在这种情况下,它会接收所有流量——同时,绿色充当一个暂存区,我们可以在其中部署和测试下一个版本。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--xdXr_7JO--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws .com/i/0ufjgni7cybbqyj5hehn.png)

一旦我们确保以绿色运行的版本运行良好,我们将切换路线。然后循环再次开始。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--Ue-ZRPc8--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev- to-uploads.s3.amazonaws.com/i/jotky1ftmvr6uaqelfmd.png)

一旦用户切换到绿色运行的新版本,部署就完成了

云让蓝绿部署更可行

始终保持两组环境运行可能会很昂贵。幸运的是,我们有许多工具可以让我们按需启动和拆除基础设施。我们可以使用 infrastructure as code (IaC) 平台(如 Ansible 或 Terraform)启动和停止服务器。我们可以使用容器简化发布,或者使用 Kubernetes 编排部署。令人惊讶的是,当我们将云提供的灵活性和成本降低考虑在内时,蓝绿部署触手可及。

云将大部分基础设施抽象出来。我们可以将部署描述为一系列松散耦合的组件。

!【云中蓝色生产环境】(https://res.cloudinary.com/practicaldev/image/fetch/s--FwmlR4al--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://开发到上传.s3.amazonaws.com/i/8gjrpj3z5g29dftxhriw.png)

当需要发布新版本时,我们会在不触及实时环境的情况下创建新资源。在实践中,我们将使用CI/CD工具(如Semaphore)来创建相同的新组件并进行部署。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--OCEpRdTb--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https:// /dev-to-uploads.s3.amazonaws.com/i/9ce4ioinxblespw1c39j.png)

然后我们一次重新路由所有用户连接。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--8oqr20xO--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880 /https://dev-to-uploads.s3.amazonaws.com/i/05ldys65n3s3v4bs2v1x.png)

一旦部署完成并且我们感到满意,我们就可以废弃旧环境。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--ywRFCrZR--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/ https://dev-to-uploads.s3.amazonaws.com/i/hwkf4wi83icxdt5uqs04.png)

让蓝绿变得非常简单的一项技术是 Kubernetes。要了解更多信息并查看实际的 Kubernetes 部署,请免费获取我们的电子书:CI/CD with Docker and Kubernetes。

谁可以从蓝绿部署中受益?

当我们需要时,蓝绿色是一个很好的解决方案:

• Uptime:当我们无法关闭系统来更新它时。

• 准确测试:当需要更可靠和准确的测试时。

• Reliability:当我们想要提高部署的可靠性时。

要使用蓝绿部署,我们需要做一些事情:

• 自动化:我们需要个持续交付管道来自动化供应、部署和测试过程。

• 测试:我们需要详尽的测试。我们将依靠他们来决定何时准备好发布版本。我们应该使用持续集成快速捕捉错误并在上线之前测试新版本。

• 隔离:我们需要两个相同且独立的环境。否则,一种环境可能会影响另一种环境。

每个人都可以做蓝绿部署吗?并非总是如此,某些情况可能会阻止我们使用该方法:

• 什么时候,在任何情况下,我们都无法进行持续更新。

• 当法规限制必须如何更新软件时。例如,在航空航天、电信或医疗行业。

• 当我们不能有两个相同的环境时。

• 当我们无法隔离环境时。

• 由于基础设施的原因,我们无法使用路由器、负载均衡器或反向代理。

• 当我们有破坏性的数据库架构更改时。数据库更改需要向前和向后兼容。

蓝绿部署的优点

那么,蓝绿部署策略适合您吗?要回答这个问题,我们必须比较它的优缺点。

让我们从专业人士开始:

• 测试奇偶校验:这是功能。测试平价意味着测试真正反映了生产的现实。这就是 Dan 和 Jez 在设计蓝绿色时所寻找的。通过在相同的硬件和软件上运行测试,它们使它们变得更有用和更有意义。

• 随时部署:无停机意味着我们可以随时发布。无需等待维护窗口。

• 即时切换:用户立即切换到新版本,或几乎如此。每个人都会同时看到最新版本。

• 即时回滚:切换双向工作。如果我们决定回到以前的版本,我们可以立即将所有用户切换回来。

• 热备:蓝绿色可以将我们从灾难场景中拯救出来。假设一个数据中心离线,导致现场环境下降。没什么大不了的,我们将切换到另一个,直到问题得到解决。只要我们采取预防措施,不要将蓝色和绿色放在同一可用区,这将起作用。

• 事后分析:就地部署很难调试失败的版本。当面临停机时,首要任务始终是恢复正常。收集调试数据是次要的,因此在回滚过程中可能会丢失很多有价值的信息。 Blue-green 不会遇到这个问题——回滚总是让失败的部署保持完整以供分析。

蓝绿部署的缺点

在这一点上,您可能会认为蓝绿色必须有一个陷阱。否则,每个可能会使用它的人。因此,让我们检查一下缺点:

• 冷启动:用户突然切换到新环境时可能会遇到缓慢的情况。此外,此时可能会出现任何未检测到的性能问题。热身工作和压力测试可以缓解这些问题。

• 成本:与其他方法相比,蓝绿部署更昂贵。按需配置基础设施会有所帮助。但是,当我们每天进行多次横向扩展部署时,成本可能会滚雪球。

• 时间:设置蓝绿部署过程需要时间和精力。过程复杂,责任重大。在让它正常工作之前,我们可能需要进行多次迭代。

• 数据库:数据库迁移更难,甚至到了成为一个大人物的地步。数据库模式更改必须向前和向后兼容。我们可能需要在新旧版本之间来回移动。当我们有两个数据库时,问题变得更加复杂,一个用于蓝色,一个用于绿色。保持数据同步是一件痛苦的事情。处理此问题的常用策略包括使用复制或将一个数据库设为只读。

• 用户交易:割接期间,部分用户交易会被中断。我们必须仔细考虑如何处理它们。我们应该如何处理半应用事务?我们是否会显示错误消息并告诉用户重试?还是我们尝试将它们带到新环境中?一种可能的解决方案是将所有事务同时并行地提供给两个环境。在这种情况下,我们需要在部署完成后处理任何重复的数据。

• 共享服务:数据库和其他共享服务可能会在蓝色和绿色之间泄漏信息。我们在这里需要谨慎,否则一个环境可能会间接影响另一个环境。这可能会破坏隔离规则并干扰部署。

如您所见,蓝绿与传统的就地部署相比有很多优势,但也有一些缺点。有些人不喜欢全有或全无的方法,而更喜欢使用金丝雀版本,它结合了蓝绿和就地部署的元素,并提供更渐进的过渡。您可以在我们的免费电子书CI/CD with Docker and Kubernetes中阅读有关金丝雀部署的所有信息。

在哪里了解更多

我们已经了解了蓝绿部署是什么、它们是如何形成的以及它们解决的问题。我希望这篇文章可以帮助您确定蓝绿部署策略是否适合您。

通过这些帖子了解更多部署软件的方法:

• 我们正在编写一份蓝绿色的 Kubernetes 分步指南。不要错过!订阅我们的时事通讯,我们会在发布后立即通知您。

• Kubernetes 部署:终极指南

• 持续集成、持续部署和持续交付有什么区别?

更多永不停止学习的资源:

[

](/巫师)[

持续集成和交付到 AWS Kubernetes

Tomas Fernandez ・ 2019 年 10 月 11 日 ・ 7 分钟阅读

#kubernetes #aws #devops #tutorial

](/semaphore/continuous-integration-and-delivery-to-aws-kubernetes-12d6)

[

](/巫师)[

Docker 和 Java Spring Boot[Part.1:持续集成]

Tomas Fernandez ・ 20 年 1 月 22 日 ・ 5 分钟阅读

#java #docker #devops #microservices

](/semaphore/docker-and-java-spring-boot-part-1-continuous-integration-1mfl)

[

](/巫师)[

Kubernetes 和 Java Spring Boot[Part.2:持续部署]

Tomas Fernandez ・ 20 年 1 月 30 日 ・ 8 分钟阅读

#kubernetes #java #devops #docker

](/semaphore/kubernetes-and-java-spring-boot-part-2-continuous-deployment-47l9)

[

](/巫师)[

10 分钟## 个谷歌云 Kubernetes

Tomas Fernandez ・ 2019 年 11 月 14 日 ・ 10 分钟阅读

#kubernetes #devops #productivity #tutorial

](/semaphore/google-cloud-kubernetes-in-10-minutes-2enb)

谢谢阅读!