Налаштування GitOps для Terraform State: Atlantis і робочий процес

GitOps Terraform: чому стан розходиться з кодом

Стан описує те, що вже створено в хмарі, а код — те, що має бути.

Поки між ними стоїть лише дисципліна, розходження з'являється швидко: доступ знадобився терміново, інженер править правило балансувальника або розмір диска прямо в консолі, а в описі інфраструктури це не відображається.

Через тиждень наступне застосування повертає все до попереднього вигляду — і ламає те, що ремонтували руками.

Друге джерело дрейфу — сам файл стану. Це єдиний змінюваний артефакт, і без коректного блокування два одночасні застосування перетирають записи одне одного: частина ресурсів залишається в стані, частина губиться.

Сховище на локальній машині посилює проблему — стан існує в одному екземплярі в однієї людини, і відновлення після збою перетворюється на археологію.

Ціна проявляється не в момент правки, а під час розбору інциденту. Графік змін порожній, бо правка не проходила через систему контролю версій; план показує десятки «нових» ресурсів, які насправді давно працюють; відкат на попередній реліз тягне за собою чужі зміни.

Окремо розходяться середовища: те, що вручну виправлено на стенді, ніколи не доїде до промислового контуру, і навпаки.

Розбираємо, як це закривається: стан переїжджає до спільного захищеного сховища з блокуванням, зміни проходять лише через перевірюваний опис, а застосування запускається з єдиної точки, де видно автора й причину. Саме на цьому будується GitOps — репозиторій стає єдиним джерелом правди про інфраструктуру.

Що змінюється після впровадження: вимірювані ефекти

Перехід на керування станом через репозиторій змінює не сам факт застосування змін, а їхню вартість за часом і ризиком. П'ять наслідків видно вже в перший місяць роботи, і далі вони лише зміцнюються.

Швидкість доставки. План і його застосування йдуть одним маршрутом: коміт, рев'ю, автоматична перевірка, застосування.

Ручні виклики з машини інженера зникають, тому типове змінення інфраструктури проходить від правки до робочого контуру за хвилини замість годин очікування вікна й вільного відповідального.

Час відновлення після збою. Конфігурація й стан лежать поруч і версіонуються, отже відкат — це реверс коміту, а не збирання середовища з пам'яті. Відновлення скорочується з годин до хвилин і відтворюється будь-яким інженером команди, а не лише тим, хто вносив правку.

Усунені класи відмов. Блокування стану, розходження копій між майданчиками, правки напряму в консолі та зміни «повз процес» перестають бути можливими — кожен клас закритий правилом, а не домовленістю. Залишаються помилки в самій конфігурації, і вони ловляться на рев'ю до застосування.

Прозорість змін. Кожна дія залишає коміт з автором, причиною та історією: видно, що змінювалося, коли й навіщо. Розбір інциденту перестає залежати від чиєїсь пам'яті або листування в чаті.

Частка ручних операцій падає до рев'ю та рішень про архітектуру — рутинні застосування переходять до автоматики. Інфраструктура стає передбачуваною не лише в описі, а й в обслуговуванні.

Режими GitOps Terraform: порівняння підходів

Режим ведення стану визначає, хто застосовує зміни і що вважається джерелом правди про інфраструктуру. Нижче чотири варіанти, які трапляються на практиці — від локального стану до застосування за злиттям запиту.

Вони сумісні за кроками: перехід можна робити частинами, не переписуючи описи середовищ на Terraform.

Що перевіряємо під час переходу

Блокування стану не дає двом запускам одночасно змінювати одне середовище: без нього паралельні застосування залишають розходження між описом і реальністю.

Розділення прав доступу будуємо так, щоб запис до віддаленого сховища стану був лише в конвеєра, а інженери працювали через запит на злиття — тоді зміну перевіряють до застосування, а відкат зводиться до повернення попередньої версії.

Етапи впровадження: від аудиту до передачі в роботу

Починаємо з аудиту інфраструктури, а не зі встановлення інструментів: без інвентаризації ресурсів будь-яка схема розділення стану виявиться неправильною, і її доведеться переробляти разом з уже перенесеними конфігураціями.

Далі вибудовуємо порядок, у якому кожна зміна Terraform-конфігурації проходить через Git, перевіряється до застосування і залишається в історії з автором і причиною правки.

1. Аудит інфраструктури. Збираємо перелік ресурсів, середовищ і провайдерів, позначаємо створене вручну та розходження між описом і фактичним станом.
2. Схема розділення стану. Визначаємо гранулярність: окремі набори за середовищами, доменами й критичністю, щоб збій одного не блокував інші. Налаштовуємо віддалене сховище та блокування від паралельних правок.
3. Репозиторії та доступ. Розкладаємо модулі й конфігурації, задаємо гілкування, обов'язкове рев'ю та права на захищені гілки.
4. Перевірка змін до застосування. Підключаємо автоматичний розрахунок плану в запиті на злиття, статичний аналіз і політики: що заборонено — не проходить далі. Застосування в робочий контур — лише після явного підтвердження.
5. Тестовий прогін. Проганяємо створення, зміну та імпорт наявних ресурсів на неповному контурі, окремо перевіряємо відновлення стану з резервної копії.
6. Передача в експлуатацію. Документуємо порядок роботи, розбираємо типові сценарії з командою, налаштовуємо оповіщення про розходження та чергування.
7. Регламент відкатів. Фіксуємо, як відкотити невдале застосування і що робити під час конфлікту станів, поки правки йдуть паралельно.

