新应用程序版本的AWS不可更新

Question

尝试使用不可变部署策略在AWS Elastic Beanstalk上部署新的应用程序版本。无论如何，确定AWS如何处理从旧实例到新实例的流量？因为看起来在给定点处有两组（旧的+新的）实例在负载均衡器后面运行。

这可以被视为蓝绿部署的变种吗？既然我们点击了相同的Load Balancer并且只是更改在这些实例上运行的App-Version？

我在AWS文档中没有看到明显的解释。

Answer 1

不可变更新如何工作？

不可变更新发生的是，Elastic Beanstalk将创建一个新的AutoScaling组，其参数与活动的AutoScaling组完全相同。它将启动1个实例到该组中，并检查它是否正常。该实例将连接到负载均衡器，并开始为已经处于活动状态的实例提供流量。然后，EB将继续引导实例，直到所需的实例数量出现在AutoScaling组中，并且与原始AutoScaling组中的数量匹配为止。如果所有新实例均已启动且运行状况良好，EB将把它们移至原始的AutoScaling组，并清理新创建的AutoScaling组以及旧实例，并清除连接。因此，是的，暂时来说，您将有两倍数量的实例在运行。

使用不可变更新而不是滚动更新的原因是什么？

• 您不会冒险进行部分部署，因为您可能会面临滚动更新的风险。可能并非所有批次都已在更新中运行，从而导致环境部分升级。在这里要意识到的一个非常重要的事项是，滚动更新在同一个自动缩放组中起作用，不可变的更新将创建一个新的自动缩放组。
• 滚动更新失败时，它必须再次更新自动伸缩组，以进行更新的回滚。回滚不可变的更新就像杀死新的自动伸缩组一样容易，而且完成。
• 考虑到您正在对autoscaling组进行回滚，还可能会发生（基于您的参数），您必须使用旧的应用程序版本重新引导一定数量的计算机。这意味着对您的Elastic Beanstalk环境造成了一定程度的破坏。
• 您的实例将始终被替换。尽管这看起来微不足道，但它确实会在每次部署时为您提供一个新实例，而不是让您“永远”在同一实例上运行。

不可变更新的真正价值在于所有这些特征的结合：每个部署在新的新实例上一次“全部”发生。回滚不会中断正在运行的实例。

绿色/蓝色部署与什么有关系？不是吗？

绿色/蓝色实际上正在引导一个全新的环境，进行各种检查，然后翻转负载平衡器的URL。从基础结构的角度来看，不可变的部署确实非常类似于绿色/蓝色部署。但是，如果您对环境进行各种功能检查（烟雾测试，健康检查等），这些检查不是基础设施性质的，则差异很大，因为此过程是自动化的。 EB仅在执行此更新时执行运行状况检查。

所以……为什么不总是使用这种形式的部署？

不可变的部署不能同时处理资源配置更新（即负载平衡器设置）和应用程序版本更新。如果要同时执行这两个操作，则必须将它们拆分为两个连续的更新，或者使用绿色/蓝色部署。

我想到了其他一些随机的念头：

• 假设您的帐户中有X个实例的限制，并且您已经在使用X-2个实例。您的环境是5个实例。您无法执行不可变更新，因为它不符合您的限制。

• 如果您的环境有50个实例（我只是在这里说明一个随机的巨大数字）。要启动包含50个实例的整个AutoScaling组以及原始的AutoScaling组来进行更新，将花费大量时间和金钱。