Обычные так называемые революционные подходы к разработке программного обеспечения противоречат требованиям современных облачных платформ и программных платформ DevOps, в том числе требованиям гибкости, быстроты адаптации и непрерывного развертывания.
Недостаточно просто подготовить чек-лист действий, которые необходимо выполнить во время развертывания рабочей версии. Если вы так делаете, то вы никогда не станете достаточно гибким и, тем более, истинным DevOps-инженером.
1. Сине-зеленое развертывание: что это такое?
Сине-зеленое развертывание – это подход к развертыванию программного обеспечения, который позволяет сократить время простоя и риск появления новых версий программного обеспечения за счет создания двух идентичных сред: активной (синей) и неактивной (зеленой).
В активной среде запускается текущая версия программного обеспечения, и пользовали генерируют в ней рабочий трафик. В неактивной среде развертывается и тестируется новая версия программного обеспечения.
После того, как новая версия будет полностью протестирована и готова к релизу, трафик переключается с активной среды на неактивную, превращая ее таким образом в новую активную среду. При необходимости этот процесс можно повторить.
Связь с DevOps
Сине-зеленое развертывание хорошо согласуется с идеологией и процессами DevOps, а все потому, что оно поддерживает непрерывную доставку и развертывание программного обеспечения, минимизируя при этом время простоя рабочих пользователей и устраняя риск сбоя в рабочей версии.
Наличие двух идентичных сред позволяет тестировать и развертывать новые версии программного обеспечения без ущерба для текущей рабочей среды. Это значит, что релизы станут более быстрыми и частыми, что является ключевым аспектом DevOps.
Помимо этого, вы можете быстро переключать трафик между средами, что позволяет выполнить быстрый откат в случае возникновения каких-либо проблем, что также важно в DevOps-среде.
2. Важнейшие концепции сине-зеленого развертывания
#1. Две идентичные среды
Сине-зеленое развертывание требует от вас создания двух идентичных сред: активной (синей) и неактивной (зеленой). В данном случае понятие «идентичность» относится к данным и процессам.
Синяя среда – это место, где пользователи выполняют свою повседневную работу. Зеленая среда постоянно синхронизируется с синей, но на ней тестировщики запускают свои тестовые сценарии. Несмотря на то, что эта среда не является рабочей, вы запускаете тесты в реальных условиях, так как она очень похожа на рабочую.
#2. Переключение трафика
После того, как новая версия программного обеспечения будет полностью протестирована и готова к релизу, трафик переключается с активной среды на неактивную, превращая ее таким образом в новую активную среду.
Переключение происходит мгновенно. Все развертывания остались далеко в прошлом, и никаких простоев. Пользователям даже не нужно ничего делать, чтобы переместиться в новую среду – они перенаправляются туда автоматически.
#3. Быстрый откат
То, что вы можете быстро переключать трафик, также означает, что вы можете выполнить быстрый откат в случае возникновения каких-либо проблем. Таким образом, вы можете обеспечить минимальное время простоя и сохранить доступность приложения.
#4. Автоматизированное тестирование
Автоматизированное тестирование – это ключевой аспект сине-зеленого развертывания. Это значит, что новая версия программного обеспечения будет протестирована от и до, прежде чем будет развернута в активной среде.
Если вы не автоматизировали большую часть тестов в своих системах (как минимум модульные, функциональные и регрессионные тесты), то, возможно, вам не стоит задумываться о реализации сине-зеленого развертывания.
Отсутствие такой вещи, как автоматизация тестирований, существенно замедлит вашу работу. Количество времени, которое вы потратите на тестирование новой (зеленой) среды, будет настолько большим, что к тому моменту, как вы сможете переключиться на зеленую среду, она уже будет «слишком старой» с точки зрения жизненного цикла разработки программного обеспечения.
#5. Непрерывное развертывание
Сине-зеленое развертывание является частью конвейера непрерывного развертывания, а это значит, что релизы программного обеспечения будут более быстрыми и, соответственно, более частыми.
Вы можете переключаться с одной среды на другую, как только будете готовы протестировать новую версию ПО в «зеленой» среде. Поскольку само развертывание уже было выполнено, от вас требуется лишь переключить трафик, что довольно быстро. Вы можете это делать хоть каждый день, если, конечно, также быстро тестируете.
3. Стандартный жизненный цикл
Платформа, на которой выполняется сине-зеленое развертывание, имеет свой собственный жизненный цикл – набор этапов и процессов. Как правило, он состоит из следующих этапов:
- Создание новой версии программного обеспечения. Сюда входит компиляция кода, запуск автоматизированных тестов и создание развертываемого артефакта.
- На следующем этапе вы развертываете новую версию ПО в неактивной (зеленой) среде. Сюда входит настройка среды, развертывание артефакта и настройка всех необходимых параметров.
- После того, как вы развернете новую версию ПО в «зеленой» среде, вы запускаете автоматизированные тесты с целью убедиться, что новая версия работает правильно. К этим тестам относятся функциональные, регрессионные, интеграционные и, если вы очень продвинуты, даже тесты производительности.
- Теперь вы переключаете трафик с активной (синей) среды на неактивную (зеленую). В данном случае, чтобы направить трафик в зеленую среду, необходимо выполнить обновление балансировщика нагрузки или настроек DNS. Разумеется, вы захотите, чтобы все это тоже было выполнено автоматически.
- После того, как трафик будет переключен, проверьте приложение с целью убедиться, что оно работает правильно. Сюда относится отслеживание ошибок, проблем с производительность и прочих проблем.
- Этот этап не является обязательным, и в целом не стоит доводить ситуацию до него. Но в случае если кто-нибудь обнаружит какие-либо существенные проблемы, просто переключите трафик обратно на синюю среду. Таким образом, вы выполните откат. Снова повторюсь, никаких простоев или разъединений связи. Вам нужно просто обновить балансировщик нагрузки или настройки DNS, чтобы направить трафик в «синюю» среду.
- Как только вы решите все проблемы и будете готовы вернуться к новой версии, переключите трафик обратно на «зеленую» среду. И снова – обновите балансировщик нагрузки или настройки DNS, чтобы направить трафик обратно в «зеленую» среду.
- И наконец, как только новая версия ПО станет стабильной и будет правильно функционировать, вы должны «списать» старую версию ПО, работающую в «синей среде. Она вам понадобиться для создания еще одной новой версии вашей системы.
4. Внедрение конвейеров CI/CD
Внедрение сине-зеленого развертывание в CI/CD-конвейер DevOps должно стать обычной практикой.
Обязательным условием является наличие двух описанных выше идентичных сред. И так как это автоматизированный процесс, в качестве инструмента написания кода вы можете использовать инфраструктуру, например, AWS CloudFormation, или даже облако-независимые сценарии Terraform для создания/воссоздания/обновления сред в рамках автоматизированных контейнеров.
Если у вас все это есть, то этот шаг к созданию полностью автоматизированного процесса развертывания будет относительно простым. Вы просто должны повторно воспользоваться уже существующими конвейерами и создать синюю и зеленую среды. Однако сейчас вам нужно добавить в конвейер процесс тестирования.
Процесс переключения трафика тоже можно автоматизировать. Это можно сделать с помощью таких инструментов, как AWS Elastic Load Balancer или NGINX. Этот этап подразумевает обновление балансировщика нагрузки и настроек DNS для направления трафика в зеленую среду после того, как новая версия ПО будет полностью протестирована и готова к релизу.
Следующее звено в этой цепочке – отслеживание. Для этого рекомендуется использовать такие инструменты, как AWS CloudWatch, New Relic или Datadog.
И наконец, вы можете повторно использовать уже существующие конвейеры для того, чтобы «списать» старую синюю среду. Здесь уже выбор за вами, будете ли вы уничтожать все службы и компоненты и воссоздавать их с нуля, или обновлять сценарии для каждой службы в этой цепи. В большинстве случаев первый вариант является более безопасным, так как, обновляя сценарии, вам придется разбираться с гораздо большим количеством тупиковых ситуаций.
5. Рекомендации по сине-зеленому развертыванию
Вам интересно, как использовать сине-зеленое развертывание самым выгодным для вас способом? Тогда вот вам несколько практических советов.
Разработайте надежную стратегию миграции базы данных
Когда вы разворачиваете новую версию ПО, вы должны быть уверены, что схема базы данных была обновлена корректно. Используйте стратегию миграции базы данных, например, Flyway или Liquibase, для того, чтобы управлять изменениями схемы базы данных.
Используйте инструменты канареечного анализа
Несмотря на то, что канареечное (Canary) развертывание – это контрпример сине-зеленого развертывания, мы все равно можем использовать некоторые из его технологий для совершенствования последнего.
Вы можете использовать инструменты канареечного анализа, например, Kayenta или Spinnaker, для того, чтобы анализировать производительность новой версии ПО в реальной среде. В данном случае речь идет о сравнении производительности новой версии ПО с производительностью старой.
Вы также можете использовать библиотеку переключения функциональности, например, Togglz, для того, чтобы включать/отключать какие-то функции в новой версии ПО. Таким образом, вы можете внедрять новые функции постепенно и в случае необходимости быстро их откатывать.
Используйте балансировщик нагрузки с проверками состояния
Используйте балансировщик нагрузки с проверками состояния, например, AWS Elastic Load Balancer или NGINX, для того, чтобы быть уверенным в том, что трафик направляется только в работоспособные экземпляры. Таким образом, вы можете гарантировать высокий уровень доступности приложения и минимизировать время простоя.
Используйте план откатов с автоматизированными откатами
Разработайте план отката на случай возникновения каких-либо проблем и автоматизируйте процесс отката с помощью специального инструмента, например, AWS CodeDeploy или Octopus Deploy. Таким образом, вы сможете минимизировать время простоя и сохранить высокий уровень доступности приложения.
Всякий раз, когда вы обнаруживаете какую-либо серьезную проблему в новой версии, в большинстве случаев это связано с «зеленой» средой.
Вам не нужно разрабатывать план отката для «синей» среды, так как она остается нетронутой, и вы можете вернуться к ней в любой момент, как захотите.
6. Проблемы сине-зеленого развертывания
Реализация сине-зеленого развертывания может создать некоторые проблемы для команд разработчиков. Вот некоторые стандартные проблемы:
- Настройка и управление двумя идентичными средами может быть довольно сложной и времязатратной задачей. Для этого требуются знания в области инфраструктуры, например, знание инструментов написания кода (Terraform или CloudFormation). Вам потребуется команда старших разработчиков, которая будет способна справиться с такими техническими задачами.
- Когда вы разворачиваете новую версию ПО, вы должны быть уверены, что схема базы данных была обновлена корректно. Это может оказаться не самой простой задачей, особенно если схема базы данных довольно сложна. Вам нужны надежные способы развертывания баз данных, которые бы позволили безошибочно обрабатывать действия по обновлению схем баз данных в автоматическом режиме.
- Сложным может оказаться анализ производительности новой версии ПО. Для этого требуется опыт работы с инструментами канареечного анализа, например, Kayenta или Spinnaker.
- Реализация переключения функциональности также может оказаться довольно сложной, особенно если приложение имеет огромное количество функций. Это требует подготовки хорошего плана и слаженной работы разработчиков.
- Тестирование новой версии ПО в реальной среде также может оказаться не самой простой задачей, особенно если у приложения довольно большое количество пользователей и серверов. Вам необходимо автоматизировать тестовые сценарии по максимуму. Кроме того, к вашим привычным обязанностям добавится координирование действий команды разработчиков и команды тестировщиков.
- Наличие хорошего программного решения для отслеживания – явление крайне редкое, но для правильной работы DevOps это необходимо. Как только это станет возможным, потратьте на это время и создайте решение с помощью проверенных служб (AWS CloudWatch, New Relic, Datadog).
7. Разница между сине-зеленым и канареечным развертываниями
Несмотря на то, что отличие от обычных методов развертывания вполне очевидно (в обычных процессах развертывания нет двух параллельно существующих сред с разными версиями ПО), отличие от канареечного развертывания будет несколько поинтересней.
Сине-зеленое развертывание подразумевает наличие двух сред (синюю и зеленую), которые постоянно синхронизируются в отношении данных. После того, как новая версия была протестирована и признана готовой к релизу, трафик переключается с активной среды на неактивную, превращая ее таким образом в новую активную среду. Вы не тратите ни капли времени на развертывание нового кода, а рабочая среда не простаивает. Все пользователи так и продолжают работать в текущей активной среде; переключение происходит для них незаметно.
Канареечное развертывание подразумевает развертывание новой версии ПО для небольшой группы пользователей, тогда как большая часть пользователей или серверов продолжают использовать текущую версию. Это постепенное развертывание, а не резкий переход. В данном случае непосредственными пользователями продукта являются тестировщики, хоть и являются лишь их частью. Эта группа активно тестирует новую версию ПО в рабочей среде и, когда она наконец станет стабильной, ее распространят среди остальных пользователей.
Что же все-таки лучше?
Ответ любого эксперта начнется с «это зависит от…», и как бы тривиально это не звучало, он подходит сюда больше всего.
Если для вашей системы на первом месте стоит высокий уровень доступности, то сине-зеленое развертывание для вас.
Если же вы предпочитаете более быструю обратную связь и более контролируемые (хотя и более медленные) откаты новой версии ПО, то вам больше подойдет канареечное развёртывание.
Важно здесь то, что они оба достаточно быстрые и гибкие для того, чтобы считать себя хорошими вариантами для создания серьезной DevOps-системы.
8. Конкретные примеры
Netflix использует сине-зеленое развертывание для развертывания новых версией своего онлайн-кинотеатра. Таким образом, Netflix может развертывать новые версии своего сервиса, не влияя на взаимодействие пользователей с ним. По сути, одновременно с этим Netflix также использует канареечное развертывание для других своих сервисов. Так что, это вполне нормально использовать разные подходы к развертыванию DevOps.
Кроме того, сине-зеленое развертывание используют Amazon и Etsy. С его помощью они развертывают новые версии своих онлайн-магазинов.
Вот еще один пример – LinkedIn. Он использует сине-зеленое развертывание для развертывания новых версий своей социальной сети.
И последнее, но от того не менее важное: IBM использует сине-зеленое развертывание для развертывания новых версий своей облачной платформы.
Все эти компании успешно внедрили сине-зеленое развертывание в инфраструктуру своих платформ. Можете брать с них пример.
Заключение
Как и канареечное, сине-зеленое развертывание нацелено на наилучшую оптимизацию уже существующих гибких процессов и методов бесперебойного незаметного развертывания нового ПО. Для таких подходов это задача максимум. Вы постоянно и довольно часто выполняете развертывание, но никто об этом не знает, никто этого не замечает и, в итоге, никому нет до этого дела.
Конечно, команду разработчиков может немного расстраивать, что никто не судачит об их новых релизах. Но если вы спросите меня, почему такой расклад наилучший, я вам отвечу: никто об этом не говорит, но все это используют.
