View a markdown version of this page

Amazon ECS 金丝雀部署 - Amazon Elastic Container Service
金丝雀部署涉及的资源注意事项金丝雀部署的工作原理
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

Amazon ECS 金丝雀部署

金丝雀部署首先将一小部分流量路由到新修订进行初始测试，然后在金丝雀阶段成功完成后，一次性转移所有剩余流量。借助 Amazon ECS 金丝雀部署，请使用真实的用户流量验证新服务修订，同时最大限度地降低风险。这种方法提供了一种受控方式来部署更改，并且能够监控性能，如果检测到问题则可以快速回滚。

金丝雀部署涉及的资源

下面是 Amazon ECS 金丝雀部署涉及的资源：

  • 流量转移：Amazon ECS 用于转移生产流量的过程。对于 Amazon ECS 金丝雀部署，流量分两个阶段转移：首先转移到金丝雀百分比，然后完成部署。

  • 金丝雀百分比：评估期内路由到新版本的流量百分比。

  • 金丝雀烘焙时间：在继续进行全面部署之前监控金丝雀版本的持续时间。

  • 部署烘焙时间：Amazon ECS 将所有生产流量转移到新服务修订后，在终止旧服务修订之前等待的时间（以分钟为单位）。这是生产流量转移后蓝色服务修订和绿色服务修订同时运行的持续时间。

  • 生命周期阶段：部署操作中的一系列事件，例如“生产流量转移后”。

  • 生命周期挂钩：特定生命周期阶段的 Lambda 函数或暂停点。Lambda 钩子会调用您为运行自定义代码而定义的 Lambda 函数。暂停钩子暂停部署并等待您调用 ContinueServiceDeployment 以继续。

  • 目标组：一种 Elastic Load Balancing 资源，用于将请求路由到一个或多个已注册目标（例如 EC2 实例）。创建侦听器时，您为其默认操作指定目标组。流量将转发到在侦听器规则中指定的目标组。

  • 侦听器：一种 Elastic Load Balancing 资源，可通过所配置的协议和端口检查连接请求。为侦听器定义的规则决定了 Amazon ECS 如何将请求路由到其注册的目标。

  • 规则：与侦听器关联的 Elastic Load Balancing 资源。规则定义了请求的路由方式，由操作、条件和优先级组成。

注意事项

选择部署类型时，请考虑以下因素：

  • 资源使用情况：金丝雀部署在评估期间会同时运行原始任务集和金丝雀任务集，从而增加资源使用量。

  • 流量：确保金丝雀百分比产生足够的流量，以便对新版本进行有意义的验证。

  • 监控复杂性：金丝雀部署需要同时监控和比较两个不同版本之间的指标。

  • 回滚速度：金丝雀部署通过将流量转移回原始任务集来实现快速回滚。

  • 风险缓解：金丝雀部署通过将暴露限制在一小部分用户来提供出色的风险缓解措施。

  • 部署持续时间：金丝雀部署包括评估期，这些评估期会延长总体部署时间，但提供了验证机会。

金丝雀部署的工作原理

Amazon ECS 金丝雀部署过程遵循结构化方法，包含六个不同的阶段，可确保安全可靠地进行应用程序更新。在验证应用程序并将其从当前版本（蓝色环境）迁移到新版本（绿色环境）时，每个阶段都有其特定目的。

  1. 准备阶段：在现有的蓝色环境旁创建绿色环境。

  2. 部署阶段：将新的服务修订版部署到绿色环境。Amazon ECS 使用更新的服务修订版启动新任务，同时蓝色环境继续传送生产流量。

  3. 测试阶段：使用测试流量路由来验证绿色环境。应用程序负载均衡器将测试请求定向到绿色环境，而生产流量仍保留在蓝色环境中。

  4. 金丝雀流量转移阶段：在金丝雀阶段，将配置的流量百分比转移到新的绿色服务修订，然后将 100.0% 的流量转移到绿色服务修订

  5. 监控阶段：监控烘焙时间内的应用程序运行状况、性能指标和警报状态。检测到问题时将启动回滚操作。

  6. 完成阶段：通过终止蓝色环境来完成部署。

