Развёртывание in-place и blue/green

Автоматизация развёртывания на AWS

Dunieski Otano

Amazon Web Services Solutions Architect

Сбой в 2 часа ночи

• Развёртывание сразу на все серверы прошло неудачно
• На каждом сервере работает неисправная версия
• Клиенты видят ошибки в течение часа
• Откат требует ещё одного полного развёртывания

Почему важна стратегия развёртывания

• Неудачный релиз может полностью остановить сервис
• Развёртывание сразу на все серверы = быстро, но рискованно
• Постепенное развёртывание = медленнее, но безопаснее
• Стратегия определяет масштаб последствий при сбое

Развёртывание in-place

• Развёртывание на тех же инстансах, что обслуживают трафик
• По одной партии за раз: половина, потом половина, или по одному
• Проверка состояния каждой партии перед переходом к следующей
• Дёшево: не нужна дополнительная инфраструктура

Развёртывание blue/green

• Blue = текущий рабочий парк серверов
• Green = новый парк серверов с новой версией
• Балансировщик нагрузки переключает трафик с blue на green
• Старый парк серверов остаётся доступным для быстрого отката

Lambda и ECS изначально работают по принципу blue/green

• Lambda: трафик переключается через указатель на псевдоним версии
• ECS: трафик переключается через замену набора задач
• Дублирование парка серверов, как в EC2, не требуется
• Всё равно нужно выбрать конфигурацию развёртывания

Выбор между in-place и blue/green

• Ограниченный бюджет, низкорисковый патч → in-place
• Нужен нулевой простой или мгновенный откат → blue/green
• Один устаревший сервер → in-place — единственный вариант
• Lambda или ECS → blue/green встроен по умолчанию

Откат в CodeDeploy

• Откат = повторное развёртывание последней успешной ревизии
• Запускается автоматически при сбое развёртывания
• Запускается автоматически по сигналу CloudWatch
• Откат blue/green: переключение балансировщика обратно

Давайте потренируемся!

Автоматизация развёртывания на AWS