Почему ручные Terragrunt-настройки разъезжаются при росте окружений
Пока окружений два, terragrunt конфигурации держат копированием каталога. dev, stage и prod отличаются парой значений в переменных, а каждое новое окружение — копия предыдущего вместе с чужими настройками: адресом кластера, размером пула, политикой резервных копий. Через несколько релизов уже никто не помнит, почему в stage включён другой набор ресурсов, а в prod остался параметр из прошлого запуска.
Дальше начинается дрейф конфигурации инфраструктуры. Один сервис подключает модуль из актуальной ветки, другой закреплён на прежней, третий описывает ресурсы прямо внутри окружения и живёт отдельно от общего модуля. Правка в общем коде доезжает до части сервисов, и расхождение обнаруживается уже в облаке, а не на ревью.
Расхождение окружений всплывает при развёртывании: план показывает десятки изменений там, где ожидалась одна строка, а отказ при развёртывании приходит на этапе применения, когда часть ресурсов уже пересоздана. Такая ошибка воспроизводится только в одной среде, поэтому её не ловят ни тесты, ни проверки кода. Откат тоже не проходит одним запуском — состояние приходится разбирать вручную.
Корень не в самих файлах, а в управлении конфигурациями вручную: нет единого источника правды для параметров, нет общей версии модулей на все среды, нет проверки, которая поймает расхождение до применения. Разбираем, как это закрывается.
Что даёт единый слой описания инфраструктуры: меньше ручных правок
Terragrunt здесь не самоцель, а способ держать единый слой описания инфраструктуры: тестовый, предпродуктивный и продуктивный контуры собираются из одних модулей, а различия вынесены в параметры. Ниже — эффекты, которые видно по метрикам, а не по ощущениям.
Скорость поднятия окружения и восстановления
- Новый стенд под тест или нагрузочную проверку собирается из тех же модулей: время развёртывания окружения измеряется десятками минут вместо дней переписки и ручных шагов.
- Восстановление после сбоя — повторный запуск того же описания: стенд возвращается в известное состояние, а не «как получилось».
- Окружение снимается одной командой, поэтому временные стенды не живут месяцами и не копят расхождения с репозиторием.
Предсказуемость изменений и откат
- План изменений заранее показывает, что будет создано, изменено и удалено, поэтому снижение ручных правок видно по числу операций вне репозитория.
- Откат изменений инфраструктуры — возврат к предыдущему описанию: состояние приводится к нему тем же планом, без разбора ручных действий «по памяти».
- Повторяемость окружений держится на общих модулях: расхождения ловятся на этапе плана, а не в продуктивном контуре.
«Раньше стенд под нагрузочный тест поднимали два дня и половину правили руками — теперь это одна команда, и он повторяет продуктив один в один», — говорит наш инженер.
Terragrunt, рабочие пространства или модули: выбор для окружений
Когда конфигураций Terraform становится больше одной, появляется развилка: держать окружения в рабочих пространствах одного каталога, разводить их по каталогам с модулями или ставить сверху Terragrunt. От схемы организации конфигураций зависит, сколько стоит добавить новое окружение и как быстро разработка и продуктив начинают расходиться.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Рабочие пространства | Набор ресурсов один, окружения отличаются размерами и адресами | Общий файл состояния и провайдер: ошибка в разработке задевает продуктив |
| Каталоги и модули без обёртки | Состав ресурсов на окружение разный, сервисов немного | Бэкенды и переменные копируются вручную, каждый сервис — новый набор файлов |
| Terragrunt | Окружений и сервисов много, отличаются состав и параметры | Лишний слой абстракции: наследование и пути надо понимать, иначе ошибки в зависимостях |
Ограничения каждого варианта
Рабочие пространства экономят структуру каталогов, но не дают изоляции: один сбой плана или применения затрагивает все окружения сразу. Каталоги и модули изолируют надёжно, однако при росте числа сервисов поддерживать десятки почти одинаковых описаний становится дороже, чем сам сервис. Terragrunt снимает дублирование, но требует дисциплины: неверно собранный путь или порядок зависимостей проявляется только на применении.
Как выбирать при росте числа сервисов
До пяти-семи сервисов и двух окружений достаточно модулей с раздельными каталогами — предсказуемо и без лишних слоёв. Дальше критерий один: сколько ручных правок нужно, чтобы поднять новый сервис во всех окружениях. Если правки идут в нескольких местах, переходим на Terragrunt с общим набором модулей и окружением, заданным параметрами, — добавление сервиса сводится к одному описанию.
Этапы внедрения: аудит, схема, настройка, проверка, передача
Работа идёт последовательно — от инвентаризации до регламента, который остаётся у вашей команды. Terragrunt без такого порядка быстро превращается в ещё один слой копипаста поверх Terraform, поэтому структура и проверки проектируются вместе, а не по остаточному принципу.
Аудит и инвентаризация
- Аудит инфраструктурных конфигураций: собираем репозитории и файлы состояния, находим дубли описаний ресурсов, ручные правки в консоли провайдера и расхождения между окружениями.
- Проектирование структуры окружений: общий корневой файл с настройками хранилища состояния и провайдеров, отдельные каталоги под dev/stage/prod, переиспользуемые модули вместо копий.
- План перевода окружений: порядок миграции, перенос состояния без пересоздания живых ресурсов, точка отката на каждом шаге.
Проверка перед продуктивом
- Проверка инфраструктурных изменений: план в конвейере до применения, ревью вторым инженером, проверка формата и правил, запрет разрушающих операций без подтверждения.
- Прогон на копии продуктивного контура: окружение поднимается из снимка, план применяется, повторный план должен быть пустым, откат проверяется отдельно.
- Передача инфраструктуры команде: документация, регламент изменений, шаблон нового окружения, обучение инженеров и разграничение доступов.
После этого новый контур поднимается копированием каталога окружения и правкой переменных — без переписывания конфигураций и без ручных действий в консоли.
Что остаётся в репозитории: модули, каталоги, политики, регламенты
Передаём не набор разовых скриптов, а репозиторий, из которого окружение поднимается повторно: тот же прогон на чистом аккаунте даёт ту же инфраструктуру. Ниже — что именно лежит в поставке и как этим пользуются после запуска.
Состав репозитория
- Иерархия каталогов: окружение → регион → сервис. Новая площадка добавляется копированием уровня, модули править не нужно.
- Переиспользуемые модули с фиксированными версиями: сеть, кластеры, базы, балансировщики. Обновление — через смену версии, а не правку на живом контуре.
- Конфигурации Terragrunt: значения окружений вынесены в отдельные файлы, общая логика наследуется — расхождение между стендами видно при сравнении версий.
- Удалённое хранение состояния с блокировкой: параллельный запуск двух инженеров не портит состояние, история изменений доступна по каждому ресурсу.
- Разграничение доступа: чтение, предварительный просмотр и применение разделены; права на продуктивном контуре уже, чем на тестовом.
- Политики проверок до применения: запрет открытых портов, защита от удаления критичных ресурсов, обязательные метки владельца.
Документация и регламент изменений
- Регламент изменений: любое изменение проходит предварительный просмотр и проверку вторым инженером, применение — из общей ветки, а не с рабочей машины.
- Инструкция дежурной смене: как откатить релиз, где смотреть состояние, к кому идти при инциденте.
- Матрица доступов и карта репозитория на одной странице — новый инженер выходит в работу без устных пересказов.
Кейс: как развёртывание окружения перестало быть ручной работой
Заказчик — продуктовая команда, которая вела три окружения в одном облаке. Инфраструктура частично жила в конфигурациях, частично поднималась руками из консоли: воспроизвести стенд с нуля по репозиторию было невозможно.
Что было до
Развёртывание нового окружения занимало два дня и около 40 ручных шагов на двух инженеров. Каждый третий запуск заканчивался откатом — расхождения в именах и параметрах ресурсов всплывали только на этапе применения. Разбор одного такого сбоя занимал до четырёх часов ручного сравнения.
Что стало после
Мы разложили конфигурации на переиспользуемые модули и отдельные слои окружений, оставив в них только различия: размеры, зоны, переменные. Обёртку над конфигурациями — Terragrunt — настроили так, чтобы параметры подставлялись из одного места, а состояние каждого слоя хранилось отдельно.
Окружение поднимается одной командой за 20–25 минут, ручных шагов осталось три. Доля откатов снизилась с одной трети запусков до одного случая на двадцать, а возврат к предыдущему состоянию занимает минуты.
«Новый стенд под клиента мы собирали вдвоём и сдвигали сроки. Теперь его поднимает один инженер до обеда, и откатов из-за расхождений конфигураций у нас больше не было.» — технический директор заказчика
Чем Terragrunt отличается от рабочих пространств и когда он лишний
Рабочие пространства Terraform — это изолированные состояния внутри одной конфигурации. Один и тот же код разворачивается в dev, stage и prod, отличается только имя пространства, а переменные подставляются через файлы значений. Схема работает, пока окружения расходятся лишь параметрами: размером узлов, числом реплик, тегами.
Как только расходятся структура и адрес состояния, начинаются обходные пути. У рабочих пространств один backend на всю конфигурацию, поэтому хранилище состояния и провайдеры не задать по-разному для разных сред. Порядок применения модулей выстраивается вручную, а копипаст блока module с новыми путями становится главным источником расхождений между стендами.
Terragrunt — надстройка над Terraform, которая снимает эту ручную работу: генерирует блоки backend и provider перед запуском, держит состояние отдельно для каждого окружения, описывает зависимости между модулями и применяет их в правильном порядке. Цена — дополнительный слой: команда должна разобраться в языке шаблонов, а обновления версий идут по двум цепочкам сразу.
Граница применимости формулируется коротко. «Надстройка оправдана, когда окружения отличаются структурой и адресом состояния, а модулей больше десятка. Если стек один и всё помещается в пару модулей — это лишний слой, который придётся обслуживать», — говорит один из наших инженеров.
Практический критерий простой. Совпадает структура, различаются только переменные и масштаб — хватает встроенных рабочих пространств. Расходятся backend, состав модулей, версии провайдеров или нужен строгий порядок применения между слоями — встроенных средств уже мало, и надстройка окупает себя.
Сомнения по хранению состояния и доступам: разбираем по пунктам
Состояние — самая чувствительная часть схемы: если файл состояния потерян или перезаписан параллельным запуском, инструмент перестаёт видеть уже созданные ресурсы и предлагает создать их заново. Ниже — разбор сомнений, которые чаще всего возникают до старта.
Два инженера запустят изменения одновременно — состояние не сломается?
Состояние лежит в удалённом хранилище, блокировка берётся автоматически: второй запуск встаёт в ожидание или завершается ошибкой, а не пишет поверх. В Terragrunt состояние разложено по модулям, поэтому блокировка работает на уровне конкретного модуля, а не всей инфраструктуры — команды не блокируют друг друга на пустом месте.
Как разделить права доступа между командами?
Права раздаются ролями в облаке и путями в хранилище: команда пишет только в свои модули и окружения, чужое читает без возможности изменить. Секреты не попадают в репозиторий — подставляются из хранилища секретов на этапе запуска.
Что делать, если изменение нужно откатить?
Состояние версионируется, поэтому доступна предыдущая ревизия. Откат — это возврат конфигурации и построение плана: видно, какие ресурсы будут пересозданы, а какие изменены; перед применением план уходит на согласование.
Можно ли внедрять постепенно, не останавливая текущие процессы?
Да. Начинаем с одного контура рядом с существующей схемой, сверяем план с фактическим состоянием и убеждаемся, что расхождений нет. Только после этого переводим следующий контур — остальные процессы в это время работают как раньше.
Обсудим вашу схему окружений и вернёмся с оценкой и планом
Чтобы оценка внедрения была предметной, а не «на глазок», достаточно прислать то, что уже есть в репозиториях и в головах у команды: так видно, где конфигурации дублируются между средами, а где отличие действительно оправдано. Terragrunt в первую очередь убирает копипасту и разъезд параметров, поэтому без схемы окружений любая оценка будет приблизительной.
- Схема окружений: сколько сред, чем они отличаются, что обязано оставаться общим — регионы, размеры, набор сервисов.
- Текущие конфигурации Terraform: структура каталогов, где хранится состояние, как подключены провайдеры и модули.
- Работа с секретами: что лежит открыто, где хранится, что должно подставляться на этапе применения.
- Требования к доступам: кому нужен доступ к продуктивной среде, кто его выдаёт, как ведётся журнал изменений.
- Правила версионирования модулей и провайдеров: фиксируются ли версии, как проходит обновление и откат.
- Порядок выпуска: конвейер сборки, ручные шаги, окна изменений, кто подтверждает применение.
- Ожидаемый результат: какие части должны стать воспроизводимыми, а что останется ручным исключением.
После обсуждения задачи мы возвращаемся с планом работ: разбор репозитория, пилот на одной среде, перенос остальных на общий корень с модулями, передача документации и обучение команды. Порядок работы с подрядчиком прозрачный — каждый этап заканчивается проверяемым результатом в вашей инфраструктуре, а не отчётом о проделанном.
Опишите задачу в свободной форме и приложите то, что есть: вернёмся с оценкой, планом и границами работ.
