GitOps bootstrap: де ламається базова інфраструктура
Класичний сценарій: середовище піднімають руками під конкретне завдання — так найшвидше отримати робочий стенд сьогодні. Через пів року ніхто не пам'ятає, чому в продуктивному контурі виставлено параметр, якого немає в описі, а резервна копія повертає дані, але не налаштування.
Так ручне налаштування середовищ стає єдиним джерелом правди, і живе воно в голові одного-двох інженерів.
Дрейф конфігурації накопичується повільно й майже непомітно. Правка «поза регламентом» — заради термінового релізу або обходу обмеження — залишається в живому середовищі; наступне розгортання її затирає, і поведінка системи змінюється назад без попередження.
Або навпаки: правка закріплюється, стенд розходиться з продуктивом, і перевірки перестають щось доводити.
Звідси — невідтворювані середовища. Тести проходять там, де інші ліміти й інший порядок ініціалізації, а в продуктив іде конфігурація, яку цілком ніхто не збирав.
Простій через помилку налаштування вимірюється тоді не часом розгортання, а часом пошуку причини: поки не знайдено розходження факту й опису, відкочуватися нікуди — попередній стан теж зібрано руками.
Підхід GitOps прибирає саму можливість такого розходження: опис середовища стає єдиним джерелом правди, а будь-яке відхилення від нього — видимим і усувним. Розбираємо, як це закривається на рівні базової інфраструктури.
Що змінюється після переходу на декларативну схему
Інфраструктура перестає бути набором ручних дій і стає описом у репозиторії. Контролер звіряє фактичний стан середовища з описаним і приводить його до потрібного вигляду — без ssh-сесій, «доналаштувань з пам'яті» та розходжень між стендами.
Відтворюваність середовищ перестає залежати від того, хто і в який день розгортав контур: та сама гілка дає той самий результат у тестовому та продуктивному середовищі.
Зміна проходить перевірку до застосування. Правка йде окремою гілкою, її дивляться рев'юери та автоматичні перевірки: коректність маніфестів, відповідність політикам, план майбутніх змін.
Тільки після цього контролер синхронізує середовище — і той самий опис відкочується реверсом правки, а не збиранням «як було» з пам'яті. Ми збираємо таку схему на Argo CD, тому що вона однаково працює і для першого розгортання, і для подальших правок.
Прозорість змін тримається на історії правок. Кожен коміт відповідає, що змінювалося, хто автор і навіщо — замість пошуку по логах чужої сесії. Дрейф конфігурації видно: якщо ресурс поправили руками, контролер поверне його до описаного стану, а розходження потрапить у звіт.
Час відновлення середовища падає до застосування опису до чистого контуру. Резервний стенд розгортається з тієї самої гілки, що й основний, тому відновлення не перетворюється на археологію за старими інструкціями.
Варіанти GitOps bootstrap: від ручного збирання до автоматизації
Режим bootstrap задає, скільки ручної роботи залишиться після першого запуску і що станеться при повторному розгортанні середовища. Вибирають між трьома варіантами: разове ручне збирання, параметризовані шаблони середовищ і повна автоматизація з перевірками на вході.
Різниця проявляється не на старті, а на другій-третій ітерації, коли середовище потрібно підняти заново або привести до еталонного вигляду.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Разове ручне збирання | Один контур, склад змінюється рідко, важливіша швидкість першого запуску | Стан живе в історії команд; повторний підйом відтворює розходження, дрейф накопичується непомітно |
| Параметризовані шаблони середовищ | Кілька середовищ з однаковою структурою: розробка, тест, продуктивне | Шаблон потребує підтримки: правки в обхід нього ламають ідемпотентність, розходження спливають на наступному прогоні |
| Повна автоматизація з перевірками | Регулярні релізи, вимоги до аудиту змін, кілька команд на одній платформі | Потрібен описаний у репозиторії стан і правила допуску; без них помилка тиражується в усі середовища одразу |
Як переходять між режимами
Перехід рідко буває одномоментним: спочатку описують базовий стан у репозиторії, потім виносять відмінності середовищ у параметри, і тільки потім вмикають перевірки перед застосуванням.
Ознака зрілості — повторний прогін нічого не змінює, а розходження з еталоном видно до викочування, а не після. На цьому кроці з'являються політики допуску й повернення до попереднього стану.
Порядок впровадження: аудит, схема, налаштування, перевірка
Впровадження GitOps-bootstrap — це послідовність, а не одна команда: якщо почати з налаштування постачання, легко отримати схему, яка відтворюється на одному контурі й розсипається при додаванні другого.
- Аудит інфраструктури. Інвентаризуємо кластери, реєстри, зовнішні залежності, доступи й секрети. Окремо фіксуємо те, що створено руками поза репозиторієм, — це головне джерело розходжень при першому ж застосуванні.
- Схема середовищ. Визначаємо контури, їхній спільний шар і відмінності: що успадковується, а що перевизначається. Тут же вирішуємо, де зберігається стан, а де лише описи конфігурації.
- Структура репозиторіїв і порядок застосування. Розбиваємо конфігурацію на шари — базові ресурси, платформенні сервіси, застосунки — і задаємо чергу: що має існувати раніше, ніж з'явиться залежність.
- Налаштування постачання. Узгодження змін, автоматичне застосування за фактом злиття, права для агента, секрети через зовнішнє сховище. Окремо описуємо поведінку при розходженні й те, хто його усуває.
- Перевірка на стенді. Розгортаємо контур з нуля й навмисно ламаємо сценарії: ручна правка ресурсу, конфлікт злиття, відкат до попередньої ревізії. Дивимося, чи відновлюється схема без ручного втручання.
- Передача в експлуатацію. Віддаємо схему середовищ, регламент змін і порядок підключення нового контуру — так, щоб чергова команда відкочувала постачання сама.
Артефакти: репозиторії, політики доступу, регламенти
Налаштування GitOps для базової інфраструктури закінчується не працюючим контуром, а набором артефактів, які залишаються в репозиторії замовника й далі живуть без нас.
Репозиторій без опису середовищ і правил доступу через місяць перетворюється на набір маніфестів, де ніхто не наважується щось змінювати: незрозуміло, які контури існують, чим вони відрізняються і хто має право вливати правки.
- Опис середовищ — які контури є (розробка, передпродуктив, продуктив), чим вони відрізняються за складом сервісів, що виноситься в змінні, а що задається накладенням на спільну базу.
- Політики доступу — ролі й права всередині кластера, окремі облікові записи для автоматики, прив'язка «хто і в яку гілку вливає зміни», явна заборона правок в обхід репозиторію.
- Регламент випуску змін — шлях правки від гілки до застосування: обов'язкові перевірки, узгодження, порядок просування між контурами, точка неповернення.
- Процедура відкату — як повернути попередній стан, за який час, які зміни відкочуються тільки вручну і чому.
- Управління секретами — де зберігаються, хто і як отримує доступ, як проходить ротація і що робити при витоку.
- Документація з інфраструктури — схема контурів, карта залежностей між сервісами, перелік зовнішніх точок входу й порядок підключення нового компонента.
- Матриця відповідальності — хто погоджує зміни, хто чергує, кому ескалюється розходження фактичного стану з описаним.
Кожен пункт — не формальність, а умова, за якої команда замовника сама додає сервіс або відкочує випуск, не розбираючи заново логіку репозиторію.
Кейс: інфраструктура під управлінням репозиторію
Ситуація до
Замовник — продуктовий відділ з трьома середовищами: розробка, передпрод, продакшн. Базовий контур — кластер, мережа, права доступу, секрети — піднімали вручну за чек-лістом з вікі.
Нове середовище збиралося три-чотири дні, а розходження між продакшном і передпродом спливали вже під час інциденту.
Що змінили
Перенесли опис базової інфраструктури в репозиторій: розгортання в Kubernetes, мережеві політики, простори імен, доступи, сховище секретів. Описали й сам bootstrap — мінімальний набір ресурсів, з якого розгортається все інше, включно з компонентом синхронізації.
Будь-яка зміна проходить перевірку плану в pull request, а розходження з реальним станом контур усуває сам.
Що стало
Підйом середовища з нуля — 25 хвилин замість трьох днів, другий майданчик розгортається тим самим описом. Відмови класу «забули параметр при ручному налаштуванні» зникли: за пів року жодного випадку.
Простій при відновленні скоротився з чотирьох годин до двадцяти хвилин — стан повертається з репозиторію, а не збирається заново. Плюс вся історія змін контуру читається за комітами: видно, хто і навіщо його змінював.
Чим декларативне постачання відрізняється від класичного конвеєра?
Класичний конвеєр відповідає на питання «що зробити»: зібрати артефакт, прогнати перевірки, розкласти по серверах і виконати команди в потрібному порядку.
Декларативне постачання відповідає на інше питання — «яким має бути стан», а приведення системи до цього стану бере на себе агент звірки всередині кластера. Межа проходить там, де закінчується одноразова дія і починається безперервне утримання стану.
У звичайному конвеєрі результат залежить від того, що вже лежить на сервері: повторний прогін може впасти або створити дублі. Декларативний опис ідемпотентний — застосували один раз чи сто, результат однаковий.
Якщо хтось поправив ресурс руками, звірка це помітить: або поверне опис, або покаже розходження окремою подією. Історія змін при цьому лежить у репозиторії, і відкат — це повернення попередньої ревізії, а не пошук «що ж ми там натискали».
| Критерій | Класичний конвеєр | Декларативне постачання |
|---|---|---|
| Джерело істини | порядок кроків і скрипти | опис стану в репозиторії |
| Повторний запуск | залежить від поточного стану | ідемпотентний |
| Розходження | шукають вручну | виявляються звіркою |
| Відкат | повтор окремих кроків | повернення попередньої ревізії |
На практиці підходи не конкурують: збирання, тести й публікацію залишають конвеєру, а постачання й утримання стану описують декларативно.
Тоді базова інфраструктура розгортається з одного репозиторію відтворювано — на новому майданчику або після збою, — замість повторного проходження десятка ручних інструкцій.
Технічні сумніви: доступи, відкати, ручні правки
GitOps не вимагає, щоб інфраструктура була ідеальною з першого дня. Розходження живого середовища й репозиторію описується як дрейф і закривається контрольовано: спочатку поточний стан знімається в декларації й приймається як база, і лише потім вмикається автоматична звірка. До цього кроку жоден ресурс не видаляється й не перестворюється.
Доступи розділяємо за ролями: зміна пропонується через pull request, черговий підтверджує, автоматика застосовує. Пряма правка в контурі або блокується політикою, або фіксується й перетворюється на завдання — розходження не накопичується мовчки, а потрапляє в чергу.
Що робити із середовищами, які налаштовували руками?
Інвентаризуємо ресурси, переносимо їх у декларації як є й приймаємо під управління по одному контуру за раз. Поки контур не звірено, автоматичне видалення для нього вимкнено.
Як відкочується невдала зміна?
Зворотним комітом до попереднього стану: автоматика приводить контур до нього й чекає збіжності. Історія залишається — видно, хто і що змінював.
Хто відповідає за термінові правки?
Черговий інженер може правити вручну за правилом «зламане скло»: доступ видається на час і логується. Правка зобов'язана того ж дня повернутися в репозиторій, інакше звірка поверне попередній стан.
Що буде, якщо репозиторій або агент недоступні?
Контур продовжує працювати на вже застосованому стані: зміни накопичуються, але нічого не видаляється. Після відновлення зв'язку звірка йде у звичайному режимі.
З чого почнемо: схема, доступи й порядок робіт
Перша розмова потрібна не для презентації, а для звірки вхідних даних: без інвентарю середовищ і зрозумілої моделі доступів будь-яка оцінка перетворюється на здогад. Нижче — те, що варто підготувати до обговорення задачі.
Якщо частини пунктів немає, це не блокер: прогалини фіксуємо окремо й закриваємо на етапі розвідки, до перших змін у робочому контурі.
- перелік середовищ і кластерів: скільки їх, які спільні, які ізольовані, де проходить межа між тестовим і робочим контуром;
- поточний спосіб управління інфраструктурою — ручні команди, скрипти, шаблони провайдера або частково налаштований GitOps;
- склад сервісів, які зобов'язані підніматися першими: мережа, сховище секретів, система збирання образів;
- модель доступів: хто і що може змінювати в репозиторії та в кластері, чи потрібні окремі ролі для чергових;
- вимоги до зберігання секретів і ключів — де лежать зараз, хто до них допущений, як вони потрапляють у середовище;
- правила відкату: як визначаємо, що викладка зламала середовище, і за який час потрібно повернутися до попереднього стану;
- вікна змін і обмеження — коли чіпати робочий контур не можна.
Порядок робіт після звернення виглядає так: розбір вхідних даних, схема репозиторіїв і гілок, опис базового шару, підключення середовищ, перевірка відновлення з нуля, передача з інструкцією для чергової зміни.
Першим кроком ми повертаємося з оцінкою й планом, де видно, що робимо ми, а що залишається на вашій стороні.
