Terraform State — механизм, через который Terraform отслеживает состояние реальных ресурсов инфраструктуры. Файл terraform.tfstate (JSON) создаётся после первого terraform apply и обновляется при каждом изменении. Без state Terraform не знал бы, какие ресурсы уже существуют и что нужно создать, изменить или удалить.
Как работает
State хранит маппинг: Terraform-ресурс → реальный объект в облаке. Пример: ресурс aws_instance.web в конфигурации соответствует инстансу EC2 с ID i-0a1b2c3d4e5f67890. При следующем terraform plan Terraform сравнивает конфигурацию с state и реальным состоянием ресурса (refresh), вычисляя дельту изменений.
Режимы хранения state:
- Local — по умолчанию, файл
terraform.tfstateв рабочей директории. Не подходит для команды: нет блокировки, нет версионирования. - Remote backend — state хранится в удалённом хранилище с поддержкой locking и versioning.
Популярные remote backends:
- AWS S3 + DynamoDB — S3 хранит state, DynamoDB обеспечивает locking через LockItem. С Terraform 1.10+ S3 поддерживает native locking без DynamoDB.
- Terraform Cloud / HCP Terraform — managed-решение от HashiCorp с UI, RBAC, аудит-логами.
- Azure Blob Storage — аналог S3 для Azure.
- GCS (Google Cloud Storage) — для GCP-инфраструктуры.
- HTTP backend — любой HTTP-сервис, поддерживающий GET/POST/DELETE (например, GitLab Terraform State).
Блокировка (State Locking) — механизм предотвращения одновременного изменения state двумя операторами. При terraform apply Terraform запрашивает lock; если lock занят — ожидает или выдаёт ошибку.
State может содержать чувствительные данные (пароли, API-ключи в outputs). Шифруйте state в rest: S3 server-side encryption (SSE-S3 или SSE-KMS).
История
Terraform разработан HashiCorp и выпущен в 2014 году. State-файл был частью Terraform с самого начала как решение проблемы идемпотентности: без него каждый apply создавал бы ресурсы заново. Remote backends появились в версии 0.9 (2017). Terraform Cloud с managed state вышел в 2019 году. Версия 1.0 (2021) зафиксировала стабильность API state-формата.
На что обращать внимание
Никогда не редактируйте terraform.tfstate вручную — только через terraform state mv, terraform state rm, terraform import. Добавляйте terraform.tfstate в .gitignore при локальном хранении (содержит секреты). При потере state используйте terraform import для восстановления маппинга существующих ресурсов. Для больших инфраструктур разделяйте state по слоям (сеть, вычисления, БД) через workspaces или отдельные конфигурации — монолитный state с 500+ ресурсов медленно рефрешится.
Практические примеры работы с Terraform State
terraform state list # список ресурсов в state
terraform state show aws_instance.web # детали ресурса
terraform state mv old_name new_name # переименование ресурса в state
terraform state rm aws_instance.old # удалить из state (без удаления ресурса)
terraform import aws_instance.web i-1234567 # импортировать существующий ресурсХранение Terraform State для хостинговой инфраструктуры
Remote state — стандарт для командной работы. Backends: S3 + DynamoDB (AWS), GCS (Google), Azure Blob, Terraform Cloud, GitLab. На VPS-инфраструктуре используйте S3-совместимое хранилище (Hetzner Object Storage, VK Cloud S3) + блокировка через PostgreSQL или Redis. Terraform state содержит все параметры ресурсов включая sensitive data (пароли, ключи) — шифруйте хранилище.
Типичные ошибки
- State в git-репозитории: sensitive данные в открытом виде + конфликты при командной работе.
- Ручное редактирование state-файла: используйте только
terraform stateкоманды. - Отсутствие state locking: параллельный
terraform applyдвух разработчиков повреждает state. - Не настроены версионирование и backup S3-бакета со state — потеря state = пересоздание всей инфраструктуры.