Многие компании реализуют GitOps-подход как часть внутренней Developer Platform. Он помогает унифицировать и автоматизировать доставку кода, повысить надёжность деплоя и дать разработчикам удобный интерфейс для работы с инфраструктурой. Один из самых популярных инструментов для этого — Argo CD.

Статья основана на воркшопе Егора Салиева и Николая Пушкарева, DevOps-инженеров Hilbert Team, проведённом на DevOps Conf 2025. В ней мы разберемся, как внедрить Argo CD и его ключевые компоненты, чтобы построить масштабируемую GitOps-платформу.

Материал будет в двух частях. Он будет полезен разработчикам и DevOps-инженерам, которые хотят понять, с чего начать внедрение GitOps в команде, организовать инфраструктуру под разные масштабы, а также всем, кто ищет способы унификации деплоя.

Авторы статьи: 

Егор Салиев

DevOps-инженер Hilbert Team

Николай Пушкарев

DevOps-инженер Hilbert Team

Hilbert Team — провайдер IT-решений для крупного и среднего бизнеса в области облачных технологий, DevOps, DevSecOps, DataOps, MLOps и FinOps. Партнёр Yandex Cloud со специали��ацией Yandex Cloud Professional по направлениям DevOps, Infrastructure и Data Platform.

Введение в GitOps

GitOps — это методология, в центре которой находится Git как источник истины для состояния ваших приложений. Специальный GitOps-контроллер следит за этим состоянием и синхронизирует его с реальным положением дел в вашем Kubernetes-кластере.

Принципы

Подход GitOps основан на pull-модели в отличие от push-ориентированных подходов. Представим: у вас есть Git-репозиторий, кластер Kubernetes, где работают приложения, и GitOps-контроллер, который всё это связывает. Контроллер регулярно опрашивает Git, проверяет наличие изменений — и если находит их, то применяет к кластеру, приводя фактическое состояние в соответствии с описанием из репозитория.

Это похоже на то, как разработчик завершает работу, пушит код — и в этот момент появляется мифический робот, который всё подхватывает. На этапе CD он берёт на себя всю грязную, рутинную часть — деплой, который вручную вряд ли захочется делать.

Инструменты

На рынке представлено немало инструментов, но наибольшую популярность получили Flux и Argo CD. Именно они чаще всего используются и внедряются в продакшене.

Если Flux — это надёжный друг-помощник, который может решать сложные задачи, то Argo CD — это компонент, как ассистент со степенью MBA. Он выглядит опрятно, автоматизирует процессы, на него можно положиться. Но если вы перенаделите его возможностями и неправильно настроите, он спокойно дезинтегрирует всю вашу инфраструктуру.

Мы не будем подробно сравнивать эти инструменты между собой и сосредоточимся на Argo CD.

Особенности Argo CD

  • Интуитивный интерфейс.

Это важно: благодаря удобному UI вы можете передать управление приложением не только DevOps-инженеру, но и самому разработчику. Даже без доступа в кластер он сможет, например, перезапустить приложение, посмотреть логи — и уже на основе этого попробовать разобраться, почему оно не запускается и починить всё самостоятельно.

  • Мультикластерность. Возможность управлять несколькими кластерами из одного интерфейса.

  • Поддержка RBAC-ролей.

  • Автоматическая синхронизация.

  • Откат изменений, в том числе и автоматический.

  • Поддержка плагинов и расширений. Благодаря им вы можете настроить Argo CD под свои конкретные нужды.

  • Поддержка общепринятых инструментов Helm и Kustomize.

  • Мониторинг и оповещения.

В современном мире observability — важная часть инфраструктуры. Argo CD отдаёт полезные метрики: состояния приложений, статусы синхронизаций и прочее. На их основе можно собирать собственные дашборды или использовать готовые из официального GitHub проекта.

  • Интеграция с приложениями экосистемы Argo Project.

Интеграция с приложениями экосистемы Argo Project — ещё одна киллер-фича Argo CD. В неё входят: 

  • Argo Workflows для организации сложных пайплайнов; 

  • Argo Rollouts для организации стратегии деплоя Progressive Delivery; 

  • Argo Events — для запуска триггеров по событиям и автоматизации реакций в Kubernetes.

План действий по шагам

Мы обсудили, что такое GitOps и с помощью каких инструментов он реализуется. Дальше пойдём по шагам — от установки Argo CD до интеграции с другими компонентами:

  1. Установим Argo CD с помощью helm-secrets.

  2. Разберём values, с которыми выполняется установка, и посмотрим, как можно организовать репозиторий.

  3. Предложим пример оформления в Terraform.

  4. Познакомимся с ресурсами Argo CD:

    • покажем деплой с помощью Application;

    • перейдём к ApplicationSet;

    • рассмотрим варианты деплоя, например, через GitLab CI/CD.

  5. Изучим настройку RBAC-ролей.

  6. Настроим SSO в связке Dex + Keycloak.

  7. Покажем способы доставки секретов на примере Bank-Vaults.

  8. Интегрируем всё это с Argo Rollouts.

