蓝绿部署及其在 DevOps 中的作用解释

传统的“大爆炸”软件开发方法与当今云和 DevOps 软件平台的高灵活性、敏捷性和持续部署要求不兼容。

仅准备在生产发布部署期间执行的手动步骤清单是不够的。 如果你这样做，你就不是真正的敏捷者，也不是一个真正的 DevOps 者。

蓝绿部署：概述

蓝绿部署是一种软件部署方法，它通过创建两个相同的环境：活动（蓝色）和非活动（绿色）来减少停机时间和新软件版本的风险。

活动环境是当前版本的软件运行的地方，用户产生生产流量的地方。 非活动环境是部署和测试新版本软件的环境。

一旦新版本经过测试并准备就绪，流量就会从活动环境切换到非活动环境，使其成为新的活动环境。 您可以根据需要重复此过程。

来源： docs.aws.amazon.com

开发运营环境

蓝绿部署非常适合 DevOps 思维方式和流程，因为它支持软件的持续交付和部署，同时最大限度地减少生产用户的停机时间并消除生产发布失败的风险。

拥有两个相同的环境可以在不影响当前生产环境的情况下测试和部署新版本的软件。 这意味着更快、更频繁的发布，这是 DevOps 的一个关键方面。

此外，在环境之间快速切换流量的能力是出现问题时快速回滚的主要前提，这在 DevOps 环境中也很重要。

蓝绿部署的关键原则

#1. 两个相同的环境

蓝绿部署需要创建两个相同的环境。 这意味着从数据和流程的角度来看是相同的。 一个处于活动状态（蓝色），另一个处于非活动状态（绿色）。

蓝色环境是生产用户运行日常流程的地方。 绿色环境始终与蓝色环境同步，但测试人员在那里运行他们的测试用例。 即使此环境不是生产环境，您也可以在真实条件下运行测试，因为它是类似生产的环境。

#2. 流量开关

一旦新版本的软件经过测试并准备就绪，流量就会从活动环境切换到非活动环境，使其成为新的活动环境。

切换是即时的。 所有部署现在都已成为过去。 没有停机时间窗口。 用户无需执行任何操作即可到达新环境。 它们会同时自动重定向。

来源： aws.amazon.com

＃3。 快速回滚

在环境之间快速切换流量的能力还意味着出现问题时可以快速回滚。 这可确保最短的停机时间，并且应用程序保持高可用性。

如果绿色环境出现问题，所有用户都会立即切换回稳定的原始蓝色环境，不会出现任何模糊现象。

＃4。 自动化测试

自动化测试是蓝绿部署的一个关键方面。 它确保新版本的软件在部署到活动环境之前经过彻底的测试。

如果您的系统中没有大量的自动化测试（至少包括单元测试、功能测试和回归测试），那么考虑实施蓝绿部署可能没有多大意义。

缺乏自动化测试会大大减慢你的速度。 测试新（绿色）环境所需的时间将会很长，以至于当您能够切换到绿色环境时，从软件开发生命周期的角度来看，它已经“太旧”了。

＃5。 持续交付

蓝绿部署是持续交付管道的一部分，这最终意味着更快、更频繁地将软件发布到生产中。

当您准备好在绿色环境上测试新的软件版本时，您可以立即进行切换。 由于部署已经完成，您只需要做流量切换本身，速度非常快，您每天都可以这样做。 显然，假设您的测试活动也很快。

典型生命周期

运行蓝绿部署的平台有其自己特定的运行步骤和流程的生命周期。 它通常由以下部分组成：

构建新版本的软件。 这涉及编译代码、运行自动化测试以及创建可部署的工件。

下一阶段是将新版本的软件部署到非活动（绿色）环境。 这涉及设置环境、部署工件以及配置任何必要的设置。

新版本软件部署到绿色环境后，运行自动化测试以确保新版本正常运行。 这包括功能测试、回归测试、集成测试，如果你表现出色，甚至还包括性能测试。

