如何保持最后 X 个 ECS 任务定义处于活动状态? [英] How to keep the last X ECS task definitions active?

查看:22
本文介绍了如何保持最后 X 个 ECS 任务定义处于活动状态?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有以下 Terraform 代码来更新具有新任务定义的服务:

I have the following Terraform code to update a service with a new task definition:

resource "aws_ecs_task_definition" "app_definition" {
  family = "my-family"

  container_definitions = "${data.template_file.task_definition.rendered}"
  network_mode          = "bridge"
}

resource "aws_ecs_service" "app_service" {
  name            = "my-service"
  cluster         = "my-cluster"
  task_definition = "${aws_ecs_task_definition.app_definition.arn}"
  desired_count   = "1"
  iam_role        = "my-iam-role"
}

更新我的服务时,我的任务定义的最新版本变为非活动状态.结果,在ECS控制台中尝试手动回滚到以前的版本时,我无法选择它:

When updating my service, the last revision of my task definition becomes inactive. As a result, I can not select it when trying to manually roll back to a previous revision in the ECS console:

Error: No active task definition found

理想情况下,我希望保持最近的 X 个修订版本处于活动状态,这样如果出现问题,我总是可以通过控制台手动回滚.

Ideally, I want to keep the last X revisions active so I can always manually roll back via the console if something goes wrong.

我怎样才能做到这一点?

How can I achieve that?

推荐答案

Terraform 目前不允许这样做,它的资源生命周期模型意味着当你替换某些东西(任务定义是不可变的)时,Terraform 必须创建一个新的并销毁旧的.

Terraform doesn't currently allow for this and its resource lifecycle model means that when you replace something (task definitions are immutable) Terraform must create a new one and destroy the old one.

使用 ECS 任务定义也不能真正被销毁,而是被标记为非活动状态,因为当前部署的任务可能正在使用它,直到它们被服务更新为新的任务定义.

With ECS task definitions also can't really be destroyed and instead are just marked as inactive as there may be tasks currently deployed that are using it until they are updated by the service to the new task definition.

有 2 种常用方法来处理此问题,并且需要能够回滚到任务定义的先前版本.

There's 2 common ways of dealing with this and the need to be able to roll back to a previous version of a task definition.

首先是在初始创建之外不使用 Terraform 来管理任务定义,而是使用 AWS ECS CLI 工具之类的工具来执行此操作.

The first is simply not to use Terraform to manage the task definition beyond initial creation and use something like the AWS ECS CLI tool to do this instead.

另一个选项,也是我使用的选项,是让我的 CI(在我们的例子中是 Gitlab CI)生成一个 Docker 映像,标记有要部署的应用程序的提交 SHA,然后 Terraform 将任务定义更新为apply 上的新提交 SHA 标记图像以及使用新任务定义 ARN 更新 ECS 服务.

The other option, and the one that I use, is to have my CI (Gitlab CI in our case) generate a Docker image tagged with the commit SHA of the application to be deployed and then Terraform updates the task definition to the new commit SHA tagged image on an apply as well as updating the ECS service with the new task definition ARN.

当我们想要回滚时,我们使用 CI 的能力回滚到不同的提交,仅使用旧提交 SHA 启动部署作业,然后部署旧映像.

When we want to roll back we use our CI's ability to roll back to a different commit, launching just the deploy job with the old commit SHA and so deploying the old image.

这使 Terraform 对正在部署的内容完全不可知,并使 CI 系统负责部署所需的版本,该版本通常是最新的,但如果我们手动单击部署,则有时是特定的提交,当然回滚时目标是以前的版本.

This keeps Terraform pretty agnostic of what's being deployed and makes the CI system responsible for deploying the required version which is normally latest but sometimes a specific commit if we have a manual click to deploy and of course the target previous version when rolling back.

这确实意味着您无法通过 AWS 控制台启动回滚,但我实际上很喜欢这样,因为我希望 CI 系统成为随时部署内容的真实来源.

It does mean that you can't launch roll backs through the AWS console but I actually like this as I want the CI system to be the source of truth for what is deployed at any time.

这篇关于如何保持最后 X 个 ECS 任务定义处于活动状态?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