Рабочий процесс определения задач AWS ECS

Рабочий процесс определения задач AWS ECS

Я настроил один из своих сервисов для развертывания в ECS (EC2). У меня есть сервис и определение задачи, настроенные через terraform, а затем для развертывания я использую действия Github, где, похоже, мне нужно снова определить определение задачи.

Похоже, требуются оба варианта. Каков правильный рабочий процесс, чтобы удалить дублирующее определение задачи?

Также существует проблема, заключающаяся в том, что после развертывания определения задачи с помощью действий Github образ был обновлен, и Terraform хочет его вернуть.

решение1

Это старая информация, но она пригодится вам в будущем.

Первый необходим для первоначального запуска службы (при создании предварительно настроенного кластера).

Вы можете рассмотреть второй вариант как вариант обновления вашегоуслуга(развернуть новую версию образа) поверх исходной во время развертывания GitHub Actions (так как вы можете изменить идентификатор образа и, по сути, все, что у вас есть в качестве параметра конфигурации в определении задачи).

Что касается Terraform, вы можете добавить правило жизненного цикла, чтобы игнорировать любые изменения в предварительно настроенном image_id, например, так:aws_ecs_service:

  lifecycle {
    ignore_changes = [task_definiton]
  }

Естьдовольно старая проблемав проекте terraform-provider-aws относительно того, как он обрабатывает изменения в определении задач. Взгляните наэтот комментарийдля возможного решения для вашего варианта использования (запись в блоге по теме от автора комментария).

Внизу вы можете увидетьеще один комментарийсвязываниеготовое решение Github Actions с примером кода terraform.

Связанный контент