金丝雀流量转移阶段遵循下面的步骤：

  • 初始：部署开始时，100% 的流量都路由到蓝色（当前）服务修订。绿色（新）服务修订接收测试流量，但是最初不接收生产流量。

  • 金丝雀流量转移：这是一个两步式流量转移策略。

    • 步骤 1：10.0% 变为绿色，90.0% 变为蓝色

    • 步骤 2：100.0% 变为绿色，0.0% 变为蓝色

  • 金丝雀烘焙时间：在金丝雀流量转移之后等待可配置的持续时间（金丝雀烘焙时间），以便在流量负载增加的情况下监控和验证新修订的性能。

  • 生命周期挂钩：可选的 Lambda 函数或暂停钩子可以在部署期间的各个生命周期阶段配置，以执行自动化验证、监控或自定义逻辑。为 PRODUCTION_TRAFFIC_SHIFT 或 PRE_PRODUCTION_TRAFFIC_SHIFT 配置的钩子将在每个生产流量转移步骤中进行调用。

部署生命周期阶段

金丝雀部署过程会经历不同的生命周期阶段，每个阶段都有特定职责和验证检查点。了解这些阶段有助于监控部署进度并有效排查问题。

每个生命周期阶段最多可持续 24 小时，此外，PRODUCTION_TRAFFIC_SHIFT 中的每个流量转移步骤最多可持续 24 小时。建议将该值保持在 24 小时以内。这是因为异步进程需要时间来触发挂钩。当一个阶段达到 24 小时后，系统将超时，导致部署失败，然后会启动回滚。

Amazon CloudFormation 部署还有其他超时限制。尽管 24 小时的阶段限制仍然有效，但 Amazon CloudFormation 会对整个部署强制执行 36 小时的限制。如果整个过程未在 36 小时内完成，Amazon CloudFormation 将使部署失败，然后启动回滚。

对于暂停钩子，超时可以配置为最多 20,160 分钟（14 天）。总体部署的超时时间为 30 天。

生命周期阶段
生命周期阶段 说明 生命周期挂钩支持
RECONCILE_SERVICE 仅当启动多个服务修订版处于活动状态的新服务部署时，才会发生此阶段。 是
PRE_SCALE_UP 绿色服务修订版尚未启动。蓝色服务修订版正在处理 100% 的生产流量。没有测试流量。 是
SCALE_UP 绿色服务修订版纵向扩展至 100% 并启动新任务的时间。此时绿色服务修订版不传送任何流量。 否
POST_SCALE_UP 绿色服务修订版已经启动。蓝色服务修订版正在处理 100% 的生产流量。没有测试流量。 是
TEST_TRAFFIC_SHIFT 蓝色服务修订版和绿色服务修订版正在运行。蓝色服务修订版可处理 100% 的生产流量。绿色服务修订版正在将测试流量从 0% 迁移到 100%。 是（仅限于 Lambda）
POST_TEST_TRAFFIC_SHIFT 测试流量转移已完成。绿色服务修订版可处理 100% 的测试流量。 是
PRE_PRODUCTION_TRAFFIC_SHIFT 发生在每个生产流量转移步骤前。对于金丝雀部署来说，这将发生在金丝雀流量转移前以及剩余的流量转移前。 是
PRODUCTION_TRAFFIC_SHIFT 金丝雀生产流量将路由到绿色修订，并且会调用生命周期挂钩，超时时间为 24 小时。第二步将剩余生产流量转移到绿色修订。 是（仅限于 Lambda）
POST_PRODUCTION_TRAFFIC_SHIFT 生产流量转移已完成。 是
BAKE_TIME 蓝色服务修订版和绿色服务修订版同时运行的持续时间。 否
CLEAN_UP 蓝色服务修订版已完全缩减至 0 个运行任务。在此阶段之后，绿色服务修订版将成为生产服务修订版。 否

