Пояснення синьо-зеленого розгортання та його ролі в DevOps

Традиційні підходи «великого вибуху» до розробки програмного забезпечення несумісні з високими вимогами до гнучкості, гнучкості та безперервного розгортання сучасних хмарних програмних платформ і програмних платформ DevOps.

Недостатньо підготувати контрольний список кроків, які потрібно виконати вручну під час розгортання робочої версії. Якщо ви так робите, ви не є справді спритним і не належите до DevOps.

Синьо-зелене розгортання: огляд

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

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

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

Джерело: docs.aws.amazon.com

Контекст DevOps

Розгортання Blue-Green добре підходить до мислення та процесів DevOps, оскільки підтримує безперервну доставку та розгортання програмного забезпечення, мінімізуючи час простою для робочих користувачів і усуваючи ризик збою робочої версії.

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

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

Ключові принципи синьо-зеленого розгортання

#1. Два ідентичних середовища

Синє-зелене розгортання вимагає створення двох ідентичних середовищ. Це означає ідентичні з точки зору даних і процесів. Один активний (синій), а інший неактивний (зелений).

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

#2. Перемикач руху

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

Перемикання відбувається миттєво. Усі розгортання тепер у минулому. Немає вікна простою. Користувачам не потрібно нічого робити, щоб досягти нового середовища. Вони перенаправляються автоматично, причому всі одночасно.

Джерело: aws.amazon.com

#3. Швидкий відкат

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

Якщо щось піде не так із зеленим середовищем, усі користувачі миттєво повернуться до стабільного початкового синього середовища без будь-яких потрясінь.

#4. Автоматизоване тестування

Автоматизоване тестування є ключовим аспектом розгортання Blue-Green. Це забезпечує ретельне тестування нової версії програмного забезпечення перед її розгортанням в активному середовищі.

Якщо у вас немає значної кількості автоматизованих тестів у ваших системах (включаючи принаймні модульні тести, функціональні тести та регресійні тести), то, ймовірно, немає сенсу навіть думати про впровадження Blue-Green розгортання.

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

#5. Безперервна доставка

Розгортання Blue-Green є частиною безперервного потоку поставок, що в кінцевому підсумку означає швидші та частіші випуски програмного забезпечення у виробництво.

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

Типовий життєвий цикл

Платформа, на якій виконується розгортання Blue-Green, має свій власний життєвий цикл етапів і процесів. Ось з чого він зазвичай складається:

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

На наступному етапі ви розгортаєте нову версію програмного забезпечення в неактивному (зеленому) середовищі. Це передбачає налаштування середовища, розгортання артефакту та налаштування будь-яких необхідних параметрів.

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

Перемкніть трафік з активного (синього) середовища в неактивне (зелене) середовище. Це передбачає оновлення балансувальника навантаження або налаштувань DNS для спрямування трафіку в зелене середовище. Звичайно, ви хочете зробити це за допомогою автоматизованих процесів.

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

Цей крок є необов’язковим, і ви не хочете досягати його занадто часто. Але якщо хтось виявить будь-які суттєві проблеми, перемкніть трафік назад у синє середовище, щоб виконати миттєвий відкат. Знову ж таки, без будь-яких простоїв або відключень, пов’язаних із робочими користувачами. Просто оновіть балансир навантаження або налаштування DNS, щоб спрямувати трафік у синє середовище.

Коли ви вирішите ці проблеми та будете готові знову повернутися до нової версії, перемкніть трафік назад у зелене середовище. Тож ще раз – оновіть балансир навантаження або налаштування DNS, щоб спрямувати трафік назад у зелене середовище.

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

Впровадження конвеєрів CI/CD

Впровадження Blue-Green розгортання в конвеєр DevOps CI/CD має бути природним процесом.

Обов’язковою умовою є наявність цих двох ідентичних середовищ. Оскільки це буде автоматизований процес, ви можете використовувати інфраструктуру як кодовий інструмент, наприклад AWS CloudFormation або навіть хмарний агностик Тераформа сценарії для створення/відтворення/оновлення середовищ для вас у автоматизованих конвеєрах.

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

Процес перемикання трафіку можна автоматизувати за допомогою таких інструментів, як AWS Elastic Load Balancer або NGINX. Це передбачає оновлення балансувальника навантаження або налаштувань DNS для спрямування трафіку в зелене середовище, коли нова версія програмного забезпечення буде протестована та готова.

