如何保持最后的X ECS任务定义有效? [英] How to keep the last X ECS task definitions active?

问题描述

我具有以下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.

我该如何实现?

推荐答案

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.

有两种常见的处理方式，并且需要能够回滚到任务定义的先前版本.

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)生成一个带有要部署的应用程序的提交SHA标签的Docker映像，然后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屋！