Terraform state file испортился как восстановить и не потерять инфраструктуру

[cachego9376]

Случилась неприятность: в процессе terraform apply упало соединение, и теперь terraform.tfstate частично обновлён, а реальная инфраструктура в AWS не соответствует стейту. При запуске plan видит ресурсы как новые и хочет их пересоздать, хотя они уже существуют. Бэкапа стейта нет (знаю, знаю). Как выйти из этой ситуации без сноса всего?

[secproxy7089]

Первым делом — terraform state list чтобы увидеть что terraform вообще знает. Потом terraform state show <resource> для проблемных ресурсов. Если ресурс в AWS есть, но в стейте его нет — используй terraform import <resource_type>.<name> <cloud_id>. Например, terraform import aws_instance.web i-0abc123def456. Это добавит существующий ресурс в стейт без пересоздания.

[stas_api]

Для S3 бакетов: terraform import aws_s3_bucket.my_bucket my-bucket-name. Для большинства AWS-ресурсов import работает, только надо знать правильный формат ID — он в документации к каждому ресурсу. После импорта запускай plan и смотри diff — обычно Terraform хочет поменять пару тегов или атрибутов, которые не совпадают с кодом.

[zhenya_docker]

После того как разгребёшь — сразу настрой remote state в S3 с версионированием: terraform { backend "s3" { bucket = "my-tf-state" key = "prod/terraform.tfstate" region = "eu-west-1" versioning = true } }. И добавь DynamoDB table для state locking — это предотвратит одновременные apply от разных людей. Это должно быть стандартом, а не опцией.

[svetlana_js]

Развёрнутый алгоритм восстановления. Шаг 1 — сделай резервную копию текущего побитого стейта: cp terraform.tfstate terraform.tfstate.broken.bak. Шаг 2 — если был автоматический бэкап (terraform.tfstate.backup), посмотри его содержимое — иногда он актуальнее. Шаг 3 — для каждого ресурса который Terraform хочет пересоздать, проверь через AWS Console или CLI существует ли он реально. Шаг 4 — если ресурс существует, импортируй его командой terraform import. Шаг 5 — запусти terraform plan и внимательно читай diff. Атрибуты вроде tags, description обычно можно безболезненно обновить. Если plan хочет удалить и пересоздать ресурс (forces replacement) — разберись почему, часто это из-за неизменяемых атрибутов типа ami или subnet_id. Шаг 6 — terraform apply только когда план выглядит адекватно. Шаг 7 — после успеха немедленно переходи на remote state с версионированием. Урок на будущее: terraform workspace и remote backends с версионированием — это не опциональные фичи.

[ruslan_pro]

Ещё совет: terraform refresh обновляет стейт из реального состояния облака. Но осторожно — в Terraform 0.15+ его поведение изменили и он может сделать неожиданные вещи. Сначала читай доку для своей версии.

[startup_founder]

У нас в компании после похожего инцидента ввели правило: никакого прямого apply в продакшне без peer review плана в PR. Весь Terraform через Atlantis — он автоматически делает plan на каждый PR и apply только после мержа. Порядка стало значительно больше.