将流量从活动（蓝色）环境切换到非活动（绿色）环境。 这涉及更新负载均衡器或 DNS 设置以将流量引导至绿色环境。 当然，您希望通过自动化流程来完成此操作。

切换完成后，监视应用程序以确保其正常运行。 这包括监视错误、性能问题和其他问题。

此步骤是可选的，您实际上不想太频繁地执行此步骤。 但如果有人检测到任何实质性问题，请将流量切换回蓝色环境以执行即时回滚。 同样，不会出现与生产用户相关的任何停机或断开连接。 只需更新负载均衡器或 DNS 设置即可将流量引导至蓝色环境。

解决这些问题并准备好再次返回新版本后，请将流量切换回绿色环境。 再次强调 – 更新负载均衡器或 DNS 设置以将流量引导回绿色环境。

最后，一旦新版本软件稳定并正常运行，就停用在蓝色环境中运行的旧版本软件。 您将需要它来构建系统的另一个新版本。

实施 CI/CD 管道

将蓝绿部署实施到 DevOps CI/CD 管道中应该是一个自然的过程。

一个强有力的先决条件是您已经拥有这两个相同的环境。 由于这应该是一个自动化过程，因此您可以使用基础设施作为代码工具，例如 AWS 云形成 甚至与云无关 地形 用于在自动化管道中创建/重新创建/更新环境的脚本。

一旦掌握了这一点，创建完全自动化的部署过程就相对容易了。 您只需重用现有的管道即可创建蓝色和绿色环境。 但是，这次您还需要在管道中包含测试流程。

您可以使用以下工具自动化流量切换过程 AWS 弹性负载均衡器 或者 NGINX。 这涉及到更新负载平衡器或 DNS 设置，以在新版本软件经过测试并准备就绪后将流量引导至绿色环境。

难题的下一个部分是监控。 为此，请使用类似的工具 AWS 云观察, 氮新遗物， 或者 数据狗。

最后，重用现有管道，甚至退役旧的蓝色环境。 由您决定是否首先对所有服务和组件执行销毁，然后再从头开始重新创建它们，或者您可以只更新链中每个服务的脚本。 通常，销毁并重新创建是一个更安全的选择，因为随着更新，您需要考虑更多的极端情况。

蓝绿部署最佳实践

想知道如何充分利用蓝绿部署？ 以下是实践中得出的一些技巧。

拥有可靠的数据库迁移策略

部署新版本的软件时，确保正确更新数据库架构非常重要。 使用数据库迁移策略，例如 飞道 或者 液体碱 管理数据库模式更改。

使用金丝雀分析工具

尽管金丝雀部署是一种替代方法，您仍然可以使用其中的一些技术来完善您的蓝绿部署。

使用金丝雀分析工具，例如 凯恩塔 或者 三角帆 分析新版本软件在现实环境中的性能。 这涉及将新版本软件的性能与旧版本软件的性能进行比较。

使用功能切换框架，例如 托格兹 启用或禁用新版本软件中的功能。 这允许逐步推出新功能，并在必要时实现快速回滚。

使用负载均衡器进行运行状况检查

使用负载均衡器（例如 AWS Elastic Load Balancer 或 NGINX）进行运行状况检查，以确保流量仅定向到运行状况良好的实例。 这可确保应用程序保持高可用性并最大限度地减少停机时间。

使用具有自动回滚功能的回滚计划

制定回滚计划以应对出现问题，并使用 AWS CodeDeploy 或 Octopus Deploy 等工具自动执行回滚过程。 这可确保最大限度地减少停机时间并确保应用程序保持高可用性。

当您发现新版本存在一些重大问题时，这主要适用于绿色环境。

您不需要针对蓝色环境的回滚计划，因为该环境不会受到交换机的影响，并且您可以在需要时立即返回到这一稳定的环境。

蓝绿部署的挑战

实施蓝绿部署可能会给开发团队带来一些挑战。 以下是一些典型的挑战：

