Flux CD замість ручних правок: де ламається доставка
Поки маніфести лежать у репозиторії, а застосовуються руками, описаний і фактичний стан розходяться. Термінова правка в нічному розгортанні, забутий параметр у values, реліз, піднятий не з тієї гілки — і за місяць ніхто не може впевнено сказати, що саме зараз працює в кластері.
Дрейф конфігурації накопичується непомітно: ручний деплой обходить перевірки, розсинхронізація кластера зростає від середовища до середовища, а стенд перестає відтворюватися з нуля.
Розбір збою розгортання перетворюється на археологію — звіряють логи, історію правок і те, що реально застосовано, замість того щоб подивитися в одну точку істини.
Уночі ціна помилки вища: черговий править ресурс вручну, стан розходиться ще сильніше, а відкат робиться по пам'яті.
Без автоматичного приведення кластера до описаного вигляду кожна правка в проді відводить контур далі від репозиторію, і наступне розгортання йде вже по неправильній базі.
Flux CD прибирає саму можливість такого розходження: агент звіряє кластер із репозиторієм і приводить його до описаного стану, а не чекає, поки хтось застосує правку вручну.
Далі розбираємо, як це закривається: як вибудовується потік змін, що робити з уже накопиченим дрейфом і як побачити збій раніше, ніж про нього повідомить користувач.
Що дає керована доставка: швидкість, відкати, простій
Доставка описується декларативно: маніфести та значення релізів лежать у Git, а Flux CD звіряє фактичний стан кластера з описаним і приводить його до потрібного. Звірка йде циклами, тому розходження усувається саме — без входу на сервери й ручних команд у консолі кластера.
Одиницею зміни стає коміт, а не набір дій чергового: що розгорнуто в кожному середовищі, видно з історії репозиторію.
Швидкість релізу зростає завдяки відсутності ручних кроків між збіркою образу та застосуванням у прод.
Оновлення маніфесту в гілці середовища запускає розгортання, і контролер сам доводить реліз до готовності — шлях від злиття зміни до працюючого екземпляра вимірюється хвилинами й не залежить від того, хто чергує.
Відкат змін — одна операція: повернення коміту або перемикання на попередню ревізію маніфесту, після чого звірка сама повертає кластер до попереднього стану. Відкочується конкретний HelmRelease, а не весь релізний потяг: сусідні сервіси продовжують працювати на своїх версіях.
Простій сервісу скорочується у двох місцях. Дрейф конфігурації — правки в обхід репозиторію, забуті хотфікси, розійшлися значення — знімається під час чергового циклу звірки.
Клас відмов «на сервері щось поправили, і ніхто не пам'ятає що» зникає: джерело правди одне, а розходження видно й оборотне.
Надійність розгортань стає вимірюваною: частка змін, що дійшли до проду без ручного втручання, і час повернення до попередньої версії. Обидва показники задає конфігурація звірки, а не акуратність окремого інженера.
Flux CD: порівняння способів синхронізації стану
Стан кластера розходиться з репозиторієм із двох причин: об'єкт поправили руками або застосували маніфест із зовнішньої складальної системи. Від того, хто ініціює застосування, залежать швидкість відкату, відтворюваність і те, чи помітимо ми розходження взагалі.
Гнучкість Flux CD у тому, що постійна звірка та зовнішній запуск розгортання не виключають одне одного. Ключовий критерій — звірка: тільки вона повертає об'єкт до описаного вигляду після ручної правки або падіння пода. Зовнішній запуск дає контроль над моментом застосування, але між запусками дрейф не усувається.
| Варіант | Коли підходить | Обмеження підходу |
|---|---|---|
| Агент у кластері зі звіркою | Продуктивні контури, де потрібне автоповернення до стану репозиторію | Потрібні права на зміну об'єктів і дисципліна: репозиторій — єдине джерело правди |
| Розгортання із зовнішнього конвеєра | Релізи з перевірками на боці складальної системи | Дрейф усувається тільки в момент запуску, між розгортаннями розходження накопичуються |
| Гібридна схема | Різний темп змін у застосунків і платформених сервісів | Два джерела ініціативи: без розмежування відповідальності виникають конфлікти застосування |
| Прямі правки в кластері | Розбір інциденту, терміновий патч | Не відтворюється: наступна звірка затре правку, історія змін губиться |
Робочий варіант на практиці — гібрид: платформені сервіси живуть на звірці, релізи застосунків ідуть розгортанням, а прямі правки залишаються аварійним інструментом з обов'язковим перенесенням у репозиторій.
Перед увімкненням звірки варто переконатися, що всі об'єкти контуру вже описані в репозиторії — інакше перший же цикл затре розгорнуте вручну.
Порядок впровадження: від аудиту до передачі в підтримку
Впровадження GitOps починається не зі встановлення контролера, а з опису того, що вже працює в кластері. Поки немає інвентарю сервісів і залежностей між ними, автоматизація відтворює не бажаний стан, а накопичений хаос. Порядок тому такий: аудит, схема зберігання описів, звірка, ролі, перевірка відмов.
- Аудит кластера: опис робочих навантажень, ingress-правил, томів і зовнішніх залежностей, звірка з поточними маніфестами. На виході — розходження та перелік сервісів, які не можна віддавати автоматиці без доопрацювання.
- Схема репозиторіїв: базовий шар платформи, спільні компоненти та застосунки розділено, задано середовища й порядок застосування шарів. Видно, що лежить у спільному шарі, а що — у налаштуваннях конкретного контуру.
- Налаштування звірки: розгортаємо Flux CD, підключаємо репозиторій до кластера, задаємо інтервал звірки, реакцію на ручні правки й очищення видалених об'єктів. Helm-релізи описані декларативно, з явними залежностями між ними.
- Налаштування ролей: розмежовано права на основну гілку, погодження змін і повноваження самого контролера. Сервісні облікові записи отримують мінімально необхідний доступ.
- Перевірка відмовостійкості: імітуємо падіння вузла, правку об'єкта в обхід Git і втрату зв'язку з репозиторієм — дивимося, чи повертається стан сам і як швидко.
- Передача в підтримку: регламент змін, схема репозиторіїв і порядок відкату йдуть у документацію, інциденти розбираємо разом із командою замовника.
Комплект на виході: маніфести, схеми, регламенти
Після завершення робіт у команди замовника залишається не лише працюючий контур, а й комплект артефактів, за яким його розвивають і передають іншим інженерам.
Усе лежить у git-репозиторії поруч із кодом застосунку: стан кластера відновлюється з історії змін, а не з пам'яті конкретної людини.
- HelmRelease-маніфести по кожному сервісу: зафіксовані версії чартів, значення для кожного середовища, явні залежності та порядок встановлення.
- Описи релізів — що входить у розгортання, які зміни зачіпають стан, де потрібен ручний крок і як відкотитися на попередню версію.
- Структура зберігання в репозиторії: розділення за середовищами, базові значення та перевизначення під середовище, окрема гілка під конфігурацію самого кластера.
- Політики доступу: ролі та права сервісних облікових записів, заборона прямих правок у кластері в обхід репозиторію, розділення зон відповідальності між командами.
- Схема контуру: зв'язки репозиторію, контролера, реєстру образів і моніторингу, поведінка системи при розходженні бажаного й фактичного стану.
- Документація контуру: порядок відновлення після збою, точки контролю, куди дивитися при помилці синхронізації та як читати статус релізу.
- Регламент релізів: хто погоджує розгортання, які перевірки обов'язкові до злиття змін, як оформлюється відкат і хто чергує після нього.
Комплект залишається у вас: правки йдуть через git, рев'ю та злиття, далі контролер сам приводить кластер до описаного стану.
Кейс: ручні розгортання прибрали в контурі з дванадцяти сервісів
Контур із дванадцяти сервісів жив на ручних розгортаннях: інженер збирав образ, правив маніфести на місці й застосовував їх у кластер.
На реліз ішло 14 ручних операцій на кожен сервіс — від оновлення тегу до перевірки стану після розгортання, і будь-яку з них можна було виконати по-різному.
Розходження між описаним станом у репозиторії та фактичним у кластері накопичувалися: через тиждень після релізу відповідь на питання «що зараз працює» вимагала обходу стендів руками.
Що змінили
Взяли Flux CD як єдине джерело правди: опис сервісів перенесли в репозиторій, початкове встановлення контролера зайняло один прогін, маніфести розклали по HelmRelease з окремими середовищами.
Ручні операції замінили на синхронізацію з репозиторію, а звірку стану налаштували з періодичністю, за якої розходження не встигають накопичитися. Оновлення та відкат стали однією операцією з передбачуваним результатом.
Що стало
Число ручних операцій на реліз упало з 14 до однієї-двох — правка значення в репозиторії та спостереження за розгортанням.
Час відновлення після збою скоротився з сорока хвилин до трьох-чотирьох: відкат — це перемикання на попередній опис, а не пошук робочого маніфесту по стендах.
Частка розходжень між описаним і фактичним станом звелася до нуля — контролер сам приводить кластер до репозиторію, без участі людини в контурі.
Що робити, якщо в кластері вже є ручні правки?
Ручні правки в живому кластері — не привід переписувати все одразу. Починаємо зі звірки в режимі спостереження: контролер порівнює стан об'єктів з описами, але не застосовує зміни сам. На виході — карта розходжень, отримана без ризику для працюючих сервісів.
Перший крок перехідного періоду — інвентаризація об'єктів.
Розмічаємо, що прийшло з репозиторію, а що створено руками, і розкладаємо знахідки на три групи: постійні доопрацювання, які потрібно перенести в описи; термінові виправлення, які час відкотити; об'єкти, що живуть поза репозиторієм усвідомлено. Для кожної групи одразу фіксуємо власника й термін.
Потім налаштовуємо винятки зі звірки. Для окремих полів ставимо анотацію ігнорування, для релізів — правила ігнорування розходжень за конкретними шляхами специфікації, для частини ресурсів тимчасово призупиняємо звірку цілком.
У кожного винятку є термін зняття: інакше замість перехідного періоду отримуємо друге джерело правди.
Зведення правок іде хвилями — простір імен за простором імен, сервіс за сервісом. Правку переносимо в опис через запит на злиття, знімаємо виняток і даємо контролеру застосувати стан. Накат ідемпотентний, тому перемикання проходить без простою.
Окрема тема — конфлікти володіння полями: їх закриваємо через server-side apply, явно передаючи поле контролеру. Flux CD показує план змін до застосування — цим і перевіряємо, що опис і живий об'єкт нарешті збіглися.
Технічні сумніви: секрети, дрейф, відкат, моніторинг
Інженери задають один і той самий набір питань до старту: де зберігаються секрети, що станеться при розходженні кластера з репозиторієм, як відкотити реліз і хто дізнається про збій першим.
Нижче — короткі відповіді за кожним пунктом, щоб зняти сумніви на етапі проєктування, а не в момент інциденту.
Секрети лежать відкритим текстом у репозиторії?
Значення шифруються до коміту, розшифрування йде всередині кластера окремим контролером. Ключ не покидає кластер, тому доступ до репозиторію не дорівнює доступу до секретів продакшену.
Як відстежується дрейф конфігурації?
Контролер періодично звіряє бажаний стан із фактичним у кластері. Ручна правка через командний рядок відкочується до версії з репозиторію; для критичних об'єктів звірку призупиняють, щоб не затерти аварійну зміну.
Що буде, якщо контролер втратить зв'язок із репозиторієм?
Він працює всередині кластера: недоступність репозиторію не зупиняє запущені сервіси. Нові версії не застосовуються, кластер залишається на останньому узгодженому стані, а пропущені звірки піднімають алерт.
Як відкотити невдалий реліз?
Відкат — це повернення коміту: синхронізація приводить кластер до попереднього набору маніфестів. Історія ревізій Helm-релізу дає відкат до попередньої, але підсумок фіксується в репозиторії, а не лише в кластері.
Як зрозуміти, що синхронізація зламалася?
Метрики контролера: успішність і тривалість звірки, число ревізій, готовність релізів. Алерти — на неуспішну синхронізацію, стійкий дрейф і завислі оновлення, щоб інцидент було видно до скарги користувача.
Обговоримо вашу задачу: що потрібно для оцінки контуру
Щоб повернутися з оцінкою та планом робіт, а не загальними словами, нам достатньо побачити кілька речей про ваш контур. Готувати заздалегідь нічого не потрібно — частина відповідей знаходиться вже на першій зустрічі.
- Структура репозиторіїв з маніфестами: де зберігається бажаний стан, скільки середовищ і чим вони відрізняються.
- Доступи та межі: який кластер, хмара чи свої сервери, хто власник прав і як видаються ролі для автоматики.
- Схема середовищ: тестовий і продуктивний контури, обмеження на прод — погодження, вікна релізів, політики доступу.
- Поточний спосіб доставки змін: ручні команди, скрипти або складальний ланцюжок — і що в ньому дратує найбільше.
- Секрети: де лежать ключі, токени й сертифікати, чи потрібне зовнішнє сховище і хто ним керує.
- Спостережуваність: які метрики, логи та сповіщення вже збираються, куди йдуть і хто на них дивиться.
- Вимоги до відкату: як швидко потрібно повернути попередній стан і хто ухвалює це рішення.
За цим набором збираємо схему контуру, склад робіт і порядок етапів: що налаштовуємо першим, де ставимо перевірки, на якому кроці підключаємо моніторинг. Чогось зі списку може не бути — це не перешкода, такі пункти просто увійдуть у план окремими кроками.
Якщо частина контуру вже описана декларативно — скажімо, на Flux CD, — розбір починається з ревізії наявних налаштувань, і це помітно прискорює оцінку. Опишіть задачу — повернемося з оцінкою, схемою та планом робіт.
