Terraform State Locking: DynamoDB и Consul

Почему Terraform state locking ломается при параллельной работе

Terraform держит карту управляемых ресурсов в файле состояния и строит план изменений от его текущей версии. Пока применяет один инженер, всё сходится. При двух параллельных применениях сходятся не оба — и признак поломки всплывает не в логах, а в облаке.

Механизм terraform state locking закрывает ровно этот случай: перед применением процесс занимает блокировку, второй ждёт или останавливается с сообщением, что замок уже взят. В объектном хранилище замком служит таблица DynamoDB с идентификатором блокировки, в Consul — сессия с ограниченным временем жизни. Гарантия одна: с описанием инфраструктуры работает ровно один процесс.

Конфликт одновременного применения начинается там, где блокировка не настроена или не удержана: есть адрес хранилища, но нет таблицы замка; у инженера нет прав записи в неё; у локальной машины и сборочного агента разные учётные данные; время жизни сессии истекло на длинном применении. Отдельно — снятие замка вручную после падения процесса, без проверки, что запись состояния завершена.

Тогда оба процесса читают одну версию состояния и строят план от неё; первый записывает результат, второй — поверх него своё, собранное из устаревших данных. Ресурсы первого из описания выпадают: в облаке они живут и тарифицируются, а Terraform считает, что их нет.

Это повреждённый файл состояния — не битый байтами, а неполный по смыслу. Он же даёт рассинхронизацию: следующий запуск пытается создать занятые имена или пересоздаёт рабочие узлы, а откатиться нечем, если в хранилище не включено версионирование. Разбираем, как это закрывается.

Что даёт управляемая блокировка состояния команде

Блокировка состояния — это распределённая аренда на запись. Перед применением плана Terraform ставит в общее хранилище метку владельца — строку в таблице DynamoDB или ключ блокировки в Consul — и снимает её только после завершения операции. Второй инженер видит, кто и какую операцию держит, вместо того чтобы молча перезаписать чужой результат.

Без аренды два одновременных применения сходятся в один файл состояния: часть ресурсов остаётся вне описания, часть описана дважды. Рассинхрон разбирают вручную по журналам провайдера — на это уходит ночь вместо десяти минут.

Как сокращается время подготовки изменения инфраструктуры

Инженер работает с достоверной картиной, а не с состоянием, которое кто-то правил параллельно, поэтому план не приходится пересобирать и сверять вручную. Ожидание очереди видно в выводе команды и измеряется секундами; на команде из нескольких человек изменение проходит с первого применения, без откатов на повторную подготовку.

Какой класс отказов уходит из ежедневной работы

Уходит самый дорогой по времени восстановления сценарий — потерянный или частично перезаписанный файл состояния, который восстанавливают по логам и импортом ресурсов вручную. Автоматическое истечение аренды закрывает вторую половину: если инженер потерял доступ, метка снимается по таймауту и не остаётся вечным стопом для всей команды.

Варианты блокировки состояния: сравнение режимов работы

Блокировка состояния — это распределённая блокировка записи в файл состояния: перед планированием или применением процесс захватывает её, а остальные запуски ждут либо падают с внятной ошибкой. В Terraform механизм включается на уровне бэкенда, поэтому выбор варианта — это выбор хранилища блокировок, а не надстройки над ним.

Блокировка через управляемый сервис DynamoDB

Таблица с ключом по имени состояния, условная запись и поле времени жизни — блокировка ставится атомарно, а сервис не нужно поднимать и обслуживать самому. Права выдаются политикой доступа, содержимое таблицы читается глазами, что упрощает разбор зависших запусков. Ограничение механизма: если процесс оборвался, признак блокировки остаётся и снимается отдельной командой вручную.

Блокировка через Consul

Сессия привязана к агенту: агент упал — ключ освободился сам, ручное вмешательство не требуется. Это удобно, если Consul уже обслуживается в контуре: не появляется вторая облачная привязка и второй набор прав доступа. Цена — сопровождение кластера: кворум, резервные копии, обновления.

Общее ограничение всех вариантов: блокировка защищает от одновременной записи, но не от порчи самого состояния — версионирование хранилища и регулярные копии остаются обязательными.

Этапы внедрения блокировки состояния в команду

Блокировка состояния — не опция «включить и забыть»: она меняет порядок работы команды, поэтому внедряем её последовательно. Ниже — маршрут настройки для случая, когда состоянием пользуется больше одного инженера или конвейер сборки.

Аудит текущего состояния и точек одновременного применения

1. Собираем карту бэкендов. Фиксируем, где лежит файл состояния, кто и из каких сред к нему обращается, есть ли запуски мимо конвейера.
2. Ищем точки одновременного применения. По журналам и опросу команды отмечаем, где параллельные запуски уже давали конфликт или портили состояние.
3. Определяем требования. Число команд, разграничение доступа, срок жизни блокировки, поведение при обрыве связи — от этого зависит выбор хранилища.

