本文来自Rancher Labs
在之前关于CI/CD的文章中，我们简单讨论了蓝绿部署和金丝雀发布以及它们在持续交付中所扮演的角色。这些都是十分有效的方法，能够大大降低与应用程序部署相关的风险。所以，这篇文章我们来深入介绍蓝绿部署和金丝雀发布。
蓝绿部署和金丝雀发布通过让IT人员可以在发布过程中发生问题时能够还原到先前版本来减轻应用程序部署的风险。这两个方法让版本之间来回切换就像轻按开关一样容易，并且可以自动执行，从而最大程度减少了用户暴露在错误代码的时间。在我们更进一步讨论这两种方法之前，让我们先区分部署和发布。
如何将部署与发布解耦
虽然这两个词经常混淆使用，但实际上部署和发布是两个独立的过程。部署是指在特定环境（包括生产环境）安装指定软件版本的过程，更多是一种技术行为。它不一定必须与发布相关联。而发布则是指向客户群提供新功能，是一种业务决策。
传统过程中，会在发布日期前一天部署好更新或是新功能，该更新或功能发布后可能会在媒体中广泛传播。众所周知，在部署过程中可能会出错，而因为发布时间与部署时间十分相近，因此几乎没有解决问题的空间。而如果将部署和发布解耦，那么在整个功能开发过程中频繁进行生产部署可以降低IT部门的风险。那么，要实现部署和发布的解耦，需要代码和架构能够满足新功能发布不需要变更应用程序的代码。
什么是蓝绿部署
在蓝绿发布过程中，有两套生产环境：蓝环境和绿环境。蓝色是当前版本并拥有实时流量，绿色是包含更新代码的环境。无论任何时候，只有一套环境有实时流量。
要发布一个新版本，需要先将代码部署到没有流量的环境中，这是执行最终测试的地方。当IT人员确认应用程序已经准备就绪，就会将所有流量都将路由到绿色环境。那么绿色环境就已经生效，并且执行发布。
这是新代码首次在生产负载（实际流量）进行测试。在实际发布代码之前，风险仍然存在，并且永远不会消失。但是，如果出现问题，IT部门可以快速将流量重新路由回蓝色版本。因此，他们所要做的就是密切监控代码行为，甚至可以使用适当的工具将其自动化，以查看绿色环境中的版本是否运行良好或是否需要回滚。
蓝绿部署：无论何时，只有一套生产环境有实时流量
这种方法已经不是新方法了。IT部门总会创建一个新版本，然后将实时流量重新路由到该版本。而版本控制中通过组件编码提供可靠性和可重复性是这一方法的亮点。
我们应该如何获得可靠性和可重复性？开发人员将所有参数编入版本控制中，该版本控制是一个跟踪所有代码更改的系统，类似于数据库。其中包括应用程序逻辑、构建过程、测试、部署过程、升级过程以及恢复过程等。总之，包含所有影响应用程序的因素。然后，计算机执行代码，在相应的环境中部署应用程序，该环境与版本控制中编码的exact state相匹配。
在DevOps出现之前，该流程通常是手动的，并且容易出错。因为所有更改都只能记录在文档中，基于此，开发人员可以重新创建应用程序和环境。由于需要手动执行两个关键步骤，因此此过程过于不可靠，从而导致频繁出现问题。
虽然将应用程序和环境进行编码也是一项需要手动进行的任务，但是它毕竟只是开发过程的一部分，而不是单独的工作，例如创建文档。在版本控制中编入了与生产环境相同的代码。任何更改或更新都将自动触发测试，以确保代码处于可部署状态。这样，如果出现人为错误，系统也能够很快发现它。
如何理解金丝雀发布（灰度发布）
与蓝绿部署类似，金丝雀发布也是始于两套环境：有实时流量的环境以及没有实时流量但包含了更新的代码的环境。与蓝绿部署不同的是，流量是逐渐迁移到更新的代码。一开始是1%，然后10%、25%，以此类推，直至100%。通过自动化发布，当确认代码能够正确运行时，它就可以逐步推广到更大、更关键的环境中。如果在任何时候发生了问题，所有流量都会被回滚到之前的版本。这在很大程度上降低了风险，因为仅有一小部分用户会使用到新的代码。
IT不仅可以控制用户部署的比例，而且金丝雀发布还可以从不太重要的用户开始，例如使用免费账户的用户或相对来说不太重要的业务市场。
金丝雀发布：实时流量逐渐从旧版本迁移到新版本直到更新生效
Cluster Immune System
Cluster Immune System可以让金丝雀发布更进一步。它会连接到生产监控系统，当面向用户的性能偏离预定义范围（例如，错误率高出2%）时，将会自动回滚版本。这种方法可以识别通过自动测试难以发现的错误，并减少了检测和响应性能下降所需的时间。
通过将发布与部署解耦并利用蓝绿部署或金丝雀发布，风险将会显著降低。在任何时候，IT都能够将应用程序回滚到之前的版本——这已经与传统的应用程序发布流程相去甚远了。
新的技术和方法首次让这一切成为可能：版本控制、作为代码的基础架构（Infrastructure as code）、容器和Kubernetes都能在这个崭新的、灵活的、面向DevOps的IT世界中发挥着作用。