Argo CD 2.4 и GitLab CE: референсная архитектура GitOps для on-premise

Argo CD 2.4 дошёл до второго релиз-кандидата в середине мая, и релиз получился содержательный: доработки ApplicationSet, server-side apply как опция, улучшения в управлении несколькими кластерами. Но самое интересное сейчас не в changelog, а в том, что несколько клиентов за последние два месяца задали примерно одинаковый вопрос: «Мы хотим уйти с GitHub Actions / Azure DevOps. Что поставить on-premise?»

Раньше такие разговоры касались инфраструктуры - гипервизоры, базы данных, операционные системы. Теперь добрались до CI/CD. Логично: GitHub - американская компания под санкционным риском, Azure DevOps - тоже. Для части клиентов это уже не теоретический аргумент, а практический.

Почему GitLab CE + Argo CD

GitLab CE (Community Edition) - очевидный кандидат для on-premise GitOps. Self-managed, open source, без лицензионной зависимости от западного вендора. У нескольких клиентов он уже стоит после апрельских событий вокруг GitHub Actions - мы помогали с обновлением до 14.10.

Argo CD как отдельный инструмент CD - тоже выбор не случайный. Он работает в парадигме pull: агент внутри кластера сам забирает изменения из git-репозитория и синхронизирует состояние. Это принципиально для on-premise: не надо открывать внешний доступ до кластера, не надо давать CI-системе права на деплой. GitLab знает только о репозитории, Argo CD знает о кластере - разделение ответственности чёткое.

Связка не идеальна и требует настройки, но она собирается из компонентов, каждый из которых понятен и заменяем.

Референсная архитектура

Схема, которую мы сейчас тестируем и будем раскатывать у первого клиента:

GitLab CE (self-managed)
  └─ репозитории приложений (app code + Dockerfile)
  └─ репозиторий конфигураций (Helm charts / kustomize manifests)
  └─ GitLab CI: build → test → push image → update config repo

Argo CD 2.4 (в кластере)
  └─ Application / ApplicationSet -> config repo
  └─ синхронизация с кластером (или несколькими)
  └─ уведомления → GitLab (commit status) или внутренний мессенджер

Два репозитория - принципиальный момент. Код приложения и манифесты деплоя живут отдельно. GitLab CI собирает образ, пушит его в GitLab Container Registry и обновляет тег в config-репозитории через коммит (или MR, если нужна проверка). Argo CD видит изменение в config-репозитории и синхронизирует кластер. CI-система не имеет прямого доступа к кластеру - только к registry и к config-репо.

Что нового даёт Argo CD 2.4

ApplicationSet стал заметно удобнее. ApplicationSet - это генератор Application-ресурсов: описываешь шаблон, задаёшь параметры (список кластеров, список неймспейсов, список сервисов) - и получаешь набор Application без дублирования YAML. В 2.4 появился Pull Request Generator: ApplicationSet может создавать временные деплои для каждого открытого pull request в GitHub, Gitea или Bitbucket Server. Это review environments из коробки - нас спрашивали про это несколько раз.

Server-side apply как опция деплоя. Вместо стандартного kubectl apply (client-side) Argo CD теперь умеет использовать server-side apply, где validation и merge-логика живут на стороне API-сервера Kubernetes. Это решает ряд конфликтов с field ownership при работе с операторами - в частности, с cert-manager и некоторыми custom controllers, которые тоже управляют частью манифеста.

Multi-cluster management. В 2.4 улучшили UI и API для управления несколькими целевыми кластерами из одного Argo CD. Для клиентов с dev/staging/prod в разных кластерах это уже не пунктир в доке, а рабочая история.

Где реальные сложности

Не стоит продавать эту связку как «просто поставил и работает» - не так.

Первое - аутентификация GitLab -> Argo CD. Argo CD умеет использовать GitLab как OIDC-провайдер для входа пользователей. Настройка сама по себе несложная, но если GitLab self-managed стоит за корпоративным прокси или с самоподписанным сертификатом - начинаются нюансы с TLS-верификацией, которые надо аккуратно проходить.

Второе - secrets management. Манифесты в git-репозитории не должны содержать секреты в открытом виде. Argo CD сам не решает эту проблему - нужен отдельный инструмент. Мы используем связку с Vault (HashiCorp Vault через argocd-vault-plugin) или с Kubernetes Secrets + External Secrets Operator. Для клиентов, которые только начинают и Vault нет, это порой неожиданное препятствие.

Третье - GitLab CI для сборки, не для деплоя. Переход к GitOps означает, что GitLab CI-пайплайн заканчивается пушем образа и коммитом в config-репо. Привычный stage deploy с kubectl apply или helm upgrade исчезает. Командам с укоренившимся пайплайном это надо объяснять отдельно - не все сразу понимают зачем усложнять.

ApplicationSet и review environments

Конкретный пример того, как мы настраиваем preview для PR:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: review-apps
  namespace: argocd
spec:
  generators:
  - pullRequest:
      github:
        owner: "my-group"
        repo: "my-app"
        tokenRef:
          secretName: github-token
          key: token
        labels:
        - "review"
      requeueAfterSeconds: 60
  template:
    metadata:
      name: 'review-{{branch_slug}}'
    spec:
      project: review
      source:
        repoURL: https://gitlab.internal/my-group/my-app-config.git
        targetRevision: main
        path: helm/app
        helm:
          parameters:
          - name: image.tag
            value: "{{head_sha}}"
          - name: ingress.host
            value: "{{branch_slug}}.review.internal"
      destination:
        server: https://kubernetes.default.svc
        namespace: 'review-{{branch_slug}}'
      syncPolicy:
        automated:
          prune: true
        syncOptions:
        - CreateNamespace=true

Лейбл review на PR - и Argo CD автоматически создаёт namespace и деплоит версию с тегом из HEAD коммита. PR закрыт - Application и namespace удаляются через prune. Это работает, хотя потребовало отдельной настройки прав и квот в кластере.

Где сейчас

У одного клиента архитектура уже в staging - параллельно с существующим Azure DevOps пайплайном. Цель: к концу квартала перевести три сервиса на новый стек и отключить зависимость от Azure. Не торопимся - миграция CI/CD без инцидентов требует параллельного прогона, а не переключения в один день.

У двух других - на стадии обсуждения архитектуры. Один из них хочет сохранить GitLab CI только для сборки и всё равно использовать Argo CD для деплоя - это нас устраивает, это и есть правильная модель. Второй хочет всё через GitLab, включая деплой через GitLab Agent for Kubernetes - это тоже рабочий вариант, но другой и с другими компромиссами.

Импортозамещение CI/CD - не самая быстрая история. Но managed-сопровождение здесь помогает именно тем, что не надо собирать всё это с нуля: у нас уже есть шаблоны, есть набитые шишки по TLS и secrets, есть понимание где обычно застревают. Референсная архитектура - это не документ, это работающая конфигурация, которую мы сами гоняем.