Настройка и проверка на учебном контуре

• Разворачиваем хранилище блокировок. Таблица в DynamoDB или кластер Consul с политиками доступа и сроком аренды блокировки.
• Переносим бэкенд. Переводим состояние и проверяем, что чтение и запись идут через новое хранилище, а откат остаётся возможным.
• Проверяем блокировку под нагрузкой. Два параллельных применения: одно получает блокировку, второе корректно останавливается с понятным сообщением.
• Передаём решение команде. Регламент конфликтов, инструкция по снятию зависшей блокировки, обучение инженеров и ответственный за дежурство.

На рабочем контуре это закрывает класс отказов, когда два применения переписывают состояние и инфраструктура расходится с конфигурацией.

Конфигурации, схемы и регламенты, которые остаются у вас

После внедрения у вас остаётся не только работающая инфраструктура, но и комплект артефактов, по которым её можно развивать без нашего участия. Всё лежит в системе контроля версий, изменения проходят проверку до применения, а принятые решения зафиксированы рядом с кодом — новый инженер входит в проект без устных пересказов.

Схема взаимодействия и описание прав доступа

• Схема взаимодействия: какие сервисы зависят друг от друга, где проходят границы сетей, что произойдёт с системой при отказе отдельного узла.
• Политики доступа: роли и разрешения по принципу минимально необходимых, отдельно для людей и отдельно для автоматизации.
• Описание хранения состояния: где лежит файл состояния Terraform, какой механизм блокировки защищает от одновременных изменений и как он ведёт себя при обрыве связи.
• Карта внешних зависимостей: реестры образов, хранилища секретов, точки входа — с указанием ответственных.

Регламент работы с состоянием и инструкции для команды

• Регламент работы с состоянием: кто и как снимает блокировку, что делать при конфликте и как восстановить состояние из резервной копии.
• Инструкции по развёртыванию и откату: пошаговые, проверенные на тестовом контуре.
• Соглашения по структуре конфигураций: разбиение на модули, именование ресурсов, правила хранения секретов.
• Чек-листы типовых операций: подключение новой среды, вывод узла из эксплуатации, ротация ключей и доступов.

Кейс: как мы убрали конфликтные применения состояния

Проект — инфраструктура из нескольких сред, шесть инженеров и около сорока изменений в неделю. Состояние лежало в одном бэкенде без блокировки: два одновременных применения — из ветки и с локальной машины — переписывали один и тот же файл. Итог: расхождение состояния с реальностью, «осиротевшие» ресурсы и ручной разбор вместо работы.

Перевели состояние на удалённый бэкенд с блокировкой: Terraform берёт блокировку в таблице DynamoDB перед планированием и снимает её после применения, на второй площадке координатором работает Consul. Важнее самой блокировки оказалось правило разбора: при занятой блокировке инженер видит её владельца и снимает её только после проверки, что процесс действительно не идёт.

Что изменилось в ежедневной работе команды

До: в среднем два расхождения состояния в неделю, разбор — от сорока минут до нескольких часов; один раз восстановление из резервной копии заняло половину рабочего дня. После: за девять месяцев — ни одного конфликтного применения, а время применения сократилось с двадцати одной до девяти минут за счёт исчезнувших повторных прогонов и ожидания.

Ушёл целый класс отказов: перезапись состояния и ресурсы, которые есть в облаке, но отсутствуют в файле. Изменения стали мельче и чаще — это перестало быть риском.

Чем отличается state locking в DynamoDB и Consul?

Оба механизма решают одну задачу: не допустить, чтобы два запуска одновременно переписали state и оставили инфраструктуру в полуприменённом виде. Разница — в том, где живёт замок, кто его снимает при сбое и что придётся сопровождать, чтобы блокировка сама не стала источником инцидентов.

DynamoDB — это блокировка записью: перед изменением Terraform делает условную запись в таблице с идентификатором запуска, и параллельная попытка получает отказ. Таблицу и права к ней нужно создать и поддерживать, зато отдельный кластер не нужен — всё живёт там же, где state. Поведение при сбое жёсткое: если процесс оборвался или агент умер, запись остаётся, и снять её можно только принудительно. До этого момента все сборки стоят.

Consul — блокировка на сессиях: агент открывает сессию с ограниченным сроком и постоянно её продлевает, замок привязан к сессии и освобождается сам, когда продление прекратилось. Ручное вмешательство при падении агента не требуется, но за это платят сопровождением: нужен отказоустойчивый кластер, токены доступа, контроль за агентами. Есть и обратный риск — при сетевом сбое продление не проходит, и замок снимается под всё ещё работающим apply, если срок сессии выставлен меньше самого долгого применения.

