Моделювання стратегій CI/CD розгортання: Синій-Зелений, Канар та Повний Розгорт

Конвеєр є станом машини, а не просто переліком

Тим не менш, спокусливо описувати конвеєр безперервного злиття та доставки (CI/CD) як простий список: комітьте код, зберіть його, протестуйте його, розгорніть. На практиці конвеєр краще моделюється як машина стану, яка переміщує один артефакт через послідовність середовищ, кожне з яких має свій поріг успіху чи невдачі. Коміт входить до системи як кандидат; він стає артефактом збірки після компіляції; цей артефакт стає кандидатом на випуск після проходження автоматизованих тестів; і він стає розгортанням у виробництві лише після успішного застосування політики розгортання, обраної командою. Кожна стрілка між цими станами може зазнати невдачі, і кожна невдача або повертає артефакт назад до розробника, або зупиняє його на місці для відкату.

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

Blue-green: миттєвий перехід між двома повними середовищами

У стратегії Blue-Green одночасно існують дві повні копії виробничого середовища – їх називають «синім» (поточне робоче) та «зеленим» (нова версія). Новий реліз розгортається повністю на зеленій, а синя продовжує обслуговувати 100% трафіку, тому користувачі не бачать перемикання. Після проходження зеленою серії Smoke Test, маршрутизатор або балансувальник навантаження перенаправляє весь трафік на зелену за один крок, зазвичай оновлюючи запис DNS, групу цілей балансувальника навантаження або правило маршрутизації мережі Service Mesh.

Визначною властивістю Blue-Green є те, що вплив трафіку на нову версію – це функція сходинки: 0% до моменту перемикання, а потім 100% відразу після. Це робить відкат простим – повертайте маршрутизатор назад до синьої – і тому Blue-Green популярний для змін, які важко частково скасувати, таких як міграції схеми бази даних у поєднанні зі змінами в коді додатків. Вартість – дублювання ресурсів: потрібно достатньо резервної потужності для запуску двох повних виробничих середовищ одночасно, навіть якщо це лише на короткий час, і будь-яка помилка, яка проявляється тільки під реальним навантаженням та сумішю трафіку, впливатиме на всіх користувачів одночасно в момент перемикання, оскільки немає проміжного рівня впливу для її виявлення раніше.

Канар: крива поступового розширення впливу

Розгортання у форматі «канар» направляє невеликий, свідомо обраний шматок реального трафіку до нової версії — часто починаючи з 1% до 5%, тоді як решта продовжує потрапляти до відомо надійної версії. Якщо показники помилок, затримки та бізнес-метрики для сегменту «канар» залишаються в прийнятних межах протягом періоду спостереження, частка трафіку збільшується поетапно (5% → 25% → 50% → 100%), і ті самі перевірки стану повторно оцінюються на кожному етапі. Якщо показники погіршуються в будь-який момент, «канар» відкочується просто перенаправляючи трафік з нього, і лише невелика частка користувачів була зачеплена.

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

Розгортання у форматі «канар» потребує інфраструктури, яка може розділяти трафік з високою точністю — зазвичай це мережа мікросервісів (така як Istio чи Linkerd) або маршрутизатор, орієнтований на додаток, і вони вимагають автоматизованих, статистично значущих перевірок стану здоров’я, оскільки порівняння показників помилок з вибірки 2% із базовою вибіркою 98% є справжньою проблемою статистичного висновку, а не просто порівнянням грубих цифр. Занадто мала частка «канаруша», або занадто короткий період спостереження, і справжні регресії можуть прослиснути під виглядом шуму.

Поступове розгортання: заміна інстанцій поступово

Поступове розгортання оновлює флот запущених інстанцій (сервери, контейнери або Kubernetes-поди) потроху, а не всі одразу. Типова політика передбачає виведення з ладу 25% інстанцій, їх заміну новою версією, очікування проходження ними перевірок стану та повернення до балансованого пулу, а потім повторення цього процесу з наступними 25%, поки весь флот не почне працювати з новою версією. На відміну від синього-зеленого розгортання, немає окремого дублювання середовища – флот поступово змінюється на місці, а на відміну від канарі, розподіл трафіку є наслідком кількості старих та нових інстанцій, зареєстрованих з балансовим пулом, а не навмисно контрольованим відсотком.

Це робить поступове розгортання ресурсоефективним (немає потреби в подвоєнні обсягів) але повільнішим у випадку відкочування, оскільки повернення передбачає повторення того ж процесу поступової заміни в зворотному напрямку. Це також означає, що на певний період часу обидві версії – стара та нова – одночасно перебувають у роботі і повинні бути сумісними з однаковими клієнтами, однаковою схемою бази даних та одна одною іншою – обмеження, яке іноді називається «сумісністю N-1», оскільки будь-який момент часу може мати версію N та версію N-1 одночасно обслуговувати запити до однієї й тієї ж бази даних.

Моделювання ризику як функції радіусу вибуху та часу виявлення

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

Корисно міркувати про це кількісно, уявивши собі графік «відсоток користувачів на новій версії» проти часу для кожної стратегії та наклавши на нього «кумулятивний вплив користувача на гіпотетичну регресію» під час інтеграції під криву. Синій-зелений створює криву, яка або дорівнює нулю, або максимальному впливу з майже відсутнім проміжним значенням; канар створює криву, нахил якої ви контролюєте безпосередньо через розмір і час кожного кроку трафіку; роулінгу створює криву, нахил якої визначається розміром партії та швидкістю заміни інстанцій. Жодна з цих стратегій не є універсально найкращою – правильний вибір залежить від того, наскільки дорогою є частковий відкат для цього конкретного змін, наприклад, станомі проти без стану, схематично пов’язаній проти незалежній, і наскільки чутливими є доступні сигнали здоров'я до типу регресії, про яку турбується команда.”]} 476

Футерні перемикачі як ортогональний, більш детальний контроль

Футерні перемикачі (також відомі як перемикачі ознак) повністю відокремлюють розгортання коду від виявлення ознак. Новий код ознаки може бути розгорнутий на 100% інстанцій — за допомогою будь-якої з описаних вище стратегій — і при цьому залишатися неактивним (вимкненим) через перемикач, який за замовчуванням вимкнено. Ознаку потім поступово вмикають для певних сегментів користувачів (відсоток облікових записів, конкретний клієнт, внутрішня команда) незалежно від того, який серверний інстанс обробляє дане запит. Це інший омірно, ніж стратегія розгортання: стратегія розгортання контролює, який код працює де, а перемикачі ознак контролюють, яким шляхом коду виконується для конкретного користувача після того, як він запущено. Поєднання цих двох — наприклад, ротаційне розгортання, яке відправляє код із перемикачем у вимкнено положенні, за яким слідує перемикач канарного типу, який збільшує виявлення ознаки сегментом користувачів замість інстанції — дає командам незалежний контроль над ризиками інфраструктури та продукту, тому більшість зрілих налаштувань CI/CD використовують перемикачі та стратегії розгортання разом, а не покладаються лише на один із них.

Часті запитання

Спробуйте наживо

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