滚动、蓝绿还是金丝雀？terraform-aws-ecs 支持的 3 种部署策略详解与选型建议

滚动、蓝绿还是金丝雀？terraform-aws-ecs 支持的 3 种部署策略详解与选型建议

【免费下载链接】terraform-aws-ecsTerraform module to create AWS ECS resources 🇺🇦项目地址: https://gitcode.com/gh_mirrors/te/terraform-aws-ecs

上线新版本时最怕什么？服务中断、流量雪崩、回滚困难。对于使用 AWS ECS 的团队来说，部署策略的选择直接决定了发布过程是"丝滑切换"还是"事故现场"。本文以开源项目terraform-aws-ecs为例，它是专门用来创建 AWS ECS 资源的 Terraform 模块，为你详解滚动、蓝绿、金丝雀 3 种主流 ECS 部署策略的工作原理、配置要点和选型建议，帮你用最少的心智负担完成安全发布。

什么是 ECS 部署策略？先看一张全景图

简单来说，部署策略就是"新版任务替换旧版任务"的方式。AWS ECS 提供默认的滚动部署（Rolling Update），也可以借助 CodeDeploy 实现蓝绿部署（Blue/Green）与金丝雀/线性部署（Canary/Linear）。terraform-aws-ecs 的service模块把这三种能力全部封装成了声明式变量，你不需要手写复杂的 AWS CLI 或 API 调用。

上图展示了一个 ECS 集群的基本构成：Cluster 是部署的顶层容器，内部包含 Fargate、EC2 Auto Scaling 等容量提供方（Capacity Provider），并集成 CloudWatch Logs 日志。三种部署策略都发生在这个集群内的 Service 层面。

部署策略速览：3 种方案 30 秒看懂

滚动部署：ECS 默认策略，开箱即用

滚动部署是 ECS 服务创建时的默认行为。它的核心逻辑是：先启动一批新版本任务，等待健康检查通过，再逐步停掉同等数量的旧任务，直到全部替换完成。整个过程由 ECS 自动编排，你只需要关注两个关键参数：

• deployment_minimum_healthy_percent：部署期间必须保持健康的最少任务比例（默认 66%）
• deployment_maximum_percent：部署期间允许运行的最大任务比例（默认 200%）

在 modules/service/variables.tf 中可以看到这两个参数的完整定义。为了进一步降低事故风险，terraform-aws-ecs 还封装了部署熔断器（Circuit Breaker）：当新版本任务连续健康检查失败达到阈值时，自动回滚到上一版本，无需人工干预。配置只需一个简单的deployment_circuit_breaker对象：

deployment_circuit_breaker = { enable = true rollback = true }

如上图所示，Service 是连接任务与自动扩缩容、负载均衡的"编排层"，滚动部署就是在这一层对 Task 进行逐个替换。它的最大优点是简单——不需要额外配置 CodeDeploy 和两套环境，适合绝大多数日常发布场景。

蓝绿部署：两套环境双保险，零停机发布

如果你对可用性要求极高，蓝绿部署是业界公认的"安全牌"。它的思路是：同时维护**蓝色（当前生产）和绿色（新版本）**两套目标组，新版本在绿色环境完成验证后，通过 CodeDeploy 一次性把生产流量切过去。一旦发现问题，一秒切回蓝色环境，回滚成本极低。

terraform-aws-ecs 在 examples/fargate/main.tf 中给出了完整范例，配置要点有三处：

1. 声明策略：在deployment_configuration中设置strategy = "BLUE_GREEN"，并用bake_time_in_minutes控制新环境"烘烤"（观察）时间；
2. 双目标组：在load_balancer的advanced_configuration里指定alternate_target_group_arn（备用目标组）；
3. 流量规则：为 ALB 监听器配置production_listener_rule（生产流量规则）和test_listener_rule（测试流量规则），让测试流量可以单独打到绿色环境验证。

deployment_configuration = { strategy = "BLUE_GREEN" bake_time_in_minutes = 2 }