Практический критерий выбора — уже развёрнутая инфраструктура. Там, где state и нагрузки живут в облаке, DynamoDB добавляет одну таблицу и ничего больше; поднимать Consul только ради блокировки — лишний кластер в сопровождении. Если же Consul уже обслуживает обнаружение сервисов, блокировка достаётся без новой инфраструктуры. В обоих случаях срок сессии подбирают под максимальный apply, а порядок снятия зависших замков прописывают заранее — чтобы не выяснять его в момент остановленного конвейера.

Технические сомнения по блокировке состояния

Блокировка состояния защищает от ситуации, когда два применения одновременно пишут в один файл. На старте она почти не вызывает вопросов — они появляются в эксплуатации: снять зависшую блокировку, сменить хранилище, договориться о правилах для тех, кто работает локально.

Как перейти с одного хранилища блокировок на другое без простоя?

Переход делаем в два шага: сначала переносим файл состояния и проверяем, что план совпадает с реальной инфраструктурой, затем меняем настройки блокировки и закрываем старый контур на запись. Новый механизм заранее прогоняем в отдельном окружении — в том числе сценарий одновременного запуска.

Часть команды применяет конфигурацию локально — это допустимо?

Локальные копии состояния — тупик: изменения на машине одного инженера не видны остальным, а расхождения всплывают при следующем общем применении. Допустим один вариант — локальные запуски работают с общим состоянием и блокировкой. Эксперименты выносим в отдельные окружения с изолированным состоянием.

Как разбирать инцидент, если состояние уже повредили?

Фиксируем точку: версию файла состояния из хранилища и историю изменений. Дальше сверяем ресурсы планом, возвращаем в состояние пропавшие объекты и убираем лишние записи. После — защита от принудительного снятия блокировки и запрет применений из локальных копий.

Обсудим задачу: подберём схему блокировки под вашу команду

Блокировку состояния нельзя настраивать по шаблону: одна и та же схема на двух инженерах и на двадцати даёт разный результат. Поэтому до оценки и плана работ мы разбираем ваш контур и условия эксплуатации, а не предлагаем готовое решение из каталога.

• Сколько инженеров одновременно работают с состоянием и есть ли автоматические запуски — от этого зависит, насколько чувствительной должна быть блокировка к конфликтам.
• Как часто меняется инфраструктура: редкие правки и непрерывный поток изменений требуют разного времени удержания блокировки и разной реакции на зависшие случаи.
• Какой механизм используется сейчас — локальный файл, блокировка в облачном хранилище или Consul — и какие сбои уже приводили к расхождению состояния.
• Права и доступы: кто имеет право снять зависшую блокировку, как это фиксируется в журналах и кто получает уведомление о снятии.
• Нужна ли изоляция по контурам — тестовый, предпродуктивный и промышленный блокируются отдельно или одним механизмом с разграничением доступа.
• Порядок передачи решения: конфигурации, схема работы, регламент снятия блокировки и инструкция для дежурного инженера.

Опишите задачу в общих чертах — вернёмся с оценкой и планом работ и подберём схему блокировки под вашу команду.

• Блокировку не включают вовсе. Применение запускают и с рабочей машины, и из сборочной системы, а иногда просто из двух окон сразу. Пока один процесс пишет состояние, второй читает устаревшую копию — итог виден только в момент, когда часть ресурсов уже пересоздана не тем, кто планировал.

• Блокировку снимают вручную при первой же задержке. Кто-то ждёт дольше пары минут, идёт в хранилище и удаляет запись блокировки, не проверив, жив ли удерживающий её процесс. Так из редкой задержки делают гарантированный конфликт двух одновременных применений.

• Нет срока жизни и автоматической очистки устаревших блокировок. После аварийного завершения процесса запись остаётся висеть, и работа команды встаёт до ручного вмешательства. Если это происходит в конце дня, простой растягивается на часы и не имеет отношения к самой инфраструктуре.

• Всё состояние свалено в один участок. Разные команды и продукты работают с общим состоянием, поэтому любое изменение ждёт чужих задач, а блокировка превращается в очередь. Разделение по областям не сделали заранее — и теперь боятся его делать, потому что переезд затрагивает живую систему.

• У сборочной системы нет нужных прав. Она может читать состояние, но не может снять устаревшую блокировку или записать новую. В итоге автоматические применения останавливаются, а разблокировка снова уходит на человека с расширенными правами.

• Часть инженеров держит состояние локально. Работы идут мимо общего хранилища, и блокировка на них просто не распространяется. Формально механизм внедрён, фактически — защищает только тех, кто им пользуется.

• Не ведут журнал блокировок. Не видно, кто и когда удерживал состояние и почему применение не проходило. Разбор конфликта превращается в переписку с догадками вместо поиска по истории событий.

• Обходят блокировку правкой состояния напрямую. Правки в хранилище руками или через обходные скрипты ломают и целостность состояния, и саму идею управляемой блокировки: следующий же запуск видит расхождение и пытается «починить» его пересозданием ресурсов.