16.06, ООО «ВК»
16.06, ООО «ВК»
16.06, ООО «ВК»

Разбираем ArgoCD: автоматизированный деплой в Kubernetes

Аватарка пользователя Вадим Егорцев
для
Логотип компании Tproger
Tproger
Отредактировано

Argo CD превращает развертывание приложений в Kubernetes в почти приятное занятие, где вам остается только писать код и делать коммиты. Что это за инструмент и как он работает? Читайте в материале.

599 открытий3К показов
Разбираем ArgoCD: автоматизированный деплой в Kubernetes
Используете ArgoCD?
Да, очень сокращает время
Нет, но хочу разобраться
В первый раз слышу

Представьте ситуацию: вы внесли изменения в код, отправили их в Git. А дальше?

Загибайте пальцы:

  1. Собрать Docker-образ.
  2. Обновить конфигурацию в Kubernetes.
  3. Применить изменения командами kubectl.
  4. Проверить, что все работает.
  5. Если не работает — откатить изменения, исправить, повторить.

И так каждый раз. А если на проекте не только тестовая среда, но и предпродакш, продакшн? А если команда из 10 разработчиков? Кошмар!

Инструмент Argo CD ускоряет развертывание приложений, синхронизирует Git-репозиторий с фактическим состоянием в кластере. В итоге у разработчика больше времени на написание кода и меньше проблем с деплоем. Компания тоже выигрывает — получает более быстрые и надежные релизы.

После прочтения статьи вы сможете самостоятельно настроить деплой Kubernetes с помощью ArgoCD и применить эти знания в собственных проектах.

Введение в ArgoCD: возможности и преимущества

Git коммитишь — кластер обновляется

Вася написал новую фичу и отправил ее в Git. Через 2 минуты функция уже работает в тестовой среде, но с багом. Вася исправляет код, делает коммит, — и через 2 минуты исправление снова в тестовой среде.

Когда все готово к релизу, девопс применяет изменения в ветке, и ArgoCD автоматически обновляет продакшн.

Без ArgoCD: 30+ минут ручной работы на каждый деплой, высокая вероятность ошибки.

С ArgoCD: 2 минуты автоматической работы, минимальный риск ошибок.

Изменили код, отправили в Git — работа сделана. Платформа GitOps без вашего участия обнаружит изменения и обновит приложение в кластере.

Интерактивная панель управления

В Argo CD видно все компоненты приложения — деплойменты, сервисы, конфигмапы — и их состояние. В один клик можно посмотреть историю синхронизаций, детали развертывания и логи.

Разбираем ArgoCD: автоматизированный деплой в Kubernetes 1

ArgoCD — это быстрый доступ к событиям, управление средами и кластерами с одной панели, мгновенный откат к предыдущей версии. Также доступна проверка изменений перед их применением.

Универсальный подход к конфигурациям

Команда применяет Helm для управления зависимостями?

— ArgoCD интегрируется с ним напрямую.

Предпочитаете Kustomize для настройки под разные среды?

— ArgoCD распознает эти конфигурации автоматически.

Используете стандартные YAML-манифесты?

— Они тоже поддерживаются без дополнительной настройки.

Безопасный доступ для команды любого размера

Можно разделить доступ между участниками проекта с точностью до отдельных приложений и действий:

  • Девопсы управляют всеми развертываниями.
  • Разработчики получают права на просмотр логов и статуса своих сервисов.
  • Тестировщики видят статус только тестовых сред.

Права разграничиваются по проектам, именам и типам ресурсов. Например, команда фронтенда видит только свои сервисы, бэкенд-разработчики — только свои.

Система интегрируется с корпоративными провайдерами аутентификации через OIDC, LDAP, SAML. Каждый сотрудник сможет использовать персональные учетные данные для входа.

Установка и настройка Argo CD

ArgoCD устанавливается в действующий кластер Kubernetes с помощью стандартного набора манифестов. Перед установкой потребуются: настроенный kubectl, файл kubeconfig и работающий CoreDNS.

			kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
		

