Стратегии развертывания (Deployment Strategies)

🚀 Стратегии развертывания (Deployment Strategies)

Развертывание (deployment) — это процесс обновления приложения в продакшн-среде.
От выбранной стратегии зависит время простоя (downtime), риски ошибок и скорость доставки новой версии пользователям.

🧩 1. Recreate (с даунтаймом)

Самая простая и «классическая» стратегия.
Старая версия приложения полностью останавливается, после чего разворачивается новая.

v1 ──────────────╳───────────────
                        ↓
                     Deploy v2
                        ↓
v2 ──────────────────────────────▶

Плюсы:

• Простота настройки
• Минимальные ресурсы (одна версия в каждый момент времени)

Минусы:

• Полный даунтайм во время деплоя
• Риск неудачного обновления без возможности мгновенного отката

Пример:

kubectl rollout restart deployment my-app

В Kubernetes это приведёт к остановке всех pod’ов и запуску новых.

⚙️ 2. Rolling Update (без даунтайма)

Постепенное обновление экземпляров приложения.
Новая версия запускается поштучно, параллельно со старой, пока все старые инстансы не заменятся.

v1 v1 v1 v1 → v2 v1 v1 v1 → v2 v2 v1 v1 → v2 v2 v2 v1 → v2 v2 v2 v2

Плюсы:

• Без даунтайма
• Плавный переход и возможность остановить rollout при ошибке

Минусы:

• Требует балансировщика (Load Balancer)
• Может быть сложнее контролировать версию трафика

Пример (Kubernetes):

kubectl set image deployment/my-app my-app=repo/app:v2
kubectl rollout status deployment/my-app

🟢 3. Blue-Green Deployment

Поддерживаются две среды:

• Blue — текущая версия
• Green — новая версия

После развертывания новой версии, трафик просто переключается с Blue на Green.

Users → Blue (v1)
       ↓ switch
Users → Green (v2)

Плюсы:

• Без даунтайма
• Легкий откат (просто вернуть трафик на старую среду)

Минусы:

• Удвоенные ресурсы (две среды активны)
• Необходима интеграция с балансировщиком или proxy

Пример:

# Пример nginx reverse proxy
server {
    location / {
        proxy_pass http://green_backend; # переключаем с blue_backend на green_backend
    }
}

🧪 4. Canary Deployment

Новая версия выкатывается ограниченной группе пользователей.
Если всё хорошо — процент трафика постепенно увеличивается.

5% → 25% → 50% → 100%

Плюсы:

• Минимальный риск
• Контролируемое тестирование в реальной среде

Минусы:

• Требует сложной маршрутизации (feature flags, service mesh)
• Более длительный процесс развертывания

Пример (Kubernetes + Istio):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
spec:
  http:
  - route:
    - destination:
        host: my-app
        subset: v1
      weight: 90
    - destination:
        host: my-app
        subset: v2
      weight: 10

🧱 5. Shadow Deployment (тестирование в фоне)

Новая версия получает копию реального трафика, но ответы не видны пользователям.
Используется для тестирования производительности и регрессий.

Users → v1 (реальный ответ)
       ↳ v2 (анализ ответов)

Плюсы:

• Полностью без даунтайма
• Можно тестировать новую версию под боевой нагрузкой

Минусы:

• Требует сложной инфраструктуры для дублирования запросов
• Данные должны быть консистентны

⚖️ Сравнение стратегий

🧭 Итог

Выбор стратегии зависит от инфраструктуры, бюджета и требований к доступности:

• Recreate — для простых систем без SLA
• Rolling Update — стандарт для Kubernetes и Docker Swarm
• Blue-Green — для безопасных переключений
• Canary — для контролируемых экспериментов
• Shadow — для продвинутого тестирования без риска

📚 Полезные ссылки

• Kubernetes Deployment Strategies (kubernetes.io)
• Blue-Green and Canary Deployments (Red Hat)
• Istio Traffic Management