AWS: Blue-green deployment

Автор: | 05/11/2016
 

aws-logo-square-02Строго говоря — тема не совсем относится к AWS. Тем не менее — оригинальный пост называется именно так.

Обзор

Деплой новой версии приложения требует изменений на PRODuction-системе. Изменения == риск. Имеется много техник деплоя — некоторые простые, некоторые более сложные. Некоторые требуют даунтайма — другие нет.

Blue/green Deployment — одна из таких техник. Она достаточно простая, не требует даунтайма приложения и, самое важдное — минимизирует риск.

Процесс выглядит так:

  1. Включение дополнительных ресурсов, необходимых для приложения
    • балансировщики нагрузки, группы безопасности и т.д.
  2. Деплой приложения Версии 1
    • весь трафик с балансировщика нагрузки направляется на это приложений
  3. Создание приложения Версии 2
    • обновлённое приложение с новым кодом
  4. Переключение трафика с Версии 1 на Версию 2
    • собственно — это и есть сам blue/green deployment — трафик, проходящий через балансировщик нагрузки, больше не направляется к Версии 1, а идёт к приложению Версии 2
  5. Удаление Версии 1
    • если приложение Версии 2 работает так, как ожидалось — вы можете удалить реурсы, использовавшиеся для поддержания работы приложения с Версией 1

Это — правильная, обычная процедура выполнения blue/green deployment-а.

В течении выполнения такого деплоя — приложение всегда остаётся онлайн, так как на краткий промежуток времени приложение Версии 1 и Версии 2 работают одновременно. И именно так достигается zero downtime. Как только приложение Версии 2 запущено и работает — приложение Версии 1 выключается. Это зависит только от того, насколько быстро ваш балансировщик нагрузки сможет выполнить переключение.

Но что произойдёт, когда всё пойдёт не по плану? Что, если в Версии 2 пропадает верхняя панель навигации, или перестаёт работать система авторизации?

Именно тут проявляется вся прелесть Blue/green deployment: деплой новой версии вызывает ноль изменений в предыдущей версии, она остаётся абсолютно неизменной, и она будет в рабочем состоянии.

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

Сравнение с циклическими обновлениями

Имеется и другой подход — «циклические обновления» (rolling updates). Он заключается в том, что вы выводите из эксплуатации 1 или больше серверов, деплоите новую версию приложения на него, и возвращаете его обратно в строй. Затем — процесс повторяется для всех серверов кластера.

Такой подход так же доступен в AWS ELB (Elastic Load Balancer).

Кратко рассмотрим преимущства и недостатки этого подхода:

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

Звучит неплохо, да?

Но что случится в таком случае, если приложение Версии 2 содержит баги? Тут проявляются минусы такого подхода:

  • У вас НЕТ последней рабочей версии приложения. Этот подход модифицирует имеющиеся сервера.
  • Откат обновлений может занять продолжительное время: если вы обновляете 10 серверов, по 5 за раз, а каждый деплой занимает 2 минуты, а ошибки появились, когда деплой завершён на 70% — ваша жизни превращается в боль. Откат обновлений займёт 28 минут.
  • Это сложный и тяготеющий к ошибкам способ. Вам потребуется дополнительынй сервис, который будет отслеживать состояние деплоя на нодах кластера. А как быть, если у вас имеется автоматическое мастабирование инстансов?

Хотя циклические обновления звучат неплохо в теории — но вы подвергаете себя риску при каждом таком деплое. Если вы используете Auto Scaling группы, меняете типы инстансов или пользовательские данные требуют изменения конфигурации запускаемых инстансов — за всем этим вам необходимо будет следить особенно пристально и использовать дополнительные утилиты для контроля и управления.

Почитать по теме

The DOs and DON’Ts of Blue/Green Deployment