Установка Argo CD

Прежде чем говорить о компонентах, установим приложение. Официальная документация предлагает делать это с помощью манифестов, и они там действительно есть. Но в современных реалиях устанавливать таким способом не очень удобно. Вместо этого лучше использовать Helm-чарт: он хорошо поддерживается комьюнити и довольно неплохо прокачан по возможностям.

Пока мы оперируем только теорией, давайте просто выполним три магические команды — не вдаваясь в подробности, как именно всё работает.

  • kubectl get pod -n argocd

  • kubectl get crd

  • grep argoproj.io

На выходе получим список компонентов Argo CD.

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

Компоненты ​​Argo CD

Server — предоставляет gRPC/REST API и отвечает за обработку запросов, а также содержит Web UI.

Это — мозг Argo CD. Через него происходит взаимодействие с системой: можно использовать API, просматривать Swagger-документацию, видеть, какие методы поддерживаются и что можно обновить или запушить. Вместе с сервером на этом же компоненте располагается веб-интерфейс.

Repository Server — отвечает за извлечение манифестов из Git и их подготовку для дальнейшей обработки.

Это курьер. Он извлекает манифесты из репозиториев, дешифрует их, если были закодированы, применяет плагины работы с числительными данными.

Application Controller — синхронизирует состояние приложений с желаемым состоянием, описанным в Git.

По сути, это надзиратель над приложениями. Он отвечает за обработку ресурсов Application и следит, чтобы то, что задекларировано в Git, соответствовало реальному состоянию в кластере.

ApplicationSet Controller — шаблонизатор для ресурсов ApplicationSet.

Занимается тем же, что и Application Controller, но работает с ApplicationSet. Это маг шаблонизации.

Notification Controller — отвечает за сбор и отправку уведомлений.

Они могут уходить в разные направления: Telegram, Slack, email. Также есть поддержка интеграции с Alertmanager, если у вас уже используется промстек.

Dex — компонент для интеграции с внешними системами аутентификации.

Dex выступает как OIDC-провайдер. Argo CD может работать с OIDC (например, с Keycloak) напрямую, но Dex упрощает взаимодействие, например, с Active Directory или аналогичными ID-провайдерами.

Когда смотришь на это многообразие компонентов, легко почувствовать себя маскотом ArgoProject — осьминожкой, у которой в каждой щупальце своя задача.

Ресурсы Argo CD

Ресурсы Argo CD — это Custom Resource Definition (CRD). На самом деле их всего три:

  • AppProject — позволяет настроить логическое разделение приложений. В этом ресурсе можно задать политики: какие приложения можно запускать, в какие кластеры можно деплоиться, а в какие — нет.

  • Application — базовый ресурс в Argo CD. Он описывает, откуда, как и куда будет развёрнуто приложение.

  • ApplicationSet — мощный механизм шаблонизации. С его помощью можно создавать множество Application-ресурсов.

Все эти детали мы разберём чуть позже. А сейчас из теоретического поля переходим в реальность, где нужно подумать о безопасности, хранении чувствительных данных и работе с секретами.

Практика: установка Argo CD с helm-secrets

Первым делом покажем на примере, как задеплоить Argo CD в кластер с использованием helm-secrets плагина.

Инструкция по установке

Для этого нам понадобятся инструменты:

  • helm — с помощью которого будем устанавливать Argo CD,

  • sops — для работы с зашифрованными значениями,

  • age — для генерации ключей шифрования с помощью команды age-keygen,

  • плагин helm-secrets, который подключается к Helm и позволяет работать с секретами во время установки.

После установки инструментов выполняем следующее:

  1. Генерируем ключ с помощью age-keygen.

  2. Кладём его в Kubernetes-секрет в argocd namespace.

  3. Готовим файл с секретами, который впоследствии зашифруем через sops.

Сейчас он зашифрован, но для начала его нужно заполнить:

Мы видим, что это не Kubernetes Secret, а зашифрованная часть values, используемая при установке Argo CD. Внутри — конфиг подключения репозиториев: 

  • токен доступа к GitLab,

  • имя токена,

  • имя репозитория, который будет подключён,

  • тип репозитория (Git или Helm),

  • URL.

  1. После того как заполнили конфигурацию, шифруем файл с помощью helm-secrets.

  2. После этого создаём namespace для Argo CD.

  3. Создаём будущий секрет с репозиториями.

  4. Шифруем секретный файл.

  5. Устанавливаем Argo CD в namespace argocd с помощью плагина helm-secrets:

helm secrets -n argocd install argocd ./bootstrap/base/ -f ./bootstrap/base/values.yaml -f ./bootstrap/base/secrets.yaml

Помимо самой Argo CD, также устанавливаем ApplicationSet и AppProject.

Уточню, что во всех проектах мы используем так называемые зонтичные чарты (Umbrella Chart), поэтому в начале values пишем название родительского чарта и через табуляцию — остальное.

Argo CD развёрнута. Теперь разберёмся, с какими values она была установлена.

