🔫 Не автоматизация, а русская рулетка

--auto-approve убирает единственную паузу, которую Terraform делает перед тем, как что-то сломать — подтверждение плана. Именно там человек видит «1 to destroy» и успевает остановиться. Без этой паузы план исполняется немедленно.

Разработчик переносит ресурс из инлайн-определения в shared module. Имя ресурса меняется. Terraform видит это как «уничтожить старый, создать новый» и это корректная логика. CI-пайплайн с --auto-approve не даёт никому это увидеть до того, как база уже удалена.

# Без --auto-approve вы бы увидели это и остановились:
  ~ aws_security_group.web      # изменить — окей
  + aws_cloudwatch_alarm.cpu    # добавить — окей
  - aws_db_instance.primary     # УДАЛИТЬ — стоп

# С --auto-approve это уже исполняется, пока вы читаете телегу

Что делать вместо этого

Разделить plan и apply на два шага:

# Шаг 1 — сохранить план
terraform plan -out=plan.tfplan

# Шаг 2 — проверить на деструктивные операции
terraform show -json plan.tfplan | \
  jq '[.resource_changes[]? | select(.change.actions[] == "delete")]'

# Шаг 3 — применить именно этот план, без новых сюрпризов
terraform apply plan.tfplan

Добавить prevent_destroy для критичных ресурсов:

resource "aws_db_instance" "primary" {
  # ...
  lifecycle {
    prevent_destroy = true
  }
}

Terraform упадёт с ошибкой ещё на этапе плана до того, как что-либо будет удалено.

Когда --auto-approve допустим

Только для эфемерной инфраструктуры: тестовые окружения, которые поднимаются и сносятся в рамках одного CI-прогона, sandbox-окружения без реальных данных.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#арсенал_инженера