Все статьи

Стратегии развертывания в DevOps

31 янв 20234729

Ускорение деплоя приложений и их новых версий — одна из задач DevOps.
Частые развертывания позволяют компаниям ускорить time to market: быстрее доставлять новые функции приложения пользователям, проверять продуктовые гипотезы и оперативно получать обратную связь.

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

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

В этой статье мы кратко рассмотрим различные стратегии деплоя, включая Recreate, Rolling, Multi-version, Blue/Green, Canary, A/B-тестирование:

  • сценарии, в которых оптимально использовать ту или иную стратегию;
  • ограничения стратегий.

Повторное создание (Recreate)

Стратегия состоит из двух шагов:
  • удаление текущей версии приложения;
  • развертывание новой версии.

Это самая простая стратегия, но в то же время наименее оптимальная: у вас будет простой на время деплоя новой версии, а если что-то пойдет не так, то сложно будет откатиться к предыдущей версии.



Постепенное развертывание (Rolling)

В этой стратегии все инстансы приложения будут последовательно обновляться до новой версии. Каждый инстанс проходит следующий цикл:
  • удаляется один из инстансов со старой версией приложения (остальные продолжают работать);
  • запускается инстанс с новой версией;
  • проверяется корректный запуск нового инстанса. Если все хорошо, переходим к следующему инстансу и проделываем то же самое.

Мультиверсии

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


Сине-зеленое развертывание (Blue/Green)

Эта стратегия базируется на двух продуктивных средах:

  • «синяя» — там, где живут старые версии приложения;
  • «зеленая» — зона, где мы запускаем новую версию приложения.

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


Канареечное развертывание (Canary)

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


Почему такой деплой называется канареечным?

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

A/B-тестирование

Фактически это вариация канареечного развертывания применительно для фронтенда. Здесь также запускается ограниченное количество инстансов c новой версией приложения, на которую переключается часть пользовательского трафика.

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