Два CI-джоба почти одновременно запустили terraform apply на один и тот же remote state, и второй завис с ошибкой Error acquiring the state lock, а первый после этого аварийно упал по таймауту раннера, не освободив лок. Что такое state locking в Terraform, зачем он нужен и как безопасно разблокировать state в этой ситуации?

Короткий ответ

State locking — это механизм, которым Terraform блокирует state в remote backend на время plan/apply, чтобы два процесса не писали в него параллельно и не повредили данные; если лок «подвис» из-за аварийного завершения процесса, нужно убедиться, что никакой apply реально не выполняется, и снять именно этот лок командой terraform force-unlock <LOCK_ID>, а не трогать state вручную.

Как это работает подробнее

backend с поддержкой locking (например, S3 backend с таблицей DynamoDB для блокировок, или Terraform Cloud/Consul) перед изменением state создаёт отдельную запись-лок с идентификатором операции, временем и информацией о том, кто её запустил; любой другой процесс, пытающийся получить тот же лок, получает отказ и сообщение с LOCK ID, пока запись не удалена.

Пример кода

commands.shКопировать

$ terraform apply
Error acquiring the state lock
Lock Info:
  ID:        7c4d1a2e-91f3-4b2a-9a7e-1a2b3c4d5e6f
  Path:      env/prod/terraform.tfstate
  Operation: OpenTofu/Terraform apply
  Who:       ci-runner-42
  Created:   2026-10-04 12:01:03 UTC
# после подтверждения, что ci-runner-42 действительно мёртв:
$ terraform force-unlock 7c4d1a2e-91f3-4b2a-9a7e-1a2b3c4d5e6f

Что использовать на практике

• Практика. перед force-unlock нужно проверить в самой системе хранения лока (например, в таблице DynamoDB или в логах CI) статус первого джоба и убедиться, что его процесс действительно завершён, а не просто «долго думает»; после подтверждения выполняется terraform force-unlock <LOCK_ID> с указанием точного идентификатора, а не массовая очистка; в команде это стоит сопровождать алертом в CI, чтобы зависшие локи не оставались незамеченными.

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

• Ошибка. частая ошибка — снимать лок «на всякий случай», пока первый apply физически ещё работает, из-за чего два apply одновременно пишут в один state и он повреждается; другая ошибка — хранить state локально без backend с locking при работе нескольких инженеров или CI-джобов, из-за чего блокировки вообще не возникает и гонка состояний остаётся незамеченной до тех пор, пока не испортится реальная инфраструктура.