Строго говоря – тема не совсем относится к AWS. Тем не менее – оригинальный пост называется именно так.
Содержание
Обзор
Деплой новой версии приложения требует изменений на PRODuction-системе. Изменения == риск. Имеется много техник деплоя – некоторые простые, некоторые более сложные. Некоторые требуют даунтайма – другие нет.
Blue/green Deployment – одна из таких техник. Она достаточно простая, не требует даунтайма приложения и, самое важдное – минимизирует риск.
Процесс выглядит так:
- Включение дополнительных ресурсов, необходимых для приложения
- балансировщики нагрузки, группы безопасности и т.д.
- Деплой приложения Версии 1
- весь трафик с балансировщика нагрузки направляется на это приложений
- Создание приложения Версии 2
- обновлённое приложение с новым кодом
- Переключение трафика с Версии 1 на Версию 2
- собственно – это и есть сам blue/green deployment – трафик, проходящий через балансировщик нагрузки, больше не направляется к Версии 1, а идёт к приложению Версии 2
- Удаление Версии 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
