共计 2159 个字符，预计需要花费 6 分钟才能阅读完成。
在之前对于 CI/CD 的文章中，咱们简略探讨了蓝绿部署和金丝雀公布以及它们在继续交付中所表演的角色。这些都是非常无效的办法，可能大大降低与应用程序部署相干的危险。所以，这篇文章咱们来深刻介绍蓝绿部署和金丝雀公布。
蓝绿部署和金丝雀公布通过让 IT 人员能够在公布过程中产生问题时可能还原到先前版本来加重应用程序部署的危险。这两个办法让版本之间来回切换就像轻按开关一样容易，并且能够主动执行，从而最大水平缩小了用户裸露在错误代码的工夫。在咱们更进一步探讨这两种办法之前，让咱们先辨别部署和公布。
如何将部署与公布解耦
尽管这两个词常常混同应用，但实际上部署和公布是两个独立的过程。部署是指在特定环境（包含生产环境）装置指定软件版本的过程，更多是一种技术行为。它不肯定必须与公布相关联。而公布则是指向客户群提供新性能，是一种业务决策。
传统过程中，会在公布日期前一天部署好更新或是新性能，该更新或性能公布后可能会在媒体中广泛传播。家喻户晓，在部署过程中可能会出错，而因为公布工夫与部署工夫非常相近，因而简直没有解决问题的空间。而如果将部署和公布解耦，那么在整个性能开发过程中频繁进行生产部署能够升高 IT 部门的危险。那么，要实现部署和公布的解耦，须要代码和架构可能满足新性能公布不须要变更应用程序的代码。
什么是蓝绿部署
在蓝绿公布过程中，有两套生产环境：蓝环境和绿环境。蓝色是以后版本并领有实时流量，绿色是蕴含更新代码的环境。无论任何时候，只有一套环境有实时流量。
要公布一个新版本，须要先将代码部署到没有流量的环境中，这是执行最终测试的中央。当 IT 人员确认应用程序曾经准备就绪，就会将所有流量都将路由到绿色环境。那么绿色环境就曾经失效，并且执行公布。
这是新代码首次在生产负载（理论流量）进行测试。在理论公布代码之前，危险依然存在，并且永远不会隐没。然而，如果呈现问题，IT 部门能够疾速将流量从新路由回蓝色版本。因而，他们所要做的就是亲密监控代码行为，甚至能够应用适当的工具将其自动化，以查看绿色环境中的版本是否运行良好或是否须要回滚。
蓝绿部署：无论何时，只有一套生产环境有实时流量
这种办法曾经不是新办法了。IT 部门总会创立一个新版本，而后将实时流量从新路由到该版本。而版本控制中通过组件编码提供可靠性和可重复性是这一办法的亮点。
咱们应该如何取得可靠性和可重复性？开发人员将所有参数编入版本控制中，该版本控制是一个跟踪所有代码更改的零碎，相似于数据库。其中包含利用程序逻辑、构建过程、测试、部署过程、降级过程以及复原过程等。总之，蕴含所有影响应用程序的因素。而后，计算机执行代码，在相应的环境中部署应用程序，该环境与版本控制中编码的 exact state 相匹配。
在 DevOps 呈现之前，该流程通常是手动的，并且容易出错。因为所有更改都只能记录在文档中，基于此，开发人员能够从新创立应用程序和环境。因为须要手动执行两个关键步骤，因而此过程过于不牢靠，从而导致频繁呈现问题。
尽管将应用程序和环境进行编码也是一项须要手动进行的工作，然而它毕竟只是开发过程的一部分，而不是独自的工作，例如创立文档。在版本控制中编入了与生产环境雷同的代码。任何更改或更新都将主动触发测试，以确保代码处于可部署状态。这样，如果呈现人为谬误，零碎也可能很快发现它。
如何了解金丝雀公布（灰度公布）
与蓝绿部署相似，金丝雀公布也是始于两套环境：有实时流量的环境以及没有实时流量但蕴含了更新的代码的环境。与蓝绿部署不同的是，流量是逐步迁徙到更新的代码。一开始是 1%，而后 10%、25%，以此类推，直至 100%。通过自动化公布，当确认代码可能正确运行时，它就能够逐步推广到更大、更要害的环境中。如果在任何时候产生了问题，所有流量都会被回滚到之前的版本。这在很大水平上升高了危险，因为仅有一小部分用户会应用到新的代码。
IT 不仅能够管制用户部署的比例，而且金丝雀公布还能够从不太重要的用户开始，例如应用收费账户的用户或相对来说不太重要的业务市场。
金丝雀公布：实时流量逐步从旧版本迁徙到新版本直到更新失效
返回微信公众号 Rancherlabs 后盾回复【金丝雀】即可取得应用 Istio 进行金丝雀公布的视频 demo 以及常见 debug。
Cluster Immune System
Cluster Immune System 能够让金丝雀公布更进一步。它会连贯到生产监控零碎，当面向用户的性能偏离预约义范畴（例如，错误率高出 2%）时，将会主动回滚版本。这种办法能够辨认通过自动测试难以发现的谬误，并缩小了检测和响应性能降落所需的工夫。
通过将公布与部署解耦并利用蓝绿部署或金丝雀公布，危险将会显著升高。在任何时候，IT 都可能将应用程序回滚到之前的版本——这曾经与传统的应用程序公布流程相去甚远了。
新的技术和办法首次让这所有成为可能：版本控制、作为代码的基础架构（Infrastructure as code）、容器和 Kubernetes 都能在这个簇新的、灵便的、面向 DevOps 的 IT 世界中施展着作用。
作者：
Catherine Paganini，领导 kublr 的市场团队，从策略到战术帮忙 Kublr 建立品牌形象。此前，曾在华盛顿邮报市场部门工作。
原文链接：
https://thenewstack.io/primer…