Образ собран, тесты пройдены, в реестре лежит новая версия. Остается последний шаг, а именно – деплой на прод. И вот тут возникает вопрос: как именно подменить работающую старую версию на новую там, где прямо сейчас сидят живые пользователи. Сделать это можно по-разному, и от выбора зависит, заметят ли люди обновление и что будет, если новая версия окажется битой.
Напоминание из модуля про Docker: приложение в проде живет не в одном экземпляре, а в нескольких одинаковых контейнерах-копиях, между которыми распределяется нагрузка. Стратегия деплоя описывает, в каком порядке менять эти копии.
Наивный способ, все разом
Самый прямой путь, погасить все старые копии и поднять вместо них новые.
У способа две беды. Первая – простой: между «погасили старое» и «подняли новое» есть промежуток, когда не отвечает никто, и пользователь видит ошибку. Вторая хуже: если новая версия сломана, на нее разом перекидывает всех, и отступать некуда. Поэтому так делают только там, где минута простоя не страшна. На серьезных сервисах деплоят иначе, и дальше как раз три способа про это.
Rolling update
Идея, которую мы уже упоминали: не менять все разом, а заменять копии по очереди. Погасили одну старую, подняли на ее месте новую, убедились, что взлетела, перешли к следующей.
Простоя нет: в любой момент часть копий обслуживает запросы. Если на какой-то копии новая версия не поднялась, выкатку останавливают, не тронув остальные. Платой за это идет момент, когда старая и новая версии работают одновременно, и к этому приложение должно быть готово. Rolling update, способ по умолчанию во многих системах, в том числе в Kubernetes, к которому вы придете дальше.
Blue-green
Здесь подход другой: держат не одно окружение, а два одинаковых. Одно, условно «синее», сейчас принимает весь трафик. Второе, «зеленое», стоит рядом пустым. Новую версию выкатывают целиком на зеленое, спокойно проверяют ее, пока на нем нет пользователей, а потом разом переключают трафик с синего на зеленое.
Переключением занимается балансировщик, сервис, который распределяет входящий трафик между копиями приложения. Плюсы тут весомые: переключение мгновенное, простоя нет, а откат тоже мгновенный, если на зеленом что-то пошло не так, балансировщик возвращают на синее, которое все это время никто не трогал. Минус честный: нужно держать вдвое больше ресурсов, ведь два полных окружения работают одновременно.
Canary
Третий способ, вместо того чтобы катить новую версию сразу всем, показывает её только маленькой доле пользователей, например пяти процентам. За этой группой следят по метрикам из модуля про мониторинг: растут ли ошибки, не подскочило ли время ответа. Если все спокойно, долю плавно увеличивают до 100%. Если полезли ошибки, откатывают, и пострадали только те самые пять процентов, а не все.
Canary: новую версию сначала видят 5% пользователей, при норме долю растят, при ошибках откатывают
Факт. Название пришло из угольных шахт. Шахтеры брали с собой в забой канарейку: птица гораздо чувствительнее человека к рудничному и угарному газу, и если она начинала беспокоиться или замолкала, это был сигнал уходить, пока не отравились люди. В Британии канареек в шахтах официально использовали до 1986 года, пока их не заменили электронные датчики. В деплое канарейка, это те самые 5% пользователей: на них проблема проявится первой, предупредив остальных.
Что когда выбирают
| Стратегия | Как | Простой | Откат | Цена и нюанс |
|---|---|---|---|---|
| Recreate (все разом) | погасить старое, поднять новое | есть | тяжелый | просто, но грубо |
| Rolling | менять копии по очереди | нет | постепенный | момент со смешанными версиями |
| Blue-green | переключить трафик между двумя окружениями | нет | мгновенный | нужно вдвое больше ресурсов |
| Canary | сначала малой доле, следя за метриками | нет | минимальные потери | нужен умный роутинг трафика и метрики |
Единственно правильной стратегии нет, выбирают под задачу. Rolling берут по умолчанию, когда хватает плавной замены. Blue-green, когда важен мгновенный откат и есть ресурсы на второе окружение. Canary, когда цена ошибки высока, пользователей много и хочется поймать беду на маленькой группе. Их и комбинируют: например, выкатывают канарейкой, а внутри идет rolling.
Через все три проходит одна мысль, откат. Смысл стратегий не в красоте выкатки, а в том, чтобы битая версия не положила сервис целиком и к рабочему состоянию можно было вернуться быстро: переключить балансировщик обратно, остановить канарейку, развернуть rolling вспять.
Причем здесь DevOps
Руками это не делают. Стратегия деплоя описывается в конфигурации, в пайплайне или в настройках Kubernetes, который по умолчанию катит rolling update, а blue-green и canary настраивают поверх. |