如何在 ECR 源管道中向 CodeDeploy 提供 AppSpec 和任务定义

Posted 2023-03-04

【中文标题】如何在 ECR 源管道中向 CodeDeploy 提供 AppSpec 和任务定义

【英文标题】：How to provide AppSpec and Task Definition to CodeDeploy in ECR sourced pipeline

【发布时间】：2020-02-03 09:46:04

【问题描述】：

我想在 ECR 映像更新时触发蓝/绿 ECS 部署。部署阶段需要三个输入工件：imageDetail.json、appspec.json 和 taskdef.json。

在创建管道时，我选择 ECR 存储库作为源，这会创建一个 imageDetail.json SourceArtifact，这很清楚。稍后在构建阶段，我可以将其放入输出工件中。

我完全想念的是如何提供剩下的两个文件？我应该在构建阶段定义buildspec.yaml 中内联它们（它们很大而且内联看起来很乏味）还是从 CodeCommit 中以某种方式获取它们（到目前为止，我认为我可以做到这一点而不必仅为该目的设置 CodeCommit）？

提供这些文件的通常做法是什么？

【参考方案1】：

是的，您需要从代码存储库 (github/CodeCommit) 获取其他文件。本教程是 ECS/CodeDeploy 部署管道的一个很好的指南：

https://docs.aws.amazon.com/codepipeline/latest/userguide/tutorials-ecs-ecr-codedeploy.html

【讨论】：

将文件直接存储在源代码中表明它们无法动态管理； AWS 是否提供了一种方法来检索生成的构建工件作为 ECS 的输入？将它们存储在源代码中似乎是一种解决方法。例如。如果在图像标签中使用语义版本控制，图像 URI 可能会发生变化，您是否会在每次版本更改时更新源中的文件？ （你真的可以这样做，因为这将触发管道中的另一个构建）。除非我错过了什么？

这个想法是“imageDetail.json”将作为构建过程的一部分动态生成，即创建图像，标记/推送它，然后在创建“imageDetail.json”时使用相同的标签神器。问题中提到的其余 2 个文件 (appspec/taskdef) 将保持静态，不经常更改，并将检查到源代码中。

Ok.. 但是作为示例，taskdef.json 需要引用图像 URI，如果标签在更新后增加，那么该引用肯定不能是静态的。我相信可以使用占位符，例如“图像”：“”？ .. 然后可以被 imageDetail.json 中的 ImageURI 值覆盖。你也这么理解吗？

是的，这是正确的。本教程也使用了 taskdef 中的占位符方法：docs.aws.amazon.com/codepipeline/latest/userguide/…