如何处理 CodePipeline 中的 ECS 部署以更改任务定义

how to handle ECS deploys in CodePipeline for changes in task definition

我正在使用两个容器部署 ECS Fargate 任务:1 个反向代理 nginx 和 1 个 python 服务器。对于每个我都有一个 ECR 存储库,并且我有一个 CI/CD CodePipeline 设置

CodeCommit -> CodeBuild -> CodeDeploy

此流程适用于简单的代码更改。但是如果我想添加另一个容器怎么办?我当然可以更新我的 buildspec.yml 以添加容器的构建,但我还需要 1) 更新我的任务定义,以及 2) 将此任务定义分配给我的服务。

问题:

1) 如果我在 CodeBuild 阶段使用 CLI 创建新的任务定义并将其与我的服务相关联,这是否会触发部署?然后我的 CodeDeploy 会再次尝试部署,所以我最终会部署两次?

2) 这种方法最终会创建一个新的任务定义并在每次部署时更新服务。这很糟糕吗?我是否应该有一些逻辑来拉下最新的任务修订并从 CodeCommit 版本中区分 JSON 并且仅在有差异时更新?

谢谢!

CodePipeline 的 ECS Job Worker 复制任务定义并更新 'imagedefinitions.json' 文件中指定容器的 Image 和 ImageTag,然后使用这个新的 TaskDef 更新 ECS 服务。工作人员无法在任务定义中添加新容器。

If I use the CLI in my CodeBuild stage to create a new task definition and associate it with my service, won't this trigger a deploy? And then my CodeDeploy will try to deploy again, so I'll end up deploying twice?

我不这么认为。是否有以这种方式触发 CodeDeploy 的 CloudWatch 事件规则?

This approach ends up creating a new task definition and updating the service on every single deploy. Is this bad? Should I have some logic to pull down the LATEST task revision and diff the JSON from CodeCommit version and only update if there is a difference?

每次部署发生时,ECS 部署作业工作人员都会创建一个新的任务定义修订版,因此如果这是官方行为,我不会认为它本身是坏事。

我会质疑为什么您需要在部署期间在运行时将新容器添加到您的任务定义中。您的任务定义通常应该较少修改,只有其中的 image:tag 应该定期修改 - ECS Deploy 操作可以帮助您实现。