配置参数

金丝雀部署需要以下配置参数：

  • 金丝雀百分比：在金丝雀阶段路由到新服务修订的流量百分比。这使得可以使用受控的生产流量子集进行测试。

  • 金丝雀烘焙时间：将剩余流量转移到新服务修订之前在金丝雀阶段等待的持续时间。这为监控和验证新版本提供了时间。

流量管理

金丝雀部署使用负载均衡器目标组来管理流量分布：

  • 原始目标组：包含来自当前稳定版本的任务，并接收大部分流量。

  • 金丝雀目标组 ：包含来自新版本的任务，并接收少量流量用于测试。

  • 加权路由：负载均衡器使用加权路由规则，根据配置的金丝雀百分比在目标组之间分配流量。

监控和验证

有效的金丝雀部署依赖于全面监控：

  • 运行状况检查：两个任务集必须通过运行状况检查才能接收流量。

  • 指标比较：比较原始版本和金丝雀版本之间的关键性能指标，例如响应时间、错误率和吞吐量。

  • 自动回滚：配置 CloudWatch 警报，以便在金丝雀版本显示性能下降时自动触发回滚。

  • 手动验证：继续之前，请使用评估期手动查看日志、指标和用户反馈。

金丝雀部署的最佳实践

请遵循这些最佳实践来确保使用服务成功进行金丝雀部署。

选择合适的流量百分比

在选择金丝雀流量百分比时，请考虑下面的因素：

  • 从小处着手：从 5-10% 的流量开始，以尽量减少问题发生时的影响。

  • 考虑应用程序关键性：对任务关键型应用程序使用较小百分比，对不太重要的服务使用较大百分比。

  • 考虑流量：确保金丝雀百分比产生足够的流量以进行有意义的验证。

设置合适的评估期

根据下面的注意事项配置评估期：

  • 留出足够的时间：设置足够长的评估期以捕获有意义的性能数据，通常为 10-30 分钟。

  • 考虑流量模式：考虑应用程序的流量模式和高峰使用时间。

  • 平衡速度和安全性：较长的评估期提供更多数据，但部署速度较慢。

实施全面监控

请设置监控以跟踪金丝雀部署性能：

  • 关键指标：监控两个任务集的响应时间、错误率、吞吐量和资源利用率。

  • 基于警报的回滚：配置 CloudWatch 警报，以在指标超过阈值时自动触发回滚。

  • 比较分析：设置控制面板，并排比较原始版本和金丝雀版本之间的指标。

  • 业务指标：包括业务特定的指标，例如转化率或用户参与度以及技术指标。

规划回滚策略

使用下面的策略为潜在回滚场景做好准备：

  • 自动回滚：根据运行状况检查和性能指标配置自动回滚触发器。

  • 手动回滚过程：当自动触发器无法捕获所有问题时，记录手动回滚的明确过程。

  • 回滚测试：定期测试回滚过程，以确保它们在需要时正常工作。

部署之前彻底验证

在继续进行金丝雀部署之前，确保进行彻底验证：

  • 部署前测试：在金丝雀部署之前，彻底测试暂存环境中的更改。

  • 运行状况检查配置：确保运行状况检查准确反映应用程序的就绪情况和功能。

  • 依赖项验证：验证新版本是否与下游和上游服务兼容。

  • 数据一致性：确保数据库架构更改和数据迁移向后兼容。

协调团队参与

确保在金丝雀部署期间团队之间进行有效协调：

  • 部署时间段：在工作时间安排金丝雀部署，以便团队能够进行监控和响应。

  • 通信渠道：针对部署状态和问题升级建立明确的通信渠道。

  • 角色分配：定义监控、决策和回滚执行的角色和职责。