Blue-Green Deployment паттерн

Описание Blue Green Deployment, разберем что это

Наибольший риск при выпуске новой версии в продакшн - это обнаружение ошибок и проблем, сразу после релиза. Даже если вы тщательно протестируете новые функции в своих средах тестирования QA\QC, они могут вести себя по-разному в продакшин среде. Но есть решение: Деплой по методу Blue-Green - это метод снижения рисков при развертывании новых версий напродакшин. Это достигается путем работы с двумя одинаково настроенными средами, одной production (общедоступной) и одной внутренней (Staging), и переключением между ними.

В Blue-Green deployment мы используем две идентичные среды: одну с именем «Синяя», а другую «Зеленую». Присвоение имен Blue / Green - это просто способ различения двух отдельных сред: поскольку одна и та же среда может служить в один день как производственная, а в другай раз как тестовая среда, мы должны ссылаться на них с постоянными именами, независимо от роли, которую они выполняют. играть. Некоторые называют это развертыванием A / B, некоторые называют его staging/ production.  

Зеленый и синий  environment подключены к одной базе данных, настроены практически одинаково и ведут себя одинаково. Единственное отличие состоит в том, что одна из них - это live production среда (скажем, Зеленая), и все ваши пользователи используют ее, в то время как другая (Синяя) открыта только внутри для тестирования.

Таким образом новый релиз будет заливатся на ту среду, где сейчас находится Staging например на домене test.Mydomain.com и на green сервере, после того как приложение будет протестировано, Мы поменяем местами DNS где test.Mydomain.com будет теперь смотреть на blue сервер (где был ранее продакшн) а продакшн mydomain.com будет смотреть на green сервер (где мы тестировали релиз кандидата).

Blue-Green Deployment Best Practices для плавного перехода на новый сервер.

1. Используйте load balancer через DNS коммутатор.

Современные клауд сервисы такие как Azure, AWS сразу предоставляют инфрастуктуру и deployment слоты для простого развертывания с подходом blue/green. 

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

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

2. Используйте Rolling update

Подход Rolling Update используется в том числе в таком популярном оркестраторе как kubernetes. Суть в том что вместо переключения со всех серверов Blue на все серверы Green в одном режиме вы можете работать с интегрированной средой. Добавьте один новый сервер, удалите один старый сервер и повторяйте это, пока все новые серверы не будут внутри (см. Изображение ниже):

Однако нужно убедиться, что ваш новый код может работать вместе со старым кодом, потому что они будут работать бок о бок (подробнее об обратной и прямой совместимости ниже).

Обратите внимание, что вам нужно будет использовать 'connection draining' на вашем балансировщике нагрузки, чтобы запросы, обработанные старыми серверами, имели возможность завершиться до того, как старый сервер будет отключен.

3. Контролируйте свои Environments с помощью правильных алертов

Мониторинг продакшина очевиден, но мониторинг тестовой среды также важен - вы хотите поймать эти проблемы до того, как они достигнут продакшина, верно? Однако не продакшн мониторинг менее важен, что б найти проблему на более ранних стадиях.

4. Автоматизировать, автоматизировать, fвтоматизировать

Автоматизируйте как можно больше действий которые вы делаете в процессе переключения с green на blue и наоборот вместо того что б делать это вручную.

Это имеет большие преимущества:

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

5. Сделайте ваш код обратно и вперед совместимым

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

Чтобы избежать downtim'a, вы можете разбить обновление на несколько «мини-обновлений». Например, допустим, вы меняете имя поля базы данных с «user_name» на «username».

Этот релиз потребует следующих шагов:

• Зарелизте промежуточную версию кода, которая может найти и работать с «user_name» и «username» с некоторый бизнес логикой вокруг этого.
• Запустите миграцию данных - переименуйте поле в «username» для всех записей / документов в базе данных.
• Зарелизте окончательную версию кода, поддерживающую только «имя пользователя», и полностью удалите старый код, поддерживающий «имя_пользователя».

Blue-Green Deployment в Cloud

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

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

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