如何通过CodePipeline更新无负载均衡的ECS后台服务任务定义

可行解决方案 #

方案1：使用ECS标准滚动部署（最简便） #

AWS CodePipeline原生提供Amazon ECS (Standard)部署动作提供商，不需要绑定CodeDeploy Deployment Group，也不需要配置任何负载均衡资源，完全适配无端口暴露的后台服务场景。
你现有的CI/CD流程几乎不需要做大改，仅需要调整部署阶段配置：

• 给scheduler、worker服务单独配置部署阶段，部署动作类型选择ECS (Standard)
• 动作参数仅需指定对应ECS集群名称、服务名称，将Build阶段生成的taskdef.json作为输入即可
• 该动作会自动注册新版本Task Definition，触发ECS服务按照你预先配置的滚动更新策略（最小健康百分比、最大扩容百分比）完成服务更新，全程不需要人工介入，所有变更均可通过git版本管理。

方案2：创建无负载均衡的CodeDeploy部署组（适配现有蓝绿流程） #

你之前的认知存在偏差：CodeDeploy ECS部署组早已支持无负载均衡配置，专门为后台任务类服务设计。
你可以直接为scheduler、worker服务创建独立的CodeDeploy部署组，在负载均衡配置步骤选择NONE即可，不需要关联ALB、目标组等资源。
该方案的优势是可以完全复用你当前为web服务设计的整套流水线逻辑：生成taskdef.json、appspec.yml的工具不需要做任何修改，部署流程和web服务完全统一，还可以给后台服务也提供蓝绿部署的能力，降低版本更新的风险。

方案3：基于CloudFormation的栈更新（IaC对齐度最高） #

如果你的ECS集群、服务资源本身就是通过CloudFormation管理的，还可以选择将Task Definition的模板也纳入CloudFormation栈配置，CI/CD阶段直接通过更新CloudFormation栈的方式完成部署：

• Build阶段完成镜像构建后，将新镜像地址作为参数传入CloudFormation栈更新动作
• CloudFormation会自动生成新版本Task Definition，并触发对应ECS服务的更新，所有基础设施变更完全以代码形式留存，符合你的设计目标。

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