Команды создают пространство имен argocd и устанавливают компоненты: серверы приложений, репозиториев и другие службы.

Доступ к ArgoCD осуществляется через CLI и веб-интерфейс.

CLI устанавливается из официальных релизов:

По умолчанию сервер ArgoCD не имеет внешнего IP. Это значит, что веб-интерфейс и API ArgoCD доступны только из кластера Kubernetes.

Есть три способа настройки доступа:

1. Изменение типа сервиса на LoadBalancer:

			kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'
		

2. Настройка Ingress-ресурс для маршрутизации трафика через входной контроллер кластера.

3. Использование kubectl port-forward для временного доступа:

			kubectl port-forward svc/argocd-server -n argocd 8080:443
		

Начальный пароль администратора генерируется автоматически и хранится в секрете argocd-initial-admin-secret:

			argocd login 
		

Вход в систему через CLI:

			argocd login 
		

После первого входа необходимо сменить пароль:

			argocd account update-password
		

Секрет argocd-initial-admin-secret следует удалить после смены пароля, так как он содержит пароль в открытом виде:

			kubectl delete secret argocd-initial-admin-secret -n argocd
		

Для веб-интерфейса используется тот же адрес и учетные данные, что и для CLI.

Разбираем ArgoCD: автоматизированный деплой в Kubernetes 2

Регистрация кластера (необходима только для внешних кластеров):

			kubectl config get-contexts -o name
argocd cluster add 
		

При добавлении внешнего кластера ArgoCD создает сервисный аккаунт argocd-manager в пространстве имен kube-system и выдает ему права администратора. При работе с тем же кластером, где установлен Argo CD, используется адрес https://kubernetes.default.svc.

Создание приложения:

			kubectl config set-context --current --namespace=argocd
argocd app create  \
  --repo  \
  --path  \
  --dest-server https://kubernetes.default.svc \
  --dest-namespace 
		
Разбираем ArgoCD: автоматизированный деплой в Kubernetes 3

То же самое через веб-интерфейс:

  1. Нажать кнопку «New App».
  2. Заполнить форму с указанием имени, Git-репозитория, пути к манифестам.
  3. Выбрать целевой кластер и пространство имен.
  4. Нажать «Create».

После создания приложение находится в состоянии «OutOfSync». Для развертывания ресурсов в кластер:

Через CLI:

			argocd app sync 
		
Разбираем ArgoCD: автоматизированный деплой в Kubernetes 4

Через веб-интерфейс:

  1. Нажать «Sync» для нужного приложения.
  2. В открывшейся панели выбрать «Synchronize».

Для автоматической синхронизации при изменениях в Git-репозитории используется флаг –sync-policy automatic:

			argocd app set  --sync-policy automatic
		

При загрузке манифестов из репозитория Арго автоматически определяет формат и применяет соответствующий инструмент для развертывания.

Основные команды и работа с CLI

Рассмотрим 4 базовые команды:

  • Добавление нового приложения.
  • Проверка состояния развертывания.
  • Автоматическая и ручная синхронизация.
  • Откат изменений.

Добавление нового приложения

Команда argocd app create создает приложение в Argo CD, связывая Git-репозиторий с целевым кластером Kubernetes.

Нужно указать имя приложения, источник манифестов и целевую среду:

			argocd app create your_app \
  --repo https://github.com/example/app.git \
  --path manifests \
  --dest-server https://kubernetes.default.svc \
  --dest-namespace production
		

Альтернативой ручному созданию приложения служит определение через YAML-файл:

			argocd app create -f application.yaml
		

Проверка состояния развертывания

Команда argocd app get отображает текущее состояние приложения, включая статус синхронизации, ревизию Git и состояние ресурсов:

			argocd app get your_app
		

Для вывода информации о ресурсах приложения используется флаг -o wide:

			argocd app get your_app -o wide
		

Можно отслеживать состояние ресурсов во время синхронизации:

			argocd app get your_app --refresh
		