蓝绿部署还支持可选的lifecycle_hook（生命周期钩子），可以在POST_SCALE_UP、POST_TEST_TRAFFIC_SHIFT等关键阶段接入 Lambda 做自动化验证，相当于给发布流程加了"质检关卡"。

金丝雀与线性部署：让 1% 的流量替你试错

金丝雀部署（Canary）是"小步快跑"思想的体现：先把一小部分流量（例如 10%）切到新版本，观察一段时间确认无误后，再逐步放大比例直到 100%。线性部署（Linear）则是按固定步长匀速放量，比如每次增加 20%，每一步间隔 1 分钟。两者都由 CodeDeploy 驱动，区别只是放量曲线不同。

terraform-aws-ecs 用同一个deployment_configuration变量覆盖两种模式：

• 金丝雀：设置strategy = "CANARY"，配合canary_configuration指定首批流量比例（canary_percent）和观察时长（canary_bake_time_in_minutes），见 examples/ec2-autoscaling/main.tf；
• 线性：设置strategy = "LINEAR"，配合linear_configuration指定每步放量比例（step_percent）和每步间隔（step_bake_time_in_minutes），见 examples/complete/main.tf。

deployment_configuration = { strategy = "CANARY" canary_configuration = { canary_percent = 10.0 canary_bake_time_in_minutes = 5 } }

如上图所示，Task 是部署的原子单元，容器和日志、IAM 角色都封装在任务内部。金丝雀部署的精髓，就是让这一小撮"敢死队"任务（图中的 Container 实例）先承接灰度流量，用真实用户数据检验新版本。

三种部署策略怎么选？一张决策清单送给你

优先选滚动部署，如果：

• ✅ 服务是内部系统或对停机不敏感
• ✅ 发布频率高、变更幅度小
• ✅ 不想引入 CodeDeploy 等额外组件

优先选蓝绿部署，如果：

• ✅ 面向外部用户的核心业务，可用性要求 99.9%+
• ✅ 需要严格的发布审批和快速回滚能力
• ✅ 有独立测试环境可以完整验证新版本

优先选金丝雀/线性部署，如果：

• ✅ 变更风险高（数据库迁移、依赖升级等）
• ✅ 希望用真实流量做 A/B 验证
• ✅ 团队具备监控告警能力，能及时发现异常

另外注意：蓝绿、金丝雀、线性策略都需要服务挂在 ALB 负载均衡器后面，且要在deployment_controller中配合 CodeDeploy 使用；而纯滚动部署则完全由 ECS 自身控制，无需额外依赖。

快速上手：从官方示例开始

如果你不想从零写配置，terraform-aws-ecs 的examples目录就是最佳起点，每个示例都对应一种部署策略：

• examples/complete：完整示例，内含线性（LINEAR）部署配置
• examples/fargate：Fargate 场景，内含蓝绿（BLUE_GREEN）部署配置
• examples/ec2-autoscaling：EC2 自愈场景，内含金丝雀（CANARY）部署配置

克隆仓库后，找到与你的场景最接近的示例，修改region、name和容器镜像即可terraform init && terraform apply一键验证。核心配置逻辑都集中在 modules/service/main.tf 的aws_ecs_service资源中，想深入了解实现细节可以直接阅读源码。

写在最后

部署策略没有绝对的好坏，只有是否匹配你的业务阶段：初创期用滚动部署快速迭代，业务稳定后上蓝绿部署守住可用性，高风险的重大变更则交给金丝雀部署慢慢验证。terraform-aws-ecs 的可贵之处在于，它用统一的 Terraform 变量语法把三种策略拉到了同一套工作流里，切换策略往往只是改动几行配置的事。希望这篇 ECS 部署策略指南能帮你做出更理性的选型，让每一次发布都从容不迫。🚀

【免费下载链接】terraform-aws-ecsTerraform module to create AWS ECS resources 🇺🇦项目地址: https://gitcode.com/gh_mirrors/te/terraform-aws-ecs