Все о стратегии развертывания Blue Green!

Еще в 2005 году два разработчика по имени Даниэль Терхорст-Норт и Джез Хамбл решали проблемы со своим сайтом электронной коммерции. Они были разочарованы тем, что даже при наличии хорошей системы тестирования, ошибки все равно обнаруживаются на гораздо более поздних стадиях производства. После этого они провели детальный анализ первопричины, результаты которого показали существенную разницу в условиях тестирования и производственной среды, и эти различия приводили к частым сбоям.

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

После последующего успеха они назвали эту стратегию «Сине-зеленой стратегией развертывания».

Требования перед реализацией стратегии сине-зеленого развертывания

1. Должны быть доступны две идентичные среды
2. Необходимо убедиться, что новый код может быть запущен вместе с существующим кодом, поскольку они будут работать одновременно в производственной среде.
3. Балансировщик нагрузки для маршрутизации трафика. Создаются две идентичные платформы — синяя среда и зеленая среда. В синей среде хранится существующая версия, а в зеленой — более новое обновление (или как вам удобнее, правила как такового нет, это просто для обозначения).

Шаги, участвующие в стратегии сине-зеленого развертывания

Стратегию развертывания Blue Green можно разбить на четыре этапа:

Шаг 1: Настройка балансировщика нагрузки

Теперь, когда у нас есть две среды, мы хотим направить трафик в зеленую среду, где мы развернули наше новое обновление. Для этого нам нужен балансировщик нагрузки, хотя это можно сделать через обмен DNS-записями, но это не очень предпочтительно, поскольку распространение DNS не является мгновенным.
При использовании балансировщика нагрузки и маршрутизатора для переключения трафика между двумя экземплярами нет необходимости менять записи DNS, балансировщик нагрузки будет указывать на те же записи DNS, но трафик теперь направляется в «зеленую» среду.
Используя балансировщик нагрузки, мы имеем полный контроль над каналом пользователей, что подразумевает, что мы можем переключить их обратно на старую/существующую версию, т.е. в нашем случае мы поместили ее в синий экземпляр мгновенно, в случае любого сбоя в зеленом экземпляре.

Шаг 2: Выполнить обновление

После того как наш зеленый экземпляр готов, мы переносим его в продакшн и запускаем одновременно с существующим кодом. Балансировщик нагрузки эффективно направляет трафик от синего к зеленому. Эта операция проходит незаметно для пользователей.

Шаг 3: Мониторинг среды

Поскольку трафик направляется на новый зеленый экземпляр, инженеры DevOps получают узкий промежуток времени для проведения дымового тестирования нового экземпляра. Это необходимо для того, чтобы убедиться, что все аспекты нового экземпляра работают нормально. Это очень важный шаг, позволяющий выявить все существующие ошибки, прежде чем они проявятся в широком масштабе.

Шаг 4: Развертывание или откат

На этом этапе, когда во время дымового теста обнаруживается какая-либо ошибка, пользователи немедленно перенаправляются на старую версию или синий экземпляр. В некоторых случаях ошибки выявляются только после того, как приложение работает в течение некоторого времени, поэтому даже после успешного дымового тестирования инженеры devops отслеживают всю операцию, чтобы понять и найти ошибки или любые другие проблемы.
Если с новым зеленым экземпляром все в порядке, он становится нашим синим экземпляром для следующего обновления.

Преимущества стратегии сине-зеленого развертывания

Приятный опыт работы с клиентами

Это вполне возможно, когда у нас есть балансировщик нагрузки для безопасного перенаправления трафика на старую/существующую версию без внесения изменений в записи DNS (в случае, если новый экземпляр показывает ошибки). Действия по маршрутизации настолько быстрые, что не вызывают никаких простоев у клиентов/пользователей.

Мгновенный откат

Это так же просто, как нажать кнопку отмены, без каких-либо негативных последствий. Когда действия по маршрутизации быстро отвлекают пользователей, проще развернуть новые обновления для экспериментов, а также мгновенно откатиться назад в случае любой ошибки или сбоя.

Больше не нужно ждать окон обслуживания

Ранее инженерам DevOps приходилось ждать и отслеживать дни, когда трафик не работал, проводить плановые простои, чтобы развернуть определенные обновления. Эти плановые простои приносили значительные убытки.

Тестирование паритета

Результаты являются точными, если предоставленные условия являются реальными, или среда, в которой развернуты новые обновления, испытывает такой же стресс, как и производственная среда. Эквивалентность двух экземпляров — синего и зеленого — делает их идеальным выбором для проведения аварийного восстановления.
По сравнению с Canary Deployment используется небольшой фрагмент производственной среды, и для тестирования обновления направляется крошечный объем трафика. Хотя это выгодный подход, при ограниченных условиях воздействия нового обновления мы не можем составить полную картину работы обновления, когда оно будет окончательно развернуто и станет доступным для всех.

Проблемы стратегии «сине-зеленого» развертывания

Неудачная транзакция пользователя

Во время первоначального перехода на «зеленый» экземпляр или новый развернутый экземпляр некоторые пользователи будут вынуждены выйти из приложения, а в некоторых случаях сервисы могут не работать. Если новое обновление не работает, и требуется переключение обратно на старую среду, то пользователи, вошедшие в «зеленую» среду, могут столкнуться с внезапной блокировкой сервисов.
Эти проблемы можно решить с помощью современных балансировщиков нагрузки, которые обычно работают путем замедления входящего трафика, а не принудительно выводят всех пользователей из их текущих сессий или ждут, пока пользователи станут неактивными.

Рост затрат на инфраструктуру

Для реализации стратегии Blue Green Deployment Strategy предприятиям требуется поддерживать инфраструктуру, вдвое превышающую размер их приложений. Эта стратегия является хорошим выбором только в том случае, если наше приложение не настолько требовательно к аппаратному обеспечению. Идеальным решением в этом случае будет использование эластичной инфраструктуры, которая поможет покрыть расходы.

Совместимость кодов

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

Заключение

Хотя стратегия развертывания Blue Green подразумевает затраты, это один из самых надежных подходов, когда речь идет о проверке состояния приложения. Это идеальный вариант, когда наши среды согласованы между выпусками, а пользовательские сессии надежны в течение нескольких новых выпусков.
Важно отметить, что постоянно растущая потребность в принятии сложных моделей, таких как стратегия развертывания Blue Green, создала новое пространство для таких сложных услуг, как Managed DevSecOps. Они обеспечивают сквозное выполнение модели ускоренного выхода на рынок за счет

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

Меняющиеся требования приводят к меняющимся тенденциям, и быть их частью — это то, что держит любой бизнес на плаву. Единственный способ поддержать этот динамичный рынок — создать свое собственное пространство, которое создается в результате удовлетворенной клиентской базы.