На виході команда працює з інфраструктурою тим самим способом, що й з кодом застосунку, а доступ до ручних правок у консолі закривається або звужується до аварійного.

Артефакти впровадження: конфігурації, схеми, регламенти

Впровадження закінчується не зеленим планом в останньому коміті, а моментом, коли команда замовника може змінювати інфраструктуру без автора схеми.

Тому передаємо не доступ до репозиторію, а набір артефактів, за якими черговий інженер відновлює стан з нуля: що описано кодом, де лежить стан, хто має право його змінювати і як відкотитися, якщо застосування пройшло невдало.

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

Усі документи лежать поруч із кодом у тому самому репозиторії, тому опис і реальна конфігурація не розходяться.

Кейс: прибрали ручні правки та розходження стану

До впровадження інженери застосовували зміни з локальних копій, а стан правили командами імпорту й видалення об'єктів напряму.

За журналом блокувань повз спільний конвеєр проходила третина змін: розходження між описом інфраструктури й реальністю спливало вже на інциденті, а відкат збирався руками і займав близько 45 хвилин.

Ми розгорнули Atlantis у кластері й прив'язали його до репозиторіїв: план публікується коментарем до запиту на злиття, застосування запускається після схвалення, а запис до сховища зі станом дозволено лише сервісному акаунту сервісу. В інженерів залишилося читання, аварійне застосування — лише за регламентом із фіксацією причини.

Метрики знімали з трьох незалежних джерел: журналу блокувань стану, історії версій об'єкта у сховищі та тривалості інцидентів із системи обліку. Порівнювали зіставні за навантаженням періоди — розходження конфігурації перестало бути причиною аварій, а відкат звівся до однієї дії.

Що робити, якщо інфраструктура вже розгорнута вручну?

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

Далі йде імпорт ресурсів у стан Terraform. Критерій готовності — не «імпорт пройшов», а порожній план: якщо перевірка показує нуль розходжень, опис відображає реальність.

Кожне розходження розбираємо окремо: частина закривається правкою конфігурації, частина — уточненням параметрів, частина потребує точкового перезбирання ресурсу в узгоджене вікно.

Стан розділяємо за межами відмов: мережі, дані, застосунки — окремі набори. Тоді правка в одному контурі не тягне перезбирання інших, а збій обмежений однією ділянкою.

Блокування стану й заборона ручних правок у консолі знімають конфлікт: зміни проходять лише через репозиторій і перевірку.

План переходу будуємо так, щоб сервіси не зупинялися. Спочатку контур працює в режимі перевірки — план будується, але не застосовується. Потім на застосування переводимо один модуль і спостерігаємо кілька релізів. Ручні права відкликаємо лише після того, як новий контур відпрацював без відкатів.

Страховка на всьому шляху — версіонування стану та знімок перед кожним застосуванням. Відновлення зі знімка повертає контур у відомий стан, тому міграція йде порціями, без вікна простою і без зупинки сервісів.

Технічні сумніви та часті запитання щодо впровадження

Інженерні сумніви під час переходу на GitOps стосуються не самого принципу «стан змінюється лише через узгоджений запит», а меж: ізоляція середовищ, доступ до секретів, що залишиться після передачі проєкту. Відповідаємо на них так, як розбираємо на етапі проєктування, а не після першого інциденту.

Базове правило, з якого виводиться все інше: один каталог — один стан — одне середовище. Працюємо на Atlantis — сервіс формує план до застосування і блокує стан на час операції, тому паралельні запуски не псують файл стану.

Секрети не опиняться в репозиторії та в логах?

У репозиторії лежать лише посилання, значення подаються в раннер зі сховища секретів за шляхом середовища. Чутливі поля позначаються і не друкуються у відкритому вигляді, а доступ до промислових значень видається окремою роллю з обмеженим колом утримувачів.

Як розмежовуються ролі та ведеться аудит змін?

Права прив'язані до груп у системі контролю версій: інженер пропонує зміну, застосування до проміжного середовища йде за одним правилом, до промислового — лише через погодження. Кожне застосування залишає слід: хто ініціював, на якому коміті, що змінилося в стані.

Що входить у супровід після запуску?

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

Обговоримо задачу: склад робіт і порядок старту

Щоб розмова була предметною, достатньо надіслати те, що вже є. Нам потрібна не презентація, а робоча картина: як влаштовані репозиторії, де зберігаються стани Terraform, хто і як їх змінює сьогодні та які обмеження задані з боку безпеки.

Для старту вистачить такого набору:

• схема репозиторіїв: один спільний або кілька пов'язаних, де лежать модулі й описи оточень;
• перелік місць зберігання станів і того, що ще не переведено до спільного сховища;
• список акаунтів і проєктів хмари, до яких звертається інфраструктура, разом із правилами доступу;
• ролі інженерів і те, кому зараз дозволено застосовувати зміни напряму;
• ухвалений порядок погодження: хто рев'юїть, які правки вважаються критичними, чи є обов'язкові вікна;
• відомі обмеження: ізоляція середовищ, вимоги аудиту, заборона на автоматичне застосування;
• два-три приклади останніх великих змін — за ними видно реальні вузькі місця.

Далі порядок простий. Ми вивчаємо матеріали й повертаємося з уточнювальними запитаннями щодо доступів і меж відповідальності, потім збираємо план впровадження за етапами з точками контролю і лише після цього даємо оцінку строків і складу робіт.

Схему GitOps для станів розгортаємо покроково, щоб чинна інфраструктура залишалася робочою на кожному кроці.

Опишіть задачу й надішліть те, що вже є під рукою, — повернемося з оцінкою та планом робіт.