Blue-Green Deployment: чому реліз ламає прод
Класична картина: одне середовище, один контур, реліз накочується поверх працюючого застосунку. Перемикання трафіку робиться руками — інженер редагує конфігурацію або перезапускає процеси, поки частина користувачів уже тримає відкриті з'єднання.
Кожен реліз перетворюється на вікно недоступності, тривалість якого ніхто не береться назвати заздалегідь.
Зворотний бік — відкат релізу. Готової резервної копії попередньої версії немає: образи перезаписані, схему даних мігровано вперед, і назад вона не розгортається.
Повернути минулий стан можна тільки новою збіркою і повторним прогоном міграцій — замість хвилини виходять години, і все це на живому контурі.
Суміщені середовища додають шуму: на одному кластері живуть тестові прогони, стенд приймання і продакшн, ресурси діляться, а сплеск від перевірок б'є по користувацькому трафіку. Простій перестає бути аварійним сценарієм і стає штатним режимом релізу.
Ціна помилки — не тільки недоступність. Команда починає боятися релізів: деплої переносять у нічні години, частота релізів падає, виправлення чекають черги, зворотний зв'язок запізнюється на дні.
Розбираємо, як це закривається: що дає паралельний контур, постійна готовність другого середовища та передбачуване перемикання трафіку без простою.
Що дає перемикання між двома середовищами
Механіка проста: паралельно живуть два середовища — активне і підготовлене, трафік спрямовується на одне з них перемикачем Service або правилом Ingress.
Відкат — це перемикання селектора назад, а не перезбирання: час відкату вимірюється секундами і не залежить від розміру образу чи кількості подів. Попередня версія залишається запущеною і прогрітою, тому повернення не супроводжується сплеском помилок через холодний старт.
Готовність середовища і перевірка перед релізом
Перед перемиканням нове середовище має довести готовність: readiness-проби дають успіх, застосунок відповідає на службовому маршруті, проганяють smoke-перевірки за ключовими шляхами, за потреби — навантажувальна перевірка на одному поді.
Argo Rollouts додає до цього аналіз метрик прямо в процес релізу: поки середовище не проходить заданий поріг за помилками та затримками, трафік на нього не переводиться. Ручне підтвердження залишають там, де реліз зачіпає платежі або дані.
Що це дає у вимірюваних величинах
Простій при релізі йде в нуль: трафік перемикається між уже працюючими наборами подів, вікно недоступності відсутнє. Частка успішних релізів зростає завдяки тому, що перевірка відбувається до переведення всього трафіку, — невдала версія просто не стає активною.
Час відкату скорочується до операції перемикання, і ним можна керувати без чергового інженера і без повторного проходження перевірок.
Окремо йде цілий клас відмов, пов'язаний з «відкотили код — втратили дані»: схема бази змінюється так, щоб бути сумісною з обома версіями, і повернення стає безпечним.
Порівняння схем релізу: blue-green deployment і канареечна
Схема релізу — це компроміс: чим нижчий ризик, тим більше ресурсів, часу або інфраструктури він потребує. У Kubernetes вибирають між чотирма варіантами, і обмеження кожного проявляються не на демо, а на третьому релізі з міграцією даних.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Синьо-зелена схема | Потрібен миттєвий відкат зміною трафіку; сервіс без стану або дані сумісні в обидва боки | Подвійний запас ресурсів на час релізу; перемикання розриває довгі з'єднання та сесії без зовнішнього сховища |
| Канареечний реліз | Трафік великий і різнорідний, є метрики для автоматичного рішення про розкатку | Розкатка та відкат тривають у часі; потрібна надійна маршрутизація за вагами або заголовками |
| Тіньове дзеркалювання трафіку | Хочеться перевірити версію на реальному трафіку без ризику для користувачів | Копія не впливає на відповіді — порівняння будують окремо; побічні записи та зовнішні виклики ізолюють |
| Поступове оновлення | Прості сервіси без стану, де достатньо заміни подів по одному | Немає середовища, щоб перевірити реліз цілком; версії працюють одночасно, відкат теж поступовий |
Схеми не взаємовиключні: Argo Rollouts веде реліз кроками з паузами та автоматичним відкатом за метриками, тому синьо-зелену схему доповнюють канареечною розкаткою, а тіньове дзеркалювання ставлять перед перемиканням трафіку — так обмеження кожної схеми перекриваються сусідньою.
Порядок впровадження: від розбору схеми до передачі
Порядок робіт будуємо так, щоб зміна версії стала рутинною операцією з передбачуваним відкатом, а не подією з ризиком. На кожному кроці впровадження blue-green deployment у замовника залишається артефакт: схема, конфігурація або регламент.
- Розбір поточного релізу. Дивимося, як версія потрапляє в кластер сьогодні: маніфести, власники образів, проби, фактичний час відкату. Результат — карта ризиків і список змін у контурі.
- Проєктування схеми. Два середовища з незалежними наборами подів, спільний доступ до даних і жорстке правило: трафік обслуговує рівно одна версія.
- Налаштування маршрутизації. Перемикаємо селектори сервісів і правила вхідного контролера, перевіряємо, що з'єднання закриваються коректно і запити не губляться.
- Налаштування Argo Rollouts. Описуємо об'єкт релізу з посиланнями на активні й попередні сервіси, задаємо проби та крок ручного підтвердження перед переведенням трафіку.
- Перевірка готовності. Проганяємо сценарії на попередньому середовищі: відгук ключових шляхів, метрики помилок, логи, поведінку під навантаженням.
- Тестове перемикання та відкат. Робимо навчальне переведення трафіку та повернення на попередню версію, заміряючи час кожної операції. Якщо відкат довший за очікуваний — правимо схему.
- Передача регламенту. Віддаємо документацію: як випускати, як відкочувати, що дивитися в чергуванні, які сигнали вважати приводом для повернення версії. Далі команда замовника веде релізи сама.
Конфігурації, схеми стендів і регламент відкату
На виході замовник отримує не набір розрізнених файлів, а пов'язаний комплект: конфігурації, схеми, регламенти та інструкції, за якими чергова зміна діє без автора змін. Нижче — що саме входить у передачу і навіщо кожна частина потрібна в експлуатації.
- Файли конфігурації розгортання: описи двох робочих середовищ, правила перемикання трафіку, ліміти ресурсів і проби готовності — у репозиторії з історією правок, а не на машині інженера.
- Схема стендів: які середовища є, чим відрізняються за складом і даними, як проходить потік трафіку при перемиканні і де залишається точка входу для повернення.
- Політики доступу: ролі на читання і на зміну, хто має право перемкнути трафік, хто тільки спостерігає, порядок ротації доступів і секретів.
- Регламент відкату: умови спрацьовування, відповідальний за рішення, цільовий час повернення на попередню версію та поведінка активних з'єднань у момент перемикання.
- Інструкція для чергового: сценарій на одну сторінку — від сигналу моніторингу до підтвердження результату, із зазначенням, де дивитися стан і куди писати при сумнівах.
- Карта спостережуваності: набір метрик і порогів, за якими видно деградацію нової версії, і список адресатів повідомлень.
- Порядок роботи зі схемою даних: правила сумісності змін, щоб повернення коду не ламало вже застосовані міграції.
Такий комплект знімає залежність від конкретного спеціаліста: перемикання та відкат відтворювані за документом, а не з пам'яті.
Розбір впровадження: як скоротили вікно недоступності
Що було до
Сервіс із десятка мікросервісів у Kubernetes випускався раз на два тижні, і тільки в нічне вікно.
Один реліз займав 3-4 години: третина часу йшла на ручне перемикання трафіку, прогрів контурів і перевірки, а при помилці в новій збірці сервіс ішов у відмову на 20-40 хвилин — поки черговий не відкотить образ і не підніме попередній контур. Таких епізодів набиралося до семи за квартал.
Що змінили і що стало
Підняли другий контур з ідентичною конфігурацією і винесли перемикання трафіку на рівень маршрутизації за схемою blue-green, а управління викатом віддали Argo Rollouts.
Нова версія спочатку приймала частку трафіку і тільки потім основний потік, критерії просування та відкату задали метриками: частка помилок, час відповіді, стан перевірок готовності.
Якщо показники виходили за поріг, викат зупинявся сам, а трафік повертався на попередній контур без участі чергового.
Час релізу скоротився з 3-4 годин до 20-25 хвилин, і нічне вікно перестало бути обов'язковим.
Кількість інцидентів на релізах упала з семи за квартал до одного, частка відкатів без простою дійшла до 100%: повернення на попередню версію займає менше хвилини і не розриває з'єднання користувачів. Звільнений час команда перенесла на перевірки в тестовому контурі.
Що робити, якщо релізний конвеєр уже розгорнуто?
Перебудовувати чинний конвеєр цілком не потрібно. Blue-green вбудовується як окремий етап релізу: збірка, тести й перевірки залишаються на своїх місцях, змінюється лише спосіб доставки версії в кластер. Попередній процес продовжує працювати, поки новий не пройде перевірку на одному сервісі.
Поетапний перехід починається з кластера і середовищ. Поруч із робочим контуром піднімається другий набір подів з ідентичною конфігурацією, що відрізняється тільки мітками; перемикання трафіку бере на себе Service, а зважений розподіл — Ingress або сервісна сітка.
Квоти й ліміти рахуються відразу на два контури, інакше зелене середовище витіснить синє під навантаженням.
Ключове обмеження — сумісність схем даних. Міграції готуємо за принципом розширення: спочатку додаємо поля й таблиці, код учимо читати обидва формати, і тільки наступним релізом прибираємо старе. Тоді обидві версії працюють з однією базою, і перемикання не потребує зупинки.
Перенесення релізу йде хвилями: спочатку сервіс без стану, потім черги й фонові задачі, в кінці — ядро. Відкат — повернення трафіку на попередній контур за секунди, без перезбирання образу та повторного прогону перевірок. Розробка не зупиняється: обидва контури живуть в одному кластері, а конвеєр збирає в ту саму гілку.
Перед першою хвилею перевіряємо проби готовності, поведінку довгих з'єднань і порядок застосування міграцій — інакше перемикання обірве відкриті сесії. Далі схема тиражується на решту сервісів без змін у звичних процесах команди.
Часті технічні питання перед стартом
Blue-green у Kubernetes виглядає просто: два середовища, перемикання трафіку на рівні сервісу, відкат поверненням покажчика.
На практиці рішення впирається в чотири питання — що саме дублювати, що робити зі спільною базою, як розвести секрети і чим довести, що зелена версія здорова до перемикання. Нижче — короткі відповіді на те, що спливає на старті найчастіше.
Чи потрібно дублювати всю інфраструктуру?
Ні — тільки шар застосунків: робоче навантаження, його налаштування та правила маршрутизації. База даних, черги, кеш і сховище залишаються спільними, друге середовище звертається до них через окремі облікові записи та префікси.
Що відбувається з базою даних при перемиканні?
Схема змінюється розширювальними міграціями, сумісними з обома версіями коду: нові поля додаємо заздалегідь, старі прибираємо тільки після виведення попередньої версії. Тоді відкат стосується застосунку і не вимагає відкочувати дані.
Як розводяться секрети та ключі?
У кожного середовища свій набір, підключений із зовнішнього сховища, а не вшитий у маніфести. Ротація йде незалежно, тому перемикання не тягне за собою перевипуск ключів і синхронні правки в обох середовищах.
Як переконатися, що зелена версія здорова, і чи не подвоїться навантаження?
До перемикання вона проходить перевірки готовності, синтетичні сценарії та тіньовий потік на частині трафіку; метрики й трасування порівнюються з поточними.
Ресурси на час перевірки виділяються понад звичайні — пік планується заздалегідь, зайві вузли знімаються відразу після перемикання.
Обговоримо задачу і повернемося з оцінкою
Щоб оцінка строків і план робіт спиралися на факти, а не на здогадки, нам потрібен короткий зріз по вашому контуру: як влаштований реліз, чим він обмежений і що критично не зламати при оновленні.
Обговорити задачу можна у вільній формі — деталі уточнимо на дзвінку з інженером, який далі веде проєкт, і повернемося з оцінкою та етапами.
Розмова йде швидше, коли вже зрозуміло:
- як випускаються оновлення зараз: ручні кроки, хто підтверджує, що відбувається між збіркою і робочим середовищем;
- що не можна втратити при перемиканні: активні сесії, фонові задачі, стан кешу та черг;
- з чого складається середовище: кластери, реєстр образів, зовнішні залежності та доступи;
- вимоги до відкату: за який час потрібно повернутися на попередню версію і хто дає команду;
- що вже є з автоматизації: опис застосунку, маніфести, правила збірки та перевірок;
- обмеження: вікна релізів, режим обслуговування, погодження з безпекою та суміжними командами.
Якщо йдеться про blue-green deployment, окремо проговоримо, як співіснують дві версії і за якою ознакою приймається рішення про перемикання та відкат.
За цими вступними ми збираємо склад робіт, оцінку строків і порядок етапів — і повертаємося з планом робіт, від якого можна починати, без недомовок на старті проєкту.
