1

我们有以下蓝=绿部署设计。想法是为了我们

  • 将最新代码部署到非活动集群中
  • 冒烟测试
  • 切换 VIP 使当前的 VIP 处于非活动状态

我们在 go.cd 中相应地创建了管道。但是，我们遇到的问题是，我们希望将最新代码部署到新转换为非活动状态的集群。我们如何确保这个不会再次变得活跃？或者其他人如何进行蓝绿部署？谷歌搜索结果是针对 AWS 的解决方案。我们不使用 AWS 或公共云。

编辑 1

基础设施限制：我们只有两个集群可用的硬件

是什么阻止您在实时集群中运行批处理作业？: 实时集群服务于生产查询，批量加载会占用机器资源，可能会导致在线系统无响应

在此处输入图像描述

4

1 回答 1

1

我不确定这是否会对您有所帮助，但在我们的设置中，我们有一个负载均衡器，客户端可以与之交谈。这个 LB 知道哪些实例是活动的，哪些是黑暗的，并相应地转发流量。如果请求具有“特殊”标头，则 LB 将流量发送到暗池。我们每个应用程序都有这个设置（只是在您发布的图表中清楚地说明这一点，有些人可能会认为整个平台都是蓝绿色的）

所以它的图表是，绿色集群是活的，蓝色是黑暗的（<3 ascii art）

           [Client]      <- I assume this is internal, otherwise add a FW :).
               |
              \|/
   [Application Load Balancer]  <- internal, per app
               |
               |\--------------\--------------\--------------\
              \|/             \|/            \|/            \|/
         [Node 1 G/L]    [Node 2 G/L]    [Node 3 B/D]  [Node 4 B/D]


G = Green  B = Blue
L = Live   D = Dark

Application Load Balancer可以是多种技术。它可以是网关应用程序（如 Netflix Zuul）或负载平衡网络服务器（如使用 HAProxy 的 AirBnB Smartstack）。

值得一提的是，如果 live cluster 火了，我们不会自动将 dark cluster 提升到 live... 我想说的是，我们不使用 blue/green 作为 High Availability 的替代品. 这是你的担心吗？（因为您在这里使用 VIP 和 keepalived）

编辑

感谢您对问题的回答。不幸的是，我认为您无法在约束条件下成功蓝绿。

您是否考虑过只有一个大环境，然后在Canary Release和蓝绿之间进行某种混合？使用这种方法，最初您有 5 台服务器服务实时流量和 1 台服务暗流量（我假设您总共有 6 个盒子）。可以配置实时节点，以便 3 个节点获取实时流量，2 个节点进行批处理。

当您对暗池中的代码感到满意时，您开始一个接一个地升级服务器，直到所有服务器都在实时池中提供实时流量。此时，您可能需要将 2 个批处理服务器移动到轻池，除非您有办法更慢地移动它们（可能一次一个作业？）。

以防万一，我想把一些事情说清楚，因为这可能会咬到你（而且我不希望其他开发人员感到痛苦）。如果您的批处理是您平台的基本组成部分，那么您没有真正的 HA 环境，出于我在原始答案中概述的原因，如果您的实时集群因任何原因失败（数据库损坏？），您将不会能够在其余硬件中运行。

于 2015-09-26T17:58:10.013 回答