- 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