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

[lover_denis]

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

[Austkin]

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

[seniorwarlock]

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

[tiger71]

После того как разгребёшь — сразу настрой 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 от разных людей. Это должно быть стандартом, а не опцией.

[susanne]

Развёрнутый алгоритм восстановления. Шаг 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 с версионированием — это не опциональные фичи.

[infern]

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

[lorenzinoarq]

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

[lonelygoblin]

Если Terraform свежее 1.5 — не мучайтесь с terraform import по одному ресурсу из консоли. Есть import-блоки прямо в коде: пишешь блок с to и id, потом plan -generate-config-out, и Terraform сам генерит конфигурацию под существующий ресурс. Когда после оборванного apply осиротело два десятка ресурсов, это в разы быстрее, чем после каждого импорта руками сверять разъехавшиеся атрибуты. Плюс import-блоки попадают в код-ревью, в отличие от команд в терминале.

[Sdgator]

@tiger71, маленькая, но коварная правка: versioning = true внутри блока backend "s3" не существует, Terraform такой аргумент не примет. Версионирование включается на самом бакете, отдельно. И DynamoDB для локов уже не обязателен — у S3-бэкенда появился use_lockfile, лок кладётся в тот же бакет рядом со стейтом. Одной движущейся частью в схеме меньше.

[jackdd]

@infern, дополню про refresh: в свежих версиях безопаснее terraform plan -refresh-only — он сначала показывает, что именно разъехалось между стейтом и облаком, и ничего не трогает, пока не подтвердишь apply -refresh-only. Голый refresh в ситуации с уже побитым стейтом может молча перезаписать то, что ещё можно было сравнить с бэкапом.