Как реализовать надежный деплой в production с помощью Argo CD?

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

Ответ

Argo CD реализует GitOps, где желаемое состояние инфраструктуры (Kubernetes-манифесты) описывается в Git-репозитории. Наш production-деплой построен на следующих принципах:

1. Структура репозитория и автоматизация: Мы используем подход "приложения как код" с отдельными директориями для каждого окружения (например, k8s/overlays/prod). Argo CD настроен на автоматическую синхронизацию (auto-sync) с включенными функциями самовосстановления (selfHeal) и удаления устаревших ресурсов (prune). Это гарантирует, что кластер всегда соответствует коммиту в ветке main.

# Пример Application манифеста для Argo CD
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: backend-service-prod
  namespace: argocd
spec:
  project: default
  source:
    repoURL: 'git@github.com:my-org/infrastructure.git'
    targetRevision: main
    path: k8s/overlays/prod/backend
    # Используем Kustomize для наложения патчей окружения
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: production
  syncPolicy:
    automated:
      prune: true    # Удалять ресурсы, удаленные из Git
      selfHeal: true # Автоматически исправлять дрейф состояния
    syncOptions:
    - CreateNamespace=true # Создавать namespace, если его нет

2. Контроль качества и проверки:

  • Health Checks: Argo CD использует встроенные health-статусы Kubernetes (например, Deployment считается Healthy, когда все Pod'ы готовы). Мы расширили это кастомными health-проверками для наших CRD.
  • Pre-Sync Hooks: Для критичных операций (миграции БД) мы используем хуки PreSync (задачи типа Job), которые должны успешно завершиться до применения основного деплоя.
  • Интеграция с CI: Слияние в main разрешено только после успешного прохода всех CI-пайплайнов (линтеры, тесты, сборка образов). Argo CD подхватывает уже готовые и протестированные манифесты.

3. Стратегии деплоя и откат: Для сервисов с высокой нагрузкой мы используем Argo Rollouts для реализации стратегий Canary или Blue-Green. Это позволяет постепенно наращивать трафик на новую версию и автоматически откатываться при срабатывании метрик (например, рост 5xx ошибок в Prometheus). В случае проблем с обычным деплоем откат выполняется через git revert и последующую автоматическую синхронизацию Argo CD.

4. Наблюдаемость: Все события синхронизации и состояния приложений дублируются через Argo CD Notifications в Slack-канал команды, что позволяет мгновенно реагировать на сбои.