Зачем Terraform нужен state-файл? Как организовать работу со state в команде и что делать при его рассинхронизации с реальностью?
Короткий ответ
- State — соответствие между кодом и реальными ресурсами
- Без него Terraform не знает, чем управляет и что менять
- В команде — только remote backend с блокировками (S3, Terraform Cloud)
- State содержит секреты, его нужно шифровать и ограничивать доступ
- Дрифт: ручные правки в облаке расходятся с кодом
- Инструменты починки: refresh, import, state mv/rm, moved-блоки
State — источник знаний Terraform о реальных ресурсах, и в команде он живёт только в remote-бэкенде с блокировками.
Как сказать вслух
пример ответаState хранит соответствие между ресурсами в коде и их реальными идентификаторами в облаке — без него Terraform не смог бы посчитать план изменений. В команде локальный state недопустим: используем удалённый бэкенд, например S3 с блокировками, чтобы два человека не применяли изменения одновременно. Если кто-то поправил инфраструктуру руками, возникает дрифт — его видно в плане, а чинится он импортом ресурса или правкой state. Ещё важно помнить, что в state попадают секреты, поэтому доступ к нему ограничиваем.
Подробный ответ
Основной ответ
Terraform сравнивает три вещи: конфигурацию, state и фактическое состояние провайдера (через refresh), и на этой основе строит план. State хранит ID ресурсов, их атрибуты и зависимости. Командная работа: remote backend (S3 с блокировкой — с версии 1.10 через нативный S3-locking, Terraform Cloud, GitLab-managed state) с версионированием и шифрованием; разбиение на независимые конфигурации по окружениям и слоям, чтобы уменьшить blast radius и очереди на lock; применение только через CI, а не с ноутбуков. Рассинхронизация: ручные изменения ловятся плановым terraform plan -detailed-exitcode (drift detection); ресурс, созданный вне Terraform, подключается через import; переименования в коде — через moved-блоки или terraform state mv; удаление из управления — state rm.
Ключевые моменты
- Зачем state. Привязка ресурсов кода к реальным объектам и кэш атрибутов; без него невозможен корректный план и удаление.
- Remote backend и lock. Блокировка защищает от параллельных apply; версионирование бэкенда спасает при порче state.
- Секреты в state. Пароли и ключи лежат в state открытым текстом — шифрование на стороне хранилища и строгий доступ обязательны.
- Работа с дрифтом. Регулярный plan в CI как детектор дрифта; import и moved — штатные инструменты починки без пересоздания.
Практический контекст
Вопрос про state — главный фильтр на реальный опыт с Terraform: кто работал только в одиночку, обычно плавает в блокировках и дрифте. В работе это ежедневная рутина: ревью планов в CI, разбор конфликтов state, импорт «исторических» ресурсов. Интервьюер может дать сценарий «коллега удалил ресурс руками в консоли — что покажет plan и что вы сделаете».
Частые ошибки
- Хранят state в git рядом с кодом и не видят в этом проблемы
- Не знают про блокировки и риск параллельного apply
- При любом дрифте предлагают пересоздать ресурсы вместо import/state mv