Сообщить об ошибкеКороткий ответ
Новая версия полностью разворачивается в «зелёном» окружении, проходит smoke-тесты без боевого трафика, после чего балансировщик (или weighted DNS/Target Group) одномоментно переключает весь трафик на зелёное окружение; при обнаружении проблемы откат выполняется обратным переключением балансировщика на «синее» окружение, которое какое-то время держат нетронутым именно для этого случая.
Как это работает подробнее
переключение на уровне балансировщика (например, смена Target Group в AWS ALB или weight в Route 53) намного быстрее, чем пересоздание инфраструктуры, и занимает секунды, в отличие от постепенной замены подов при rolling update. Пока «синее» окружение простаивает, его можно использовать как мгновенный rollback-путь.
Пример кода
example.sh
# Переключение на green:
aws elbv2 modify-listener --listener-arn $LISTENER_ARN \
--default-actions Type=forward,TargetGroupArn=$GREEN_TG_ARN
# Обнаружена проблема -> быстрый откат на blue:
aws elbv2 modify-listener --listener-arn $LISTENER_ARN \
--default-actions Type=forward,TargetGroupArn=$BLUE_TG_ARNЧто использовать на практике
- На практике. нужно заранее продумать работу с состоянием — если новая версия пишет данные в общую БД в несовместимом формате, откат на старую версию кода может привести к ошибкам чтения; поэтому миграции БД для blue-green стараются делать обратно совместимыми (expand-contract). Также важно держать «синее» окружение прогретым (кэши, соединения), чтобы откат не вызвал проблем холодного старта.
- Пример. Ожидаемое поведение: после первой команды весь новый входящий трафик идёт на green Target Group; при откате вторая команда возвращает трафик на blue за секунды, без пересоздания инфраструктуры и без простоя.
Подводные камни
- Частые ошибки. удаляют старое окружение сразу после переключения «для экономии», лишая себя быстрого отката; не учитывают разницу во времени жизни сессий пользователей — часть пользователей может оставаться подключённой к «синему» через sticky-сессии и не увидеть новую версию сразу.