Как бы ты организовал деплой в продакшн?

«Как бы ты организовал деплой в продакшн?» — вопрос из категории CI/CD, который задают на 23% собеседований Devops Инженер. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

Я организую деплой через полностью автоматизированный GitOps-пайплайн с использованием ArgoCD для Kubernetes и стратегией постепенного развертывания.

Архитектура пайплайна:

  1. Сборка и тестирование (CI): При пуше в ветку main Jenkins/GitLab CI запускает сборку Docker-образа, прогоняет юнит- и интеграционные тесты, а затем пушит образ с тегом (например, git-sha) в Container Registry (Harbor).
  2. Проверка образа: Запускается сканирование уязвимостей образа (Trivy) и проверка политик (OPA).
  3. Синхронизация конфигурации (GitOps): ArgoCD постоянно мониторит Git-репозиторий с манифестами Kubernetes. Как только в манифесте обновляется тег образа (например, через PR или автоматически после успешного CI), ArgoCD начинает процесс деплоя.

Стратегия деплоя в production:

  • Canary-развертывание: Использую сервисную сеть (Istio) для управления трафиком. Сначала новый релиз (canary) получает 5% трафика.
    # Пример VirtualService для Istio (упрощенно)
    apiVersion: networking.istio.io/v1beta1
    kind: VirtualService
    spec:
    hosts:
    - myapp.prod.svc.cluster.local
    http:
    - route:
    - destination:
        host: myapp.prod.svc.cluster.local
        subset: stable
      weight: 95
    - destination:
        host: myapp.prod.svc.cluster.local
        subset: canary
      weight: 5
  • Анализ и продвижение: Мониторинг (Prometheus/Grafana) и система алертинга (Alertmanager) отслеживают ключевые метрики canary-пода: latency, error rate, throughput. Если в течение заданного времени (например, 15 минут) метрики в норме, я автоматически (или вручную) увеличиваю вес канарейки до 50%, затем до 100%.
  • Автоматический откат: Если error rate превышает порог, пайплайн автоматически возвращает 100% трафика на стабильную версию и создает инцидент для анализа.

Практики:

  • Все изменения инфраструктуры и конфигурации хранятся в Git (Infrastructure as Code с Terraform).
  • Для критичных обновлений требуется ручное подтверждение через PR или интерфейс ArgoCD.
  • Обязательно настроены pre- и post-deployment хуки для задач вроде миграций БД.