Наступною частиною головоломки є моніторинг. Для цього використовуйте такі інструменти, як AWS CloudWatch, Ннова реліквіяабо Datadog.

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

Найкращі практики синьо-зеленого розгортання

Цікаво дізнатися, як найкращим чином використовувати синьо-зелене розгортання? Ось деякі поради з практики.

Майте надійну стратегію міграції бази даних

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

Використовуйте Canary Analysis Tool

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

Використовуйте інструмент аналізу canary, наприклад Кайента або спінакер для аналізу продуктивності нової версії програмного забезпечення в реальному середовищі. Це передбачає порівняння продуктивності нової версії програмного забезпечення з продуктивністю старої версії програмного забезпечення.

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

Використовуйте балансувальник навантаження з перевірками справності

Використовуйте балансувальник навантаження, такий як AWS Elastic Load Balancer або NGINX, із перевіркою працездатності, щоб гарантувати, що трафік спрямовується лише на справні екземпляри. Це забезпечує високу доступність програми та мінімізує час простою.

Використовуйте план відкату з автоматичним відкатом

Створіть план відкату на випадок проблем і автоматизуйте процес відкоту за допомогою таких інструментів, як AWS CodeDeploy або Octopus Deploy. Це гарантує мінімізацію часу простою та збереження високої доступності програми.

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

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

Проблеми з синьо-зеленим розгортанням

Впровадження Blue-Green розгортання може спричинити певні труднощі для команд розробників. Ось кілька типових викликів:

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

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

Аналіз продуктивності нової версії програмного забезпечення в реальному середовищі може бути складним завданням. Для цього потрібен досвід роботи з такими інструментами для аналізу канарок, як Kayenta або Spinnaker.

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

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

Наявність хорошого рішення для моніторингу — це дуже рідкісна реальність, але для належної роботи DevOps це обов’язково. Як тільки стане можливим, інвестуйте час у створення цього рішення за допомогою перевірених сервісів (AWS CloudWatch, New Relic, Datadog).

Різниця між розгортанням Blue-Green і Canary

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

Синьо-зелене розгортання означає два середовища (синє та зелене). Але в той же час два середовища постійно синхронізуються з точки зору даних. Після того, як нова версія перевірена та вважається готовою, трафік перемикається з активного середовища в неактивне, перетворюючи його на нове активне середовище. Ви не витрачаєте час на розгортання нового коду, і немає простою виробництва. Усі робочі користувачі постійно працюють у поточному активному середовищі й навіть не помічають перемикання.

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

Який із них кращий?

Сюди найбільше підходить відповідь консультанта «залежить», як би злобно це не звучало.

Якщо для вашої системи пріоритетом є висока доступність, то ваш вибір стане синьо-зеленим розгортанням.

Якщо ви надаєте перевагу швидшому зворотному зв’язку та більш контрольованому (хоча й повільнішому) розгортанню нової версії системи, тоді розгортання Canary має переваги перед Blue-Green.

Важливо те, що обидва вони достатньо гнучкі, щоб вважати себе достатньо хорошими для створення серйозної системи DevOps.

Тематичні дослідження

Netflix використовує розгортання Blue-Green для розгортання нових версій свого потокового сервісу. Використовуючи Blue-Green розгортання, Netflix може розгортати нові версії свого сервісу, не впливаючи на взаємодію з користувачем. Насправді Netflix також паралельно використовує розгортання Canary для інших випадків, тому нереально об’єднати різні підходи до розгортання DevOps під одним дахом.

Крім того, Amazon і Etsy використовують Blue-Green розгортання для розгортання нових версій своєї платформи електронної комерції.

Іншим прикладом є LinkedIn, який використовує розгортання Blue-Green для розгортання нових версій своєї платформи соціальних мереж.

І останнє, але не менш важливе: IBM використовує розгортання Blue-Green для розгортання нових версій своєї хмарної платформи.

Ці компанії успішно впровадили Blue-Green розгортання на своїх інфраструктурах платформ і служать хорошим прикладом для інших.

Заключні слова

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

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

Далі перегляньте поширені запитання та відповіді на інтерв’ю DevOps.