我正在尝试编写CloudFormation模板以完全定义ECS服务所需的所有资源，包括...
我设法使所有这些工作正常进行。堆栈构建良好。但是我不确定如何正确处理更新。
模板中“任务定义”中的“容器”需要定义图像。但是，直到管道首次构建代码后，实际的应用程序映像才存在。
我有个想法，也许可以通过定义某种占位符图像“ amazon / amazon-ecs-sample”来解决此问题，只是为了允许构建堆栈。管道首次运行时，此图像将被CodeBuild替换。
这部分也可以正常工作。
当我尝试更新任务定义（例如在CloudFormation模板中添加环境变量）时，会出现问题。当我重新运行堆栈时，它将容器定义中的应用程序映像替换为模板中的原始占位符映像。
这很合逻辑，因为CloudFormation显然假设模板中的图像是正确使用的图像。
我只是想找出解决此问题的最佳方法。
基本上，我想找到一种方法告诉CloudFormation在创建新修订时仅使用任务定义的最新修订中定义的任何图像，而不是将其替换为原始模板属性。
使用纯CloudFormation我实际上是想做些什么吗？还是需要使用自定义资源或类似的东西？
理想情况下，我想将额外的堆栈依赖性保持在最低水平。
我曾经想到过的一种可能性是对容器定义图像使用固定的标签，该标签在首次构建cloudformation堆栈时实际上并不存在，而在首次代码流水线构建之后便存在。
>例如
image: [my_ecr_base_uri]/[my_app_name]:latest
然后我可以让我的管道使用此标签推送新的修订版。但是，我更喜欢使用特定的Verion标签定义任务定义修订，例如...
image: [my_ecr_base_uri]/[my_app_name]:v1.0.1-[git-sha]
...，因为这样可以很容易地准确查看当前正在运行的应用程序的版本，并在需要时轻松地还原修订版本。
答案 0 :(得分：0)
您的问题是，您要在此CloudFormation模板中放入太多内容。您的模板可以包括CodeCommit存储库和CodePipeline。但是其他应该是管道的输出。切记：您的管道将具有构建和部署阶段。构建阶段可以“构建”在部署阶段执行的另一个cloudformation模板。在此部署阶段，您的管道将构建ECS服务，任务，ALB等...