Чому ручні 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: структура каталогів, де зберігається стан, як підключені провайдери й модулі.
- Робота із секретами: що лежить відкрито, де зберігається, що має підставлятися на етапі застосування.
- Вимоги до доступів: кому потрібен доступ до продуктивного середовища, хто його видає, як ведеться журнал змін.
- Правила версіонування модулів і провайдерів: чи фіксуються версії, як проходить оновлення та відкат.
- Порядок випуску: конвеєр збірки, ручні кроки, вікна змін, хто підтверджує застосування.
- Очікуваний результат: які частини мають стати відтворюваними, а що залишиться ручним винятком.
Після обговорення задачі ми повертаємося з планом робіт: розбір репозиторію, пілот на одному середовищі, перенесення решти на спільний корінь із модулями, передача документації та навчання команди.
Порядок роботи з підрядником прозорий — кожен етап закінчується перевірюваним результатом у вашій інфраструктурі, а не звітом про виконане.
Опишіть задачу у вільній формі та додайте те, що є: повернемося з оцінкою, планом і межами робіт.