Values Argo CD лежат в нашем репозитории в папке bootstrap/base:

Что здесь интересного:

  • Имя родительского чарта — global.domain. Эта настройка важна. Без неё при настройке интеграции с Keycloak можно поймать ошибку 403, потому что Argo CD не сможет корректно обработать редирект.

  • Настройка insecure (включена для тестов).

  • Настройки ingress, конфигурации, схема подключения репозиториев.

По умолчанию указан публичный репозиторий Argo CD, из которого можно обновлять саму Argo CD собственными средствами. Мы так делать не рекомендуем, но возможность есть.

Дальше — настройка конфига репозиторий-сервера. Тут появляется набор неслучайный переменных:

Все они взяты из документации к плагинам, которые мы собираемся использовать. Эмпирическим путём выяснили: без них ничего работать не будет, поэтому лучше сразу брать из документации.

Плагины устанавливаются в init-контейнере и подгружаются на volume. Init-контейнер загружает плагины нужных версий:

Проверим, Argo CD развернулась:

Когда вы заходите в интерфейс, обычно,  там ещё ничего нет. В нашем случае приложения уже подключены, потому что мы заранее добавили GitOps-репозитории, где лежат все проекты.

В группе репозиториев GitOps есть подгруппа с конкретным кластером. Внутри — четыре проекта, каждый отвечает за свою часть инфраструктуры:

На всякий случай покажу, как это выглядит в GitLab:

Мы подключили четыре репозитория, чтобы было проще управлять доступом разработчиков и логически разделять проекты. Например, все инфраструктурные проекты в этом примере развёрнуты в отдельном namespace, отдельном проекте и репозитории. Так удобнее.

Из минусов подхода: чтобы подключить все репозитории, для каждого нужно вручную создать токен и подключить его в файле с настройками, указав имя и URL:

Для четырёх проектов это занимает около пяти минут, но если у вас 10, 20 или больше — процесс становится уязвимым к ошибкам.

Есть два способа это автоматизировать:

  • либо так:

  • либо использовать Terraform

Практика: установка Argo CD с помощью Terraform

Когда у вас много репозиториев, становится тяжело управлять всем вручную. Монорепы — это плохо: они ограничивают нас в настройках доступа. А вот «мультирепы» — это хорошо, потому что позволяют организовать доступы более гранулировано.

Тут на помощь приходит Terraform — а если точнее, Terragrunt и провайдеры, с помощью которых можно это описать. У Argo CD есть свой собственный Terraform Provider. 

Может показаться, что стоит описать всё один раз, нажать кнопку — и можно переиспользовать. Но на практике есть нюансы.

Argo CD Terraform Provider

Когда вы используете Argo CD Terraform Provider, каждый ресурс Argo CD нужно описывать в синтаксисе HCL, то есть в ресурсах Terraform. Это выглядит примерно так:  слева — Terraform-файл, то есть ресурс ApplicationSet, справа — YAML:

На наш взгляд, очевидно: YAML выглядит понятнее по сравнению с HCL. Он компактнее и визуально более читаем. Поэтому в своих проектах мы отказались от Argo CD Terraform Provider и перешли на Helm Terraform Provider.

Helm Terraform Provider позволяет:

  • выкатывать helm-чарты с уже подготовленными values, 

  • добавлять туда нужное количество шаблонов, 

  • сразу темплейтировать те же GitLab токены в ресурсы для репо-сервера Argo CD.

GitLab Terraform Provider позволяет:

  • описать сразу необходимое количество репозиториев,

  • сгенерировать нужное число токенов,

  • передать всё это в Helm. 

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

Итоги

В этой части статьи мы разобрались, что такое GitOps, почему он удобен, в чём особенность Argo CD и как его установить с учётом хранения секретов. Поняли, как устроены ключевые компоненты, и познакомились с тем, какие ресурсы ждут нас дальше: Application, ApplicationSet и AppProject.

В итоге у нас есть развёрнутый Argo CD, подключённые репозитории, схема с helm-secrets и понимание, как автоматизировать с помощью Terraform. Дальше можно развивать деплой — от простого бэкенда до более высоких уровней сложности.

Мы подготовили GitHub-репозиторий с материалами воркшопа. Внутри:

  • argo-cd –– установка и настройка Argo CD

  • backend-app –– тестовое приложение backend-app

  • gitops –– gitops-репозиторий(inventory) для установки приложений Argo CD

  • helm-charts –– репозиторий с helm-чартами

Можно повторить настройку Argo CD у себя, а также изучить примеры из статьи.

Во второй части посмотрим, как это применять в реальных сценариях в зависимости от масштаба команды или компании.

А пока подписывайтесь на телеграм-канал Hilbert Team. Тут много интересного!

Скрытый текст

А чтобы узнать больше по теме, приходите на DevOps Conf 2026 — здесь сконцентрированы энергия и бесценный опыт лучших инженеров, CTO, CIO, техлидов и тимлидов. Вас ждет расширение профессионального кругозора, обсуждение практических вопросов, отработка навыков на мастер-классах и много-много нетворкинга.