how/state

state mv, state rm, import - императивные операции на state

Три команды, которые правят state-файл напрямую: переименовать запись, забыть ресурс, всосать существующий из облака. Что меняют, чего не меняют, чем опасны.

terraform.tfstate - кэш Terraform, и обычно к нему не приходится лезть руками. Apply сам всё прописывает, refresh сам всё обновляет.

Но бывают случаи, когда state и HCL расходятся по адресам, а не по значениям:

ты переименовал ресурс в HCL - для Terraform это «удалить старый, создать новый», и облако перестроится зря.
ты выпиливаешь модуль из управления - но физические ресурсы должны пережить это, их трогать нельзя.
кто-то создал бакет руками в AWS Console год назад - и теперь надо привести его под Terraform, но без destroy-and-recreate.

Под каждый случай есть команда: state mv, state rm, import. Все три императивные: меняют state на месте, HCL остаётся за тобой. Жми ▶ - посмотрим, что каждая делает с треугольником HCL/state/cloud.

step 1/5·00 · базовая позиция

§ шаги

Один S3-бакет описан в HCL как aws_s3_bucket.old, в state есть запись с id linuxlab-3f4a, в AWS висит бакет ровно с таким id. Все три источника согласны.

С этой точки разойдёмся в три стороны: переименуем, удалим, импортируем.

итого

Что важно про эти три операции:

Все три меняют state, не облако. Физические ресурсы AWS они не трогают вообще.
Все три - императивные. Запускаешь руками, на конкретный адрес, результат не воспроизводится из HCL. Это значит - не повторяется в CI, не виден в git-истории.
Это делает их аварийным инструментом. В обычном workflow к ним не обращаются.

Когда их можно и нужно:

state mv - переименовать ресурс или переехать в другой модуль без пересоздания. Самый частый случай.
state rm - отдать ресурс другой команде или сторонней системе. Бакет остаётся жить, Terraform просто перестаёт за ним следить. Часто пара к terraform import у второго владельца.
terraform import - затащить под управление давно существующий ресурс. Альтернатива - переcоздавать с нуля, что для prod-данных редко возможно.

Подводные камни:

state rm не предупреждает про зависимости. Если ты удалил из state ресурс, от которого зависят другие, - все они после plan начнут пугать «надо создать заново».
terraform import приносит в state только id. Атрибуты (теги, политики, encryption) нужно вручную прописать в HCL, потом plan должен показать No changes. Если показывает - состояние не совпадает с тем, что ты описал.

В Terraform 1.5+ появились декларативные аналоги: moved, removed, import блоки. Они воспроизводимы и живут в git. Это тема следующего explainer'а: tf-moved-removed-import-blocks.

§ копнуть в базу знаний

§ попробовать руками

§ шаги

Один S3-бакет описан в HCL как aws_s3_bucket.old, в state есть запись с id linuxlab-3f4a, в AWS висит бакет ровно с таким id. Все три источника согласны.

С этой точки разойдёмся в три стороны: переименуем, удалим, импортируем.