如何用AWS CodePipeline配置多ECS环境的CICD，支持手动审批部署

这两个阶段的输出（构建好的Docker镜像、ECS部署用的任务定义模板等）完全可以复用，不需要为不同环境重复执行，能有效节省成本和流程耗时。

整体Pipeline流程结构 #

整个CICD流程的阶段逻辑如下：

1. 源阶段（Source）：拉取代码仓库的目标分支代码
2. 构建阶段（Build）：通过CodeBuild构建镜像并推送到ECR，同时生成适配ECS部署的任务定义文件
3. 预发布部署阶段（Deploy to Staging）：将构建产物部署到Staging环境的ECS集群
4. 手动审批阶段（Manual Approval）：等待人工验证预发布环境的功能、日志后触发下一步
5. 生产部署阶段（Deploy to Production）：将同一构建产物部署到Production环境的ECS集群

具体配置步骤 #

1. 前置资源准备 #

• 两个独立的ECS集群：分别对应Staging和Production环境，每个集群需提前创建好对应的ECS服务、基础任务定义（任务定义中镜像地址可留占位符）
• ECR镜像仓库：用于存储CodeBuild构建好的Docker镜像
• CodeBuild项目：配置构建脚本，完成镜像构建、推送至ECR，同时生成替换了镜像地址的ECS任务定义文件（比如把模板中的<IMAGE_URI>替换为实际的ECR镜像地址）
• IAM权限配置：给CodePipeline、CodeBuild分配足够权限，包括ECR镜像推送、ECS部署、S3工件存储访问等

2. 配置CodePipeline各阶段 #

（1）源阶段

• 选择代码源（如CodeCommit、GitHub），指定目标分支（比如main），设置触发方式为「代码变更时自动触发」
• 配置输出工件存储到指定S3桶（CodePipeline可自动创建或选择已有桶）

（2）构建阶段

• 关联提前创建好的CodeBuild项目
• 确保CodeBuild的输出包含：推送至ECR的镜像（带唯一标签，比如Git Commit ID）、适配ECS部署的任务定义文件

（3）预发布部署阶段

• 选择部署提供商为Amazon ECS
• 配置Staging环境的ECS集群名称、服务名称
• 指定构建阶段输出的任务定义文件路径，设置镜像替换变量（比如IMAGE_URI对应ECR中的镜像地址）
• 根据需求选择部署策略：滚动更新或蓝绿部署

（4）手动审批阶段

• 在Pipeline中添加「审批」阶段，选择「手动审批」类型
• 指定审批人（可绑定IAM用户/角色），添加审批提示（比如「请验证Staging环境功能、日志，确认无误后通过审批」）
• 只有审批通过后，Pipeline才会进入生产部署阶段

（5）生产部署阶段

• 配置逻辑和预发布阶段一致，仅需替换为Production环境的ECS集群名称、服务名称
• 使用与预发布阶段完全相同的构建产物，确保生产环境部署的是经过验证的同一版本代码

关键注意事项 #

• 镜像版本一致性：CodeBuild构建时用唯一标签（如Git Commit ID）标记镜像，避免不同阶段拉取到不一致的版本
• 环境隔离：Staging和Production的ECS集群、VPC、数据库等资源需完全隔离，防止预发布操作影响生产环境
• 审批权限管控：仅授权指定的运维/开发人员拥有生产部署的审批权限，避免误操作
• 日志监控：给CodeBuild、ECS服务配置CloudWatch日志，方便验证预发布环境时快速排查问题

内容的提问来源于stack exchange，提问作者Abdulkarim Ahmed