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

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

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

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

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

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

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

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

Контекст DevOps

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

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

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

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

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

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

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

#2. Перемикання трафіку

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Створення нової версії програмного забезпечення, що передбачає компіляцію коду, запуск автоматизованих тестів і створення артефакту, готового до розгортання.
  • Розгортання нової версії програмного забезпечення в неактивному (зеленому) середовищі, включаючи налаштування середовища, розгортання артефакту та необхідні конфігурації.
  • Після розгортання нової версії програмного забезпечення в зеленому середовищі, потрібно запустити автоматизовані тести для перевірки її правильного функціонування. Це можуть бути функціональні, регресійні, інтеграційні тести, а також, за потреби, тести продуктивності.
  • Перемикання трафіку з активного (синього) середовища на неактивне (зелене), шляхом оновлення конфігурацій балансувальника навантаження або DNS. Звісно, цей процес має бути автоматизованим.
  • Після завершення перемикання, потрібен моніторинг застосунку для перевірки його стабільної роботи. Це включає відстеження помилок, проблем з продуктивністю та інших питань.
  • Цей крок є необов’язковим, але у разі виявлення суттєвих проблем, трафік можна перенаправити назад в синє середовище для миттєвого відкату. Знову ж таки, без будь-яких простоїв або збоїв у роботі. Для цього потрібно просто оновити налаштування балансувальника навантаження або DNS для перенаправлення трафіку в синє середовище.
  • Після усунення проблем та готовності повернутися до нової версії, трафік перемикається знову в зелене середовище, шляхом оновлення конфігурацій балансувальника навантаження або DNS.
  • І насамкінець, коли нова версія програмного забезпечення стає стабільною та працює належним чином, стара версія, що функціонує в синьому середовищі, виводиться з експлуатації. Це потрібно для підготовки до створення нової версії системи.
  • Впровадження конвеєрів CI/CD

    Інтеграція синьо-зеленого розгортання в конвеєр DevOps CI/CD є природним етапом.

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

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

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

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

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

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

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

    Наявність надійної стратегії міграції бази даних

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

    Використання інструменту аналізу canary

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

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

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

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

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

    План відкату з автоматизованим відкатом

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

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

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

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

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

  • Налаштування та керування двома ідентичними середовищами може бути складним і потребувати багато часу. Це вимагає досвіду роботи з інструментами інфраструктури як коду, такими як Terraform або CloudFormation. Потрібна кваліфікована команда розробників, здатна вирішувати такі технічні завдання.
  • Під час розгортання нової версії програмного забезпечення важливо правильно оновити схему бази даних. Це може бути складно, особливо якщо схема бази даних є комплексною. Потрібні надійні процеси розгортання бази даних, здатні автоматично та надійно обробляти оновлення схеми.
  • Аналіз продуктивності нової версії програмного забезпечення в реальному середовищі може бути складним завданням. Для цього потрібен досвід роботи з інструментами аналізу canary, такими як Kayenta або Spinnaker.
  • Реалізація перемикачів функцій може бути складною, особливо якщо програма має багато функцій. Це вимагає ретельного планування та координації між командами розробників.
  • Тестування нової версії програмного забезпечення в реальному середовищі може бути складним, особливо якщо програма має багато користувачів або серверів. Потрібно максимально автоматизувати тестові кейси. Крім того, рутинні процеси повинні включати значну координацію між командами розробки та тестування.
  • Хороше рішення для моніторингу є рідкістю, але необхідною умовою для належної роботи DevOps. Інвестуйте час у створення такого рішення за допомогою надійних сервісів (AWS CloudWatch, New Relic, Datadog).
  • Різниця між синьо-зеленим та Canary розгортанням

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

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

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

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

    Тут найбільш доречною є відповідь консультанта “залежить”, як би це не звучало.

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

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

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

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

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

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

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

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

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

    Підсумки

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

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

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