Веб-Сервисы Amazon — План Terraform Не Обновляет Определение Задачи Aws С Указанием Последней Активной Версии

  • Автор темы Gfdtk1963
  • Обновлено
  • 13, Oct 2024
  • #1

Мне нужна ваша помощь в ситуации, с которой я столкнулся с террафомом. Моя компания недавно запустила новый веб-сайт, WordPress которого размещен в контейнере AWS ECS. Мне пришлось внести некоторые изменения в инфраструктуру сайта, и я заметил, что при составлении плана терраформирования я получаю сообщение о том, что произошли изменения за пределами терраформирования, одним из которых является номер версии определения задачи ECS. Но если посмотреть дальше, когда terraform планирует определение задачи ECS, вместо сохранения самого последнего номера версии (31) он возвращается к последней версии, которая была применена terraform (19). Я предполагаю, что это число записано в состоянии TF. Мой вопрос: есть ли какой-либо способ (параметр или атрибут) выполнить план терраформирования и заставить его спланировать определение задачи ECS с последней активной версией, развернутой в контейнере ECS, в данном случае 31? Развертывание выполняется через конвейер битбакетов, а образ сохраняется в ECR.

Вот шаги, которые мы выполняем в Bitbucket:

Terraform detected the following changes made outside of Terraform since the
last "terraform apply":

# module.wp.aws_ecs_service.service[0] has been changed

~ resource "aws_ecs_service" "service" {

id                                 = "arn:aws:ecs:us-east-1:my-account:service/emprc-fgt-prd/my-name"

name                               = "my-name"

tags                               = {

"Environment" = "prd"

"Name"        = "my-name"

"Owner"       = "Owner"

"Project"     = "project-name"

"Provider"    = "Terraform"

}

~ task_definition                    = "arn:aws:ecs:us-east-1:my-account:task-definition/site-institucional-prd:19" -> "arn:aws:ecs:us-east-1:my-account:task-definition/site-institucional-prd:31"

# (14 unchanged attributes hidden)

Unless you have made equivalent changes to your configuration, or ignored the
relevant attributes using ignore_changes, the following plan may include
actions to undo or respond to these changes.
───────────────────────

Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:

+ create

~ update in-place

<= read (data resources)

Terraform will perform the following actions:

# module.wp.aws_ecs_service.service[0] will be updated in-place

~ resource "aws_ecs_service" "service" {

id                                 = "arn:aws:ecs:us-east-1:my-account:service/emprc-fgt-prd/site-institucional-prd-fgt"

name                               = "my-name"

tags                               = {

"Environment" = "prd"

"Name"        = "my-name"

"Owner"       = "Owner"

"Project"     = "project-name"

"Provider"    = "Terraform"

}

~ task_definition                    = "arn:aws:ecs:us-east-1:my-account:task-definition/site-institucional-prd:31" -> "arn:aws:ecs:us-east-1:my-account:task-definition/site-institucional-prd:19"

# (14 unchanged attributes hidden)

Я использую внутренний модуль terraform.

Это часть моего терраформа, где мы предоставляем сервис ECS на основе созданного нами модуля:

################################################################################
# ECS FARGATE
################################################################################

module "wp" {

source = "git::[email protected]:my-repo//terraform/aws-ecs/modules/fargate-service"

environment = var.environment

enabled = var.enabled

// variables task definition

container_name = var.container_name

enable_execute_command = var.enable_execute_command

task_container_image = var.task_container_image

task_definition_cpu    = var.task_definition_cpu

task_definition_memory = var.task_definition_memory

task_container_environment = var.task_container_environment

extra_container_defs = var.extra_container_defs

// variables service

vpc_id          = var.vpc_id

subnet_ids      = var.subnet_ids

security_groups = var.security_groups

service_name    = var.service_name

cluster_id = var.cluster_id

desired_count = var.desired_count

capacity_provider_strategy = var.capacity_provider_strategy

target_groups = var.target_groups

health_check = var.health_check

http_header = var.http_header

lb_arn       = var.lb_arn

host_header  = var.host_header

autoscale = var.autoscale

tags = var.tags
}

Вот результат моего плана терраформирования только с проблемной темой (в плане ниже я замаскирую некоторые значения):

- step:

oidc: true

name: Get task-definition

image: amazon/aws-cli:2.5.0

artifacts:

- task-definition.json

script:

- yum install jq -y

- export AWS_REGION=us-east-1

- export AWS_ROLE_ARN=arn:aws:iam::my-account:role/ci-ecs

- export AWS_WEB_IDENTITY_TOKEN_FILE=$(pwd)/web-identity-token

- echo $BITBUCKET_STEP_OIDC_TOKEN > $(pwd)/web-identity-token  

- TASK_DEFINITION=$(aws ecs describe-task-definition --task-definition site-institucional-prd) 

- ECR_IMAGE_TAG=145497587889.dkr.ecr.us-east-1.amazonaws.com/site-institucional-prd:${BITBUCKET_COMMIT}             

- NEW_TASK_DEFINTIION=$(echo "$TASK_DEFINITION" | jq --arg IMAGE "$ECR_IMAGE_TAG" '.taskDefinition | .containerDefinitions[0].image = $IMAGE | del(.taskDefinitionArn) | del(.revision) | del(.status) | del(.requiresAttributes) | del(.compatibilities) | del(.registeredAt) | del(.registeredBy)')

- echo $NEW_TASK_DEFINTIION > task-definition.json

- step:

oidc: true

name: Deploy to ECS

script:

- pipe: atlassian/aws-ecs-deploy:1.6.1

variables:

AWS_DEFAULT_REGION: 'us-east-1'

AWS_OIDC_ROLE_ARN: 'arn:aws:iam::my-account:role/ci-ecs'

CLUSTER_NAME: 'emprc-fgt-prd'

SERVICE_NAME: 'site-institucional-prd-fgt'

TASK_DEFINITION: 'task-definition.json'

Таким образом, развертывание новой версии (Wordpress) всегда выполняется с помощью конвейера Bitbucket после создания инфраструктуры. Теоретически мы не меняем инфраструктуру, но когда нам нужно что-то изменить в ней, номер версии определения задачи изменяется терраформом, который пытается принять ревизию в состоянии TF, которая устарела. Я понимаю, что это правильное поведение после того, как развертывание выполняется с помощью конвейера Bitbucket, но я хотел бы знать, есть ли способ сохранить активную текущую версию в ECS во время планирования/применения.

Спасибо за ваше время и поддержку.

#amazon-web-services #terraform #amazon-ecs #bitbucket-pipelines

Gfdtk1963


Рег
17 Jun, 2011

Тем
72

Постов
197

Баллов
577
  • 25, Oct 2024
  • #2

Из того, что я вижу в твоем плане терраформирования,

terraform apply --refresh-only
will indeed set the latest task definition version and probably run redeploy of your ECS.

Вы можете поддерживать актуальность файла состояния с помощью

terraform plan --refresh-only
to see the possible changes in infrastructure done manually, and if you are ok with it,
terraform apply
сохранит эти изменения в вашем файле состояния terraform.

Здесь есть еще информация по этому вопросу.

Надеюсь, это поможет

 

Tomorrowmc


Рег
25 Jan, 2014

Тем
80

Постов
195

Баллов
595
Тем
403,760
Комментарии
400,028
Опыт
2,418,908

Интересно