金丝雀部署（Canary Deployment）
金丝雀部署（Canary Deployment）
什么是金丝雀部署?
在另一篇文章中，我们谈到了蓝绿部署。在这篇文章中，我们将了解另一种部署策略，它具有相同的优点，但风险更低，往往能带来更好的洞察力。
持续集成改变了我们开发软件的方式。但 CI 环境不同于生产环境，合成测试并不总能发现问题。有些问题只有在投入生产时才会出现，而那时，损害已经造成。金丝雀部署可以让我们在投入生产前进行测试。
什么是金丝雀部署
在软件工程中，金丝雀部署是一种分阶段发布的做法。我们首先向一小部分用户推出软件更新，让他们进行测试并提供反馈。一旦变更被接受，更新就会向其他用户推出。
金丝雀部署向我们展示了用户在现实世界中与应用程序变更的交互方式。与蓝绿部署一样，金丝雀策略提供无停机升级和轻松回滚。与蓝绿部署不同的是，金丝雀部署更加平稳，故障影响有限。
发布与部署
金丝雀版本是应用程序的早期构建。在开源领域，将稳定分支和开发分支分开是一种普遍的策略。许多项目使用奇数/偶数编号方案来区分稳定版本和非稳定版本。
公司通常会发布其产品的金丝雀版本，希望精通技术的用户或高级用户愿意下载试用。Mozilla 及其火狐浏览器的夜间版和测试版，以及谷歌的 Chrome 浏览器金丝雀发布渠道，都是公司发布金丝雀应用程序的例子。
在金丝雀部署中，我们会在系统中安装更新，并将用户分成两组。其中一小部分用户将使用金丝雀版本，而其他用户则继续使用旧版本，作为对照。
之后，一旦我们花时间评估了金丝雀版本，我们就可以决定将其他用户迁移到金丝雀版本，或者将所有人退回到旧版本。
金丝雀部署的工作原理
正如我们所见，金丝雀部署涉及同时运行两个版本的应用程序。我们将旧版本称为 “稳定版”，新版本称为 “金丝雀”。我们有两种部署更新的方法：滚动部署和并排部署。
滚动部署
在滚动部署中，我们会分批或分阶段安装更改--每次安装几台机器。其他机器继续运行稳定版本。这是最直接的金丝雀部署方式。
运行稳定版本的服务器
只要金丝雀在一台服务器上运行，一些用户就会开始看到更新。
金丝雀部署开始
在此过程中，我们会观察升级后机器的运行情况。我们检查错误和性能问题，听取用户反馈。
随着我们对 “金丝雀 ”越来越有信心，我们会继续在其他机器上安装它，直到所有机器都运行最新版本。
金丝雀部署进行中
如果检测到故障或得到令人失望的结果，我们可以通过将升级后的服务器回滚到初始状态来撤销更改。
并排部署
并排部署策略与蓝绿部署有很多共同之处。我们不是分阶段升级机器，而是创建一个全新的复制环境，并在其中安装金丝雀版本。
假设应用程序在多台计算机或容器、几个服务和一个数据库上运行。
为了进行部署，我们会克隆硬件资源并安装更新。一旦金丝雀在新环境中运行，我们就会向部分用户展示它。这通常需要使用路由器、负载平衡器、反向代理或应用程序中的其他业务逻辑。
5% 的用户被发送到金丝雀测试版
与滚动部署一样，我们在监控金丝雀的同时，会逐渐将越来越多的用户从控制版本上迁移开。这个过程一直持续到我们发现问题或所有用户都使用金丝雀版本为止。
部署完成后，我们会移除控制环境，以释放资源。现在，金丝雀版本就是新的稳定版本。
金丝雀部署完成
金丝雀部署的好处
为什么要大费周章地实施金丝雀战略？好处多多：
- A/B 测试：我们可以使用金丝雀进行 A/B 测试。换句话说，我们向用户提供两种选择，看看哪种更受欢迎。
- 容量测试：要测试大型生产环境的容量是不可能的。通过金丝雀部署，容量测试是内置的。当我们慢慢将用户迁移到金丝雀时，系统中的任何性能问题都会开始出现。
- 反馈：我们从真实用户那里获得宝贵意见。
- 无冷启动：新系统需要一段时间才能启动。金丝雀部署会慢慢积累动力，以防止冷启动缓慢。
- 无停机时间：与蓝绿部署一样，金丝雀部署不会造成停机。
- 轻松回滚：如果出现问题，我们可以轻松回滚到之前的版本。
第一批金丝雀
金丝雀
使用金丝雀作为预警系统的想法由来已久。早在谷歌或Netflix使用金丝雀之前，煤矿工人就携带着真正的金丝雀来寻找煤气泄漏点。当这些比人类更易受无味气体影响的小鸟发现问题时，就该离开矿井了。
可以预见的是，随着技术的进步，情况会越来越好。如今，云技术已经不再危及野生动物，而且更加实用：
- 金丝雀发布：只要我们有远程更新软件的方法，我们就可以进行金丝雀发布。应用商店就是一个很好的例子。Google Play 和苹果的 App Store 都支持分阶段发布。通过这一功能，我们可以将更新一波一波地推送给设定比例的用户。
- 滚动金丝雀：我们有许多工具，如 AWS CodeDeploy、Chef、Puppet 或 Docker，可以帮助我们执行滚动更新。
- 并排金丝雀：云允许我们按需创建和拆卸硬件和服务。我们有 Terraform、Ansible 或 AWS CloudFormation 等工具来使用代码定义基础设施。
- CI/CD：当我们将持续交付和部署加入其中时，我们就得到了一种最有效的代码交付模式。
Kubernetes
Kubernetes 专为部署复杂的分布式系统而设计，因此值得单独讨论。Kubernetes 是一个流行的编排平台，内置了滚动和并行部署工具。该平台是金丝雀部署的理想选择，因为它允许我们只使用代码来部署、更新和扩展应用程序。
如果您想了解 Kubernetes 并观看金丝雀部署的实际操作，请下载我们的免费电子书《CI/CD with Docker Kubernetes》。
规划金丝雀
在规划金丝雀部署时，我们必须考虑到几个方面：
- 阶段：我们最初要向金丝雀发送多少用户，分几个阶段。
- 持续时间：我们计划运行金丝雀多久？金丝雀部署通常运行几分钟或几小时。金丝雀发布则不同，因为我们必须等待足够多的客户端更新后才能评估结果。这可能需要几天甚至几周的时间。
- 指标：我们应该记录哪些指标来分析进度，包括应用程序性能和错误报告。精心选择参数对成功部署金丝雀至关重要。
- 评估：我们将使用什么标准来确定金丝雀是否成功。
首先，我们可以尝试对数法，即以 1-10-100 为单位。也就是说，先将 1%的用户群发送到金丝雀，以确保不会出现任何严重问题。然后，我们将金丝雀提升到 10%，看看它在负载情况下的表现。最后，我们迁移 100%的用户群，完成整个过程。
我们可以根据自己的需要设置不同的阶段。也许两个阶段（2-100）就足够了，而有些人可能更喜欢循序渐进的阶段（10-20-50-100）。
不同金丝雀分区策略
用户迁移策略
计划好各个阶段后，我们必须确定如何挑选参与金丝雀计划的用户：
- 随机：我们可以随机向金丝雀发送一定比例的用户。
- 按地区：每次在一个地区部署金丝雀。例如，我们可以选择“夜间跟随 ”策略，在每个地区的夜间，也就是在线用户最少的时候发布金丝雀。
- 早期采用者计划：让用户有机会选择加入（或退出）金丝雀计划，可能会取得最佳效果。早期采用者更有可能提供高质量的反馈。
- 狗粮化：这一术语与“吃自己的狗粮 ”这一说法有关，涉及先向内部用户和员工发布金丝雀。
金丝雀部署的缺点
没有什么是完美的。金丝雀部署也不例外。让我们看看金丝雀部署的缺点：
· 挫败感：第一批使用金丝雀的用户会发现最严重的错误。此外，一些用户可能会因为被当作实验品而感到不快。如果您担心这个问题，可以考虑启动一个选择加入计划(可以将其命名为“早期采用者”或“内部计划”,以增加吸引力)。
· 成本：并排部署的成本较高，因为我们需要额外的基础设施。利用云的优势，按需创建和删除资源，以降低成本。
· 复杂性：金丝雀部署与蓝绿部署具有相同的复杂性。拥有许多生产机器、迁移用户以及监控新系统都是非常复杂的任务。应尽量避免手动操作。应始终使用Semaphore等CI/CD平台自动执行部署流程。
· 时间：建立健康的金丝雀部署管道需要时间和精力。从好的方面来看，一旦我们操作正确，就可以进行更频繁、更安全的部署。
· 数据库：关于如何更改数据库架构的书籍已有整本。问题在于数据库在部署期间必须同时与测试版和控制版协同工作。因此，如果出现破坏性的架构变更，我们就会遇到麻烦。在做出变更时，我们需要保持向后兼容性，这又增加了复杂性。
金丝雀部署并不适合所有人
遗憾的是，并非所有人都能使用金丝雀部署。在某些情况下，我们无法使用该策略：
· 在不允许任何类型持续部署的环境中工作时，例如医疗或航空航天行业。
· 处理关键任务或生命支持系统时，例如能源网络或核反应堆的应用程序。
· 当故障会对经济造成灾难性后果时，例如对金融系统。
· 当需要对数据库或存储后端进行重大架构变更时。
· 当我们依赖用户计算机上安装的软件，且无法远程更新时。
金丝雀部署与蓝绿部署
我们在之前的文章中讨论了蓝绿部署的优缺点。既然我们已经了解了金丝雀部署，那么接下来要问的问题就是：哪个更好?
需要考虑的因素很多，没有放之四海而皆准的答案。但根据经验，如果以下情况属实，我们应该考虑蓝绿色二元部署:
· 我们对新版本充满信心。我们已经对代码进行了全面测试，估计失败的可能性非常低。
· 我们正在以安全的小规模迭代方式进行开发。
· 我们需要一次性切换所有用户。
在以下情况下，金丝雀可能是一个更好的选择：
· 我们对新版本没有100%的信心，我们认为失败的可能性很小到中等。
· 我们担心性能或扩展问题。
· 我们正在进行重大更新，例如添加一个全新的或实验性的功能。
· 我们接受缓慢的发布。
· 我们的应用程序依赖于一个旧系统或第三方系统，而我们在测试环境中无法复制该系统。在这种情况下，只能在实际生产系统中进行测试。
结论
真正的考验来自人们开始使用我们的软件时。金丝雀部署使我们能够与真实用户进行受控试验。当我们将这一策略与快速的CI/CD工作流程相结合时，我们便获得了高效、功能丰富的发布周期。