Еще ArgoCD сохраняет историю синхронизаций приложения:

			argocd app history your_app
		

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

Команда argocd app sync применяет изменения, обнаруженные в Git-репозитории, к кластеру Kubernetes:

			argocd app sync your_app
		

При ручной синхронизации Argo CD:

  1. Скачивает манифесты из Git.
  2. Формирует план изменений.
  3. Применяет его к кластеру.
  4. Отслеживает состояние до завершения развертывания.

Синхронизация определенной ревизии Git:

			argocd app sync your_app --revision 53f843d
		

Принудительная синхронизация:

			argocd app sync your_app --force
		

Обновление только определенных ресурсов:

			argocd app sync your_app --resource Deployment:apps/backend --resource ConfigMap:configmap
		

Откат изменений

Команда argocd app rollback отменяет последнюю синхронизацию и возвращает приложение к предыдущему стабильному состоянию:

			argocd app rollback your_app
		

По умолчанию откат выполняется на предыдущую успешную ревизию. Для отката к конкретной ревизии требуется указать ее ID:

			argocd app history your_app
argocd app rollback your_app 5
		

где 5 — номер ревизии из истории.

При откате не происходит изменений в Git-репозитории — это временное изменение, направленное на быстрое восстановление работоспособности.

После отката приложение перейдет в состояние «OutOfSync», поскольку Git-репозиторий по-прежнему содержит новую версию.

Для долгосрочного решения после отката нужно:

  1. Исправить ошибки в манифестах.
  2. Отправить исправления в Git.
  3. Синхронизировать приложение.

Работа с ArgoCD в реальных проектах

ArgoCD дополняет классические CI/CD-системы, разделяя ответственность за процесс доставки. CI-системы отвечают за сборку кода и создание артефактов, ArgoCD берет на себя развертывание в Kubernetes.

В GitHub Actions пайплайн компилирует приложение, собирает Docker-образ, обновляет манифест с новым тегом образа и отправляет изменения в Git. ArgoCD замечает изменения в репозитории и обновляет приложение в кластере.

Подробнее про интеграцию CI/CD с GitHub Actions

GitLab CI/CD использует подобную схему — сначала тестирование и сборка, затем запись актуальных версий в манифесты. CI-пайплайн завершается, как только изменения попадают в Git. Остальную работу делает ArgoCD.

Подробнее про инструменты CI/CD на практике от DevOps-инженеров

Jenkins требует дополнительной настройки для интеграции с ArgoCD. Возможна работа через REST API ArgoCD или через обновление манифестов в Git-репозитории. Для командной строки Argo CD создают отдельные сервисные аккаунты с ограниченными правами.

Настройка уведомлений

Уведомления Argo CD информируют команду о состоянии приложений. Система уведомлений настраивается в ConfigMap argocd-notifications-cm:

  • Для Slack нужно определять шаблоны сообщений и триггеры событий. Соединение настраивается через токен бота. Приложения активируют уведомления через аннотации.
  • Microsoft Teams работает через веб-хуки. Каждый канал получает собственный URL-адрес, который ArgoCD использует для отправки сообщений.
  • Email-оповещения требуют настройки SMTP-сервера. ArgoCD поддерживает TLS-шифрование и аутентификацию. Письма содержат детальную информацию о событиях и могут включать ссылки для быстрого доступа.

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

Управление секретами

Стандартная модель GitOps требует хранения всех манифестов в Git, что небезопасно.

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

  • Sealed Secrets. Публичный ключ используется для шифрования секретов перед сохранением в Git. Контроллер в кластере расшифровывает их закрытым ключом и создает стандартные Secret-объекты.
  • HashiCorp Vault. Манифесты содержат переменные, которые заполняются значениями из Vault в момент синхронизации. Секреты никогда не попадают в Git-репозиторий.

3 лучшие практики использования ArgoCD

1. Организация репозитория

