问题标签 [blue-green-deployment]

我们目前正在 Heroku 上运行一个 Ruby on Rails 项目 (RefineryCMS)，其中包含两个 dyno。

每次我们更新网站时，我们都会经历大约 1 到 2 分钟的停机时间。管理层对此并不满意。

我们真正想要的是某种（透明的）蓝绿部署：http ://martinfowler.com/bliki/BlueGreenDeployment.html

这可以在 Heroku 或其他云平台即服务上实现吗？

我们也在使用 Unicorn，但如有必要，我们很乐意进行更改。

我阅读了 Martin Fowler 的Blue/Green Deployment文章，非常喜欢它。基本上，你有两个生产级环境的概念：一个“蓝色”LIVE 环境和一个“绿色”LIVE 环境。在任何给定时间，您只有 1 个环境被认为是“真实”的 LIVE 环境。因此，您在这两个 LIVE 环境之前放置了某种路由/切换机制（可能是中间 Web 应用程序或修改后的软件负载平衡器），以指示用户被路由到哪个环境（我们在这里谈论 Web 应用程序）。

因此，您的所有用户都被路由到了，例如，位于 的 Green LIVE 环境http://green.example.com/myapp。然后，当您准备好推出一些新的生产更改时，而不是将它们部署到 Green LIVE，而是将它们部署到 Blue LIVE，并开始将一小部分（~10%）的用户路由到 Blue LIVE。典型的策略是让路由器使用 IP 地址或 cookie 来确定用户应该被路由到蓝色还是绿色。

当您确信您的生产更改（应用于 Blue LIVE 上）没有错误错误/问题时，您重新配置路由器，现在将所有流量重定向到 Blue LIVE 的http://blue.example.com/myapp.

现在，关于我的问题：

我正在设计一个 GWT 应用程序，并希望实现这种蓝/绿切换模式。问题是 GWT 应用程序是客户端的，不遵循 Spring、Struts、JSP、servlet 应用程序使用的普通服务器端 Web 应用程序架构。

所以我问：我怎么会有 2 个 Tomcat 实例（蓝色 Tomcat 和绿色 Tomcat），从蓝色/绿色“路由器”后面为用户提供同一个 GWT 应用程序的两个不同版本？通过“路由器”，我可能在谈论一个中间网络应用程序http://router.example.com/myapp-router。

从视觉上看，这就是问题所在：

这就是基本架构：问题是客户端会向 发出请求router.example.com/myapp-router，而路由器会将请求转发到blue.example.com/myapp或green.example.com/myapp。我不相信 GWT（我在这里使用RequestFactory）最终会知道与GWT 应用程序下载到客户端中的任何一个blue或一旦进行通信。green

所以我问：这可能吗？是否有任何特殊的配置/代码/库/技术等。我需要使用才能完成这项工作？我没有想到的任何警告或陷阱？提前致谢！

语境

• 我正在尝试设计一种稳定、一致的方法来更新生产中的 RavenDB 索引
• 我特别关注索引更新故事（即我知道我的设置并没有完全解决高可用性问题）
• 这是一个假设场景（即目前没有任何东西在生产中）
• 假设硬件/软件/网络配置是灵活的（即添加另一个 RavenDB 实例、更多服务器、持久缓存等）

当前托管方案

• 2x Web 服务器负载平衡在主动-被动配置中，每个运行 1 个 Web 应用程序
• 1x 服务器运行 RavenDB 实例（最新稳定版本）

约束

• 全过程必须保持高可用
• 部署过程将完全自动化
• 部署过程可能会在整个部署过程中的任何时候启动回滚
• 索引重建可能需要长达 1 分钟；这么长时间没有可显示的数据是不可接受的

  ---

潜在的解决方案

添加第二个 RavenDB 实例并以主动-主动配置复制 RavenDB

• 活动 Web 服务器与活动 RavenDB 实例对话
• 被动 Web 服务器与被动 RavenDB 实例对话

部署将如下所示：

• 停止复制
• 将新的 Web 应用程序代码部署到被动 Web 服务器
• 启动 Web 应用程序并让它自动更新其 RavenDB 实例中的索引定义
• 测试
• 将负载均衡器切换到被动 Web 服务器，使其处于活动状态
• 监控（x 时间）并在需要时回滚
• 开始复制并让索引定义和数据在另一个 RavenDB 实例中更新

回滚看起来像这样：

• 将负载均衡器切换到被动 Web 服务器，使其处于活动状态

有没有更优化的方法来实现这一点？

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?