设置和管理两个相同的环境可能既复杂又耗时。 这需要基础设施即代码工具（例如 Terraform 或 CloudFormation）方面的专业知识。 您需要拥有一支能够应对此类技术挑战的高级开发团队。

部署新版本的软件时，确保正确更新数据库架构非常重要。 这可能具有挑战性，特别是当数据库模式很复杂时。 您需要可靠的数据库部署流程来自动可靠地处理架构更新活动。

在现实环境中分析新版本软件的性能可能具有挑战性。 这需要 Canary 分析工具（例如 Kayenta 或 Spinnaker）方面的专业知识。

实现功能切换可能具有挑战性，特别是当应用程序具有大量功能时。 这需要开发团队之间进行仔细的规划和协调。

在现实环境中测试新版本的软件可能具有挑战性，特别是当应用程序具有大量用户或服务器时。 您需要尽可能使测试用例自动化。 此外，您的日常流程最终将包括开发和测试团队之间的大量协调。

拥有良好的监控解决方案是非常罕见的现实，但对于正确的 DevOps 操作，这是必须的。 只要可行，就投入时间使用经过验证的服务（AWS CloudWatch、New Relic、Datadog）构建该解决方案。

蓝绿部署和金丝雀部署的区别

虽然与传统部署过程的差异非常明显（传统部署过程中不存在运行不同软件版本的两个并行环境），但与 Canary 部署的差异可能更有趣。

蓝绿部署意味着两种环境（蓝色和绿色）。 但与此同时，两个环境在数据方面始终保持同步。 一旦新版本经过测试并认为准备就绪，流量就会从活动环境切换到非活动环境，使其成为新的活动环境。 您无需花费任何时间来部署新代码，并且不会涉及生产停机时间。 所有生产用户始终在当前活动环境中工作，他们甚至没有注意到切换。

金丝雀部署涉及将软件的新版本部署给一小部分用户，而大多数用户或服务器继续使用当前版本。 这是一个渐进的部署，而不是全面的切换。 在这种情况下，测试人员是直接生产用户，即使只是他们中定义的子集。 该小组正在积极测试新版本的生产流程，当最终稳定后，新版本将传播给其他用户。

那么哪一个更好呢？

一位顾问的回答“视情况而定”最适合这里，尽管听起来很刻薄。

如果您的系统的首要任务是高可用性，那么蓝绿部署将是您的选择。

如果您强烈偏好更快的反馈和更可控（尽管更慢）的新系统版本的推出，那么金丝雀部署比蓝绿部署更具优势。

重要的是，他们都足够敏捷，认为自己足以进行认真的 DevOps 系统创建。

实例探究

Netflix 使用蓝绿部署来部署其流媒体服务的新版本。 通过使用蓝绿部署，Netflix 可以在不影响用户体验的情况下部署其服务的新版本。 事实上，Netflix 还在其他情况下并行使用 Canary 部署，因此在同一屋檐下结合不同的 DevOps 部署方法并非不现实。

此外，Amazon 和 Etsy 使用蓝绿部署来部署其电子商务平台的新版本。

另一个案例是 LinkedIn，它使用蓝绿部署来部署其社交网络平台的新版本。

最后但并非最不重要的一点是，IBM 使用蓝绿部署来部署其云平台的新版本。

这些公司已成功在其平台基础设施中实施了蓝绿部署，并为其他公司树立了良好的榜样。

最后的话

与金丝雀一样，蓝绿部署致力于对现有的敏捷流程和方法进行最佳优化，以没人会注意到的方式顺利交付新软件。 这是此类方法的最终目标。 你不断地、经常地交付，但没有人知道，没有人注意到，最后，没有人关心。

对于开发团队来说，公司周围没有关于他们最新版本的八卦可能会有点令人沮丧。 但如果你问我，这正是你能提供的最好的服务。 没有人谈论它，但每个人都每天都在使用它。

接下来，查看常见的 DevOps 面试问题和答案。