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

Question

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

这可以看作是蓝绿部署的变体吗？既然我们使用了相同的负载均衡器并简单地更改了在这些实例上运行的 App-Version？

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

Answer 1

不可变更新如何工作？

不可变更新会发生什么，即 Elastic Beanstalk 将创建一个新的 AutoScaling 组，其参数与活动 AutoScaling 组完全相同。它将引导 1 个实例进入该组，检查它是否变得健康。该实例将连接到负载均衡器，并开始沿着已经活动的实例提供流量。然后，EB 将继续启动实例，直到 AutoScaling 组中存在所需数量的实例，与原始 AutoScaling 组中的数量相匹配。如果所有新实例均已启动且运行状况良好，EB 会将它们移至原始 AutoScaling 组，并清理新创建的 AutoScaling 组以及旧实例，同时会耗尽连接。因此，是的，暂时您将运行双倍数量的实例。

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

• 您不会冒部分部署的风险，因为您会冒滚动更新的风险。可能并非所有批次都在更新中运行，从而导致您的环境部分升级。这里要意识到的非常重要的一点是滚动更新在同一个自动缩放组中工作，不可变更新创建一个新的自动缩放组。
• 当滚动更新失败时，它必须再次更新自动缩放组，以回滚更新。回滚不可变的更新就像杀死新的自动缩放组一样容易 - 并且完成了。
• 考虑到您正在回滚自动缩放组，也可能会发生（根据您的参数）您必须重新启动一定数量的具有旧应用程序版本的计算机。这意味着您的 Elastic Beanstalk 环境会受到一定程度的破坏。
• 您的实例总是被替换。虽然这看起来微不足道，但它确实会在每次部署时为您提供一个新实例，而不是“永远”在同一个实例上运行。

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

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

绿/蓝实际上是在启动一个全新的环境，进行各种检查，然后翻转负载平衡器的 URL。从基础设施的角度来看，不可变部署确实与绿色/蓝色部署非常相似。但是，如果您对环境进行所有类型的功能检查（冒烟测试、健全性检查等），而这些检查不是基础设施性质的，那么情况就会大不相同，因为这个过程是自动化的。 EB 仅在执行此更新时执行运行状况检查。

那么......为什么不总是使用这种部署形式？

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

想到的其他一些随机沉思：

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

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