Структура Git-репозитория влияет на эффективность работы с Argo CD. Рассмотрим два основных подхода: «моно» и «мульти» модель.

  • Монорепозиторий хранит все манифесты в одном месте. Каталоги первого уровня разделяют приложения и конфигурацию среды. Преимущество — целостная структура и возможность внесения согласованных изменений.
  • Мультирепозиторная модель разделяет компоненты по нескольким репозиториям. Каждая команда управляет своим набором приложений. Конфигурации для разных окружений хранятся отдельно. Этот подход четко разграничивает ответственность.

App of Apps упрощает управление множеством приложений через главное приложение ArgoCD. Один манифест верхнего уровня содержит определения для всех приложений, что упрощает развертывание однотипной инфраструктуры.

2. Использование Kustomize и Helm

Kustomize накладывает патчи на базовые манифесты. Конфигурация определяет основные параметры приложения, оверлеи содержат изменения для конкретных сред.

Helm применяет шаблонизацию для создания манифестов. Чарты содержат шаблоны с переменными, значения которых задаются в файлах values.yaml. Для каждого окружения создается собственный файл значений.

Можно комбинировать оба инструмента. Helm создает базовые манифесты, а Kustomize настраивает их под конкретные требования.

3. Мониторинг приложений и настройка alert-уведомлений

Арго собирает метрики синхронизации, состояния здоровья, времени развертывания. Данные передаются в Prometheus для создания дашбордов в Grafana и настройки алертов.

Разбираем ArgoCD: автоматизированный деплой в Kubernetes 5
Интерфейс Grafana 

Система уведомлений информирует команды о критичных изменениях: ошибках синхронизации, деградации здоровья, успешных развертываниях. Алерты отправляются в Slack, Teams, Email через настраиваемые триггеры и шаблоны.

6 популярных ошибок при работе с ArgoCD

Ошибка аутентификации по SSH-ключу. ArgoCD выдает «Permission denied (publickey)» при попытке доступа к репозиторию. Причина — неправильно настроенный или отсутствующий SSH-ключ.

Решение:

  • Проверить корректность SSH-ключа.
  • Убедиться, что в репозитории ключ добавлен как deploy key с правами чтения.
  • Проверить формат ключа (должен начинаться с —–BEGIN OPENSSH PRIVATE KEY—–).

Отсутствие прав доступа к репозиторию. Даже при корректных учетных данных пользователь может не иметь прав чтения.

Решение:

  • Проверить права доступа пользователя или deploy key к репозиторию.
  • Убедиться, что для организации не включено SSO или 2-FA.

Несоответствие версий Helm. Argo CD использует встроенную версию Helm, которая может отличаться от локальной.

Решение:

  • Проверить версию Helm в Argo CD через argocd admin helm version.
  • Настроить кастомную версию Helm через конфигурацию argocd-cm.

Отсутствующие значения в values.yaml. Ошибка «Error: execution error at line X» с указанием на неопределенное значение.

Решение:

  • Убедиться, что все required значения указаны в файле values или через флаги –set
  • Использовать условные блоки для необязательных параметров

Одна из основных проблем в GitOps-модели — расхождение между фактическим состоянием кластера и описанием в Git.

Отказ при синхронизации из-за drifts. ArgoCD отображает ресурс как «OutOfSync» и отказывается выполнять синхронизацию.

Решение:

  • Использовать флаг –force при синхронизации для перезаписи изменений.
  • Включить опцию автоматического самовосстановления (self-heal) для критичных ресурсов

Ошибка Update не разрешена для некоторых полей. Kubernetes запрещает изменение определенных полей после создания ресурса.

Решение:

  • Добавить аннотацию argocd.argoproj.io/sync-options: Replace=true

Подведем итоги

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

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

Если после внедрения ArgoCD у вас внезапно появилось свободное время — не пугайтесь, это нормально. Используйте его, чтобы наконец-то прочитать те 348 вкладок про Kubernetes, которые вы открыли 2 года назад. А еще можете использовать его, чтобы почитать наш тг-канал, найдете больше советов!

Следите за новыми постами
Следите за новыми постами по любимым темам
599 открытий3К показов