When using Elastic Beanstalk with CNAME swapping for zero downtime deployments, DNS caching (clients not respecting TTL) causes some clients to continue sending traffic to the old environment (for up to several days).

When using Elastic Beanstalk with Route53 Aliases for zero downtime deployments, does DNS caching remain an issue?

是否可以利用为蓝/绿部署正确设置的环境进行验收测试？

您会在那里看到哪些优势/风险？

基本上我会想象一个绿色环境将用于运行一些验收测试。如果通过，将流量切换为绿色并继续进行常规的蓝/绿场景。

谢谢！

是否有任何工具可以在 cloudfoundry 上为 node.js 应用程序自动部署蓝/绿。我已经尝试过 cloudfoundry gradle 插件（https://github.com/cloudfoundry/cf-java-client/tree/master/cloudfoundry-gradle-plugin），但它需要带有 jar/war 文件的文件参数，该文件中不存在节点应用程序。您如何在 Cloudfoundry 中自动化节点应用程序的蓝/绿部署？

我研究了这篇关于蓝/绿部署的文章，然后更多的谷歌搜索向我介绍了这篇关于金丝雀发布的文章。我有这样的歧义：数据库会发生什么？我们应该如何使它们同步？我有两种可能的情况：

• 想象一下，当蓝色处于活动状态时，每个环境（绿色和蓝色）有两个单独的数据库
  ，新记录将被插入到它的数据库中，
  除非我们提供类似触发器的机制（或任何其他机制），否则绿色不会意识到这些变化机制）来更新绿色数据库。
• 第二种情况建议我们在两个环境之间共享一个向后兼容的数据库，但是
  在处理数据库时向后兼容并不是那么容易，我们必须
  在发布应用程序之前发布数据库更改。

可能存在第三种情况，在主蓝/绿部署中为数据库实施蓝/绿部署。

您认为更好的解决方案是什么，为什么？您是否建议任何其他做法或众所周知的模式？

谢谢你

在我们使用 Spring Cloud 开发微服务期间，我们开始使用 Zuul 作为从外部到微服务的任何连接的代理，以及任何需要联系另一个微服务的微服务。

一段时间后，我们得出结论，Zuul 被设计为边缘服务（仅代理从外部到微服务的流量），不应该用于微服务间的通信。尤其是 Spring Cloud 推荐使用 eureka 与另一个服务建立直接（潜在的负载平衡）连接的方式，使我们反对在一切之间使用 Zuul。

当然，一切都按预期运行良好（就像使用 Spring Cloud 一样），但我们对如何使用此设置执行某个用例一无所知。

在部署新版本的微服务时，我们希望对旧版本和新版本进行蓝/绿部署。但是，由于微服务之间没有 Zuul，两个独立服务之间的通信将继续使用旧版本，直到它从 eureka 中删除。

我们正在考虑如何实现这一目标。在下面的图片中，我绘制了我认为可能是一个选项。

在图片的第一部分，Zuul 调用 eureka 获取注册中心来创建路由。此外，服务 1 正在调用 eureka 以让注册表路由到服务 2。由于服务 2 在 eureka 注册表中，因此路由成功完成。

在图片的第二部分，部署了服务 2（服务 2.1）的更新。它也向 eureka 注册，这使得服务 1 现在路由到服务 2 和服务 2.1。蓝/绿部署不希望这样做。

在第三部分中，展示了针对此问题的潜在解决方案，并为此目的部署了另一个 eureka 实例。此实例不支持对等，并且不会与第一个 eureka 实例同步。与第一个实例相反，这个实例的唯一目的是促进蓝/绿部署。服务 2.1 向第二个 eureka 实例注册，服务 1 的配置被更改为不是从第一个而是从第二个 eureka 实例获取其注册表。

我们面临的主要问题是这是否是一个可行的解决方案。拥有 Zuul 路由的灵活性是我们在这种情况下没有的一大优势。我们应该回到通过 Zuul 路由每个服务到服务的调用，还是有另一种更合适的解决方案（可能是某种功能区配置）？还是第二个 eureka 实例是此类部署的最佳解决方案？

任何反馈将不胜感激。

亲切的问候，安德烈亚斯

当我修补我的实时 Jenkins 实例时，我冒着停机的风险。因此，我想运行蓝色和绿色的 Jenkins 主实例。这样一来，我就可以在另一个工作稳定的情况下工作。

不出所料，搜索这个主题告诉我如何使用 Jenkins 对其他应用程序进行蓝绿部署。

您是否有任何提示或参考资料可以让我在设置绿色和蓝色 Jenkins 大师方面领先一步？