143

My understanding of a canary release is that it's a partial release to a subset of production nodes with sticky sessions turned on. That way you can control and minimize the number of users/customers that get impacted if you end up releasing a bad bug.

My understanding of a blue/green release is that you have 2 mirrored production environments ("blue" and "green"), and you push changes out to all the nodes of either blue or green at once, and then use networking magic to control which environment users are routed to via DNS.

So, before I begin, if anything I have said so far is incorrect, please begin by correcting me!

Assuming I'm more or less on track, then a couple of questions about the two strategies:

  • Are there scenarios where canary is preferred over blue/green, and vice versa?
  • Are there scenarios where a deployment model can implement both strategies at the same time?
4

5 回答 5

111

我在这里写了一篇关于这个主题的详细文章：http: //blog.itaysk.com/2017/11/20/deployment-strategies-defined

在我看来，区别在于新的“绿色”版本是否向真实用户公开。如果是，那我就叫它金丝雀。实现 Canary 的一种常见方法是常规蓝/绿，并在新版本中添加特定用户的智能路由。阅读帖子以获得详细的比较

蓝绿色： 在此处输入图像描述

金丝雀： 在此处输入图像描述

于 2017-11-20T16:57:53.467 回答
104

蓝绿发布更简单、更快捷。

如果您已经在测试环境中测试了新版本并且非常确定新版本将在生产中正常运行，您可以进行蓝绿发布。始终使用功能切换是增加您对新版本的信心的好方法，因为新版本的功能与旧版本完全相同，直到有人翻转功能切换。将您的应用程序分解成小的、可独立发布的服务是另一回事，因为要测试的东西更少，可以破坏的东西也更少。

如果您不能完全确定新版本能否在生产环境中正常运行，则需要发布金丝雀版本。即使您是一名彻底的测试人员，互联网也是一个庞大而复杂的地方，并且总是会遇到意想不到的挑战。即使您使用功能切换，也可能会错误地实现。

部署自动化需要付出努力，因此大多数组织都会计划每次都使用一种或另一种策略。

如果您致力于让您有信心这样做的实践，那么进行蓝绿部署也是如此。否则，发出金丝雀。

蓝绿部署的本质是一次部署，而金丝雀部署的本质是增量部署，所以对于一个单一的用户池，我想不出一个我会描述为同时进行的过程。如果您有多个独立的用户池，例如使用不同的区域数据中心，您可以在每个数据中心内执行蓝绿，跨数据中心执行金丝雀。虽然如果您不需要在数据中心内部署金丝雀，您可能不需要跨数据中心部署。

于 2014-06-03T12:39:30.453 回答
8

尽管这两个术语看起来非常接近，但它们之间存在细微差别。一个对您的功能发布充满信心，另一个对您发布的方式充满信心。

金丝雀

  1. 金丝雀版本是一种降低在生产中引入新软件版本的风险的技术，方法是在将更改推广到整个基础架构之前缓慢地将更改推广到一小部分用户。

  2. 它即将了解新版本的性能（与其他应用程序、CPU、内存、磁盘使用情况等集成）。

蓝绿色：

  1. 它更多的是关于零停机部署的可预测版本。
  2. 在失败的情况下轻松回滚。
  3. 完全自动化的部署过程
于 2018-06-25T17:00:19.873 回答
5

这是一些内联定义 -

  • 蓝绿部署- 部署新版本的应用程序时，会创建第二个环境。一旦测试了新环境，它就会从旧版本中接管。然后可以关闭旧环境。

     

  • A/B 测试——一个应用程序的两个版本同时运行。每个请求都有一部分。然后，开发人员可以比较这些版本。  
  • Canary Release - 新版本的微服务与旧版本一起启动。然后，该新版本可以接收部分请求，并且团队可以测试该新版本如何与整个系统交互。
于 2019-09-06T16:28:14.067 回答
3

定义的良好开端。我认为，如果您将“发布”定义拆分为“部署”和“发布（功能）”，这也有助于为您的策略做出决定。

部署（二进制文件）

将产品二进制部署到（生产）系统的操作。

发布（功能）

管理（组）用户的功能可用性的操作。

为什么？在“发布”时，您通常有（多个）两个问题：1）错误/向后兼容性/等 2）验证新功能的有效性/可用性

然后问自己，在选择 Canary 或 Blue/green 或任何灰色/混合模式策略之前：发布/部署新版本时我们有什么顾虑？只有这样，如果你知道你的担忧，选择你的策略。

此外，可以执行更复杂的部署/发布策略。例如，在某些云/基础设施中，可能有多个生产服务器，并将不同比例的负载中继到不同的服务器和产品版本，并在将发布/部署扩展到所有用户之前监控可靠性。

特征标记

“配置”（冷的，甚至热的）哪些功能对哪些（组）用户（不）可用的操作

如果您还执行“功能标记”之类的操作，您可以先部署，从向后兼容性/错误的角度衡量您的版本的健全性，然后逐步向不同的用户发布新功能，反之亦然（缩小甚至回滚功能和/或二进制文件）。功能标记允许将功能的可用性与二进制文件的部署分开，并提供比仅“部署/回滚”更细粒度的决策

于 2019-03-11T13:02:52.657 回答