Опишите процесс деплоя на вашем последнем проекте.

«Опишите процесс деплоя на вашем последнем проекте.» — вопрос из категории Архитектура и DevOps-практики, который задают на 23% собеседований Devops Инженер. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

На последнем проекте (микросервисная архитектура на Kubernetes) был реализован GitOps-подход с использованием ArgoCD и GitHub Actions.

Процесс выглядел так:

  1. Разработка: Все изменения шли через Pull Request в ветку develop. При создании PR автоматически запускался пайплайн, который:
    • Собирал Docker-образ с тегом, соответствующим хешу коммита.
    • Запускал unit- и интеграционные тесты.
    • Запускал статический анализ кода (SonarQube) и безопасности (Trivy).
  2. Сборка и тестирование образа (GitHub Actions):
    jobs:
    build-and-push:
    runs-on: ubuntu-latest
    steps:
      - name: Build and push Docker image
        uses: docker/build-push-action@v4
        with:
          push: true
          tags: |
            ${{ secrets.REGISTRY }}/app:${{ github.sha }}
            ${{ secrets.REGISTRY }}/app:latest
  3. Деплой в staging: После мержа PR в develop ArgoCD автоматически синхронизировал состояние кластера с манифестами в Git-репозитории (использовался Helm-чарт). ArgoCD сравнивал желаемое состояние (описанное в Git) с фактическим в кластере и применяла изменения.
  4. Деплой в production: Создавался Pull Request из develop в main. После его одобрения и мержа:
    • Собирался production-образ с соответствующим тегом версии.
    • В Git-репозитории с манифестами обновлялась версия образа в Helm-чарте для production-окружения.
    • ArgoCD в production-кластере обнаруживала расхождение и начинала rollout с использованием стратегии Blue-Green (реализованной через сервис Istio). Трафик переключался на новую версию только после успешных health-check.

Инструменты и практики:

  • Infrastructure as Code: Terraform для облачных ресурсов (VPC, кластер EKS).
  • Конфигурация как код: Kustomize и Helm для управления манифестами Kubernetes.
  • Наблюдаемость: Для мониторинга деплоя использовались метрики ArgoCD, алерты в Prometheus/Grafana и логи в ELK-стеке.
  • Откат (Rollback): В случае проблем откат был тривиален — нужно было revert коммита в Git-репозитории с манифестами, и ArgoCD возвращала предыдущую стабильную версию.