gpt4 book ai didi

aws-cloudformation - Cloudformation - ECS 服务。如何在没有堆栈冲突的情况下管理管道部署的镜像更新

转载 作者:行者123 更新时间:2023-12-03 07:15:29 25 4
gpt4 key购买 nike

我正在尝试编写一个 CloudFormation 模板来完全定义 ECS 服务所需的所有资源,包括...

  • Nodejs 代码的 CodeCommit 存储库
  • 用于管理构建的 CodePipeline
  • ECR 存储库
  • ECS 任务定义
  • ECS服务
  • ALB 目标群体
  • ALB 监听器规则

我已经设法让所有这些工作正常进行。堆栈构建得很好。但是我不确定如何正确处理更新。

模板中任务定义中的容器需要定义图像。然而,直到管道首次构建代码之后,实际的应用程序镜像才会存在。

我有一个想法,我可以通过定义某种占位符图像“amazon/amazon-ecs-sample”来解决这个问题,例如,只是为了允许构建堆栈。当管道首次运行时,该图像将被 CodeBuild 替换。

这部分也工作正常。

当我尝试在 CloudFormation 模板中更新任务定义(例如添加环境变量)时,会出现问题。当我重新运行堆栈时,它会用模板中的原始占位符图像替换容器定义中的应用程序图像。

这很符合逻辑,因为 CloudFormation 显然假设模板中的图像是正确使用的图像。

我只是想找出处理这个问题的最佳方法。

本质上,我想找到某种方法来告诉 CloudFormation 在创建新修订时仅使用任务定义的最新修订中定义的任何图像,而不是用原始模板属性替换它。

我想要做的事情实际上可以通过纯 CloudFormation 实现吗?还是我需要使用自定义资源或类似的东西?

理想情况下,我希望将额外的堆栈依赖性保持在最低限度。

我想到的一种可能性是为容器定义图像使用固定标签,当cloudformation堆栈首次构建时,该标签实际上并不存在,但在第一个代码管道构建后将存在。

例如

image: [my_ecr_base_uri]/[my_app_name]:latest

然后我可以让我的管道使用此标签推送新版本。但是,我更喜欢使用特定版本标签来定义任务定义修订,就像这样......

image: [my_ecr_base_uri]/[my_app_name]:v1.0.1-[git-sha]

...因为这样可以很容易地准确查看当前正在运行的应用程序版本,并在需要时轻松恢复修订。

最佳答案

您的问题是您在此 CloudFormation 模板中放入了太多内容。您的模板可以包含 CodeCommit 存储库和 CodePipeline。但其他的东西应该是你的管道的输出。请记住:您的管道将有构建和部署阶段。构建阶段可以“构建”另一个在部署阶段执行的cloudformation模板。在此部署阶段,您的管道将构建 ECS 服务、任务、ALB 等...

关于aws-cloudformation - Cloudformation - ECS 服务。如何在没有堆栈冲突的情况下管理管道部署的镜像更新,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/64334296/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com