Платформа GitOps на базе компакт-диска Argo

Привет, меня зовут Сергей, я руководитель направления DevOps в Лонто.

Периодически сотрудничаем с интересными ребятами и вместе устраиваем мероприятия. Примерами таких мероприятий являются встречи предпринимателей, онлайн-вечеринки и дни управления продуктом. Эта серия из трех статей представляет собой текстовую версию выступлений с мероприятия CTO Day. В докладе два спикера:

Сергей Маленко, руководитель направления DevOps в Lonto
Сергей Бондарев, архитектор Southbridge

Доклад был посвящен истории развертывания приложений, основным используемым моделям и их сравнению. Подробно обсуждаем модель вытягивания и показываем, как использовать «продвинутые» инструменты для управления инфраструктурой крупных проектов и позволять разработчикам самостоятельно заказывать элементы в инфраструктуре под нужды своих приложений.

Всего по отчету мы подготовили три статьи. Они будут следовать такому порядку:

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

Что такое ArgoCD и зачем он нужен, с примерами использования ←вы здесь 🚩
Поговорим об относительно новом витке в методах развертывания приложений и посмотрим, какие вопросы можно решить с помощью этого инструмента.

Как управлять инфраструктурой в GitOps с помощью Crossplane
Новый подход к IaC и его сочетание с Argo CD

GitOps — одна из реализаций модели вытягивания, в которой Git является хранилищем всех конфигураций. Git — это источник правды, это единственная точка, через которую вносятся изменения в инфраструктуру. Все изменения pull-модели вносятся специальным агентом, который затем поддерживает установленное состояние. То есть, если вы вносите изменения в инфраструктуру вручную, агент заметит несоответствие тому, что есть в Git, и вернет все в правильное состояние, идентичное источнику истины.

Argo CD — один из самых популярных инструментов GitOps. Он живет внутри Kubernetes и развертывает там сущности. Argo CD предоставляет удобный RBAC, то есть управление правами и доступом. В интерфейсе вы можете отслеживать свои действия, управлять приложениями и принудительно синхронизировать их. Компакт-диск Argo является частью CNCF, что придает ему большое доверие.

Содержание:

Основы Argo CD
Схема работы
Интерфейс
Обновление приложений
Плюсы и минусы Argo CD
Арго CD API
набор приложений
Примеры использования ApplicationSet
Как выглядит ApplicationSet
Итог: плюсы и минусы подхода GitOps

Основы Argo CD

Argo CD может быть развернут в кластер:

Общие манифесты
настроить
Jsonnet
Хелм диаграммы

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

Основные объекты, с которыми работает этот инструмент:

кластер
хранилище
приложение

Приложение является корневым объектом на компакт-диске Argo. Он указывает, что и где размещать. Объект «приложение» привязан к одному объекту «проект», который необходим для разграничения прав доступа. Внутри Argo CD может быть много «проектов». Допустим, это папки для разграничения прав доступа и удобной иерархии приложений.

Как выглядит манифест приложения:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
 name: app
 namespace: argocd
spec:
 # what
 source:
   path: app
   repoURL: https://gitlab.ktsstudio.ru/argocd/app.git
   targetRevision: HEAD
 # where
 destination:
   namespace: app
   server: https://kubernetes.default.svc
 # project
 project: default

Все, над чем работает Argo CD, хранится в самом кластере: все сущности — это отдельные «Пользовательские ресурсы» со своими APIVersion и «kind».

На рисунке выше показан пример «приложения», которое развертывает приложение. В «source» указываем, из какого репозитория и из какой папки брать график. В «назначении» указываем кластер и «пространство имен», в которое будем деплоить. А в «проекте» мы определяем, какому проекту будет принадлежать наше приложение.

Схема работы

Описание работы Argo CD можно найти на официальном сайте. Здесь у нас есть API, с которым пользователь взаимодействует либо через веб-интерфейс, либо через клиент. Есть служба репозитория, которая работает с репозиториями и хранит кеш. А сердцем решения является Application Controller, который сравнивает текущее состояние инфраструктуры с тем, что описано в репозиториях. Если происходят изменения, приложение переходит в состояние синхронизации.

Интерфейс

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

Обновление приложений

Вы можете обновлять приложения на компакт-диске Argo как вручную, так и автоматически.

Вручную

В первом случае разработчик отправляет проект в Git. Образ собран. Затем он отправляется в реестр. Далее нужно вручную изменить тег этого изображения в values.yaml в Git-репозитории с диаграммами. Компакт-диск Argo обнаруживает это и, в зависимости от того, где были сделаны изменения, применяет их к нужной среде. Ручное развертывание вызывает проблемы с безопасностью: вы должны предоставить разработчику доступ к репозиторию с диаграммами, где хранятся файлы значений.

Автоматически

Естественно, нас больше интересует этот вариант. На компакт-диске Argo есть отдельно установленный компонент Image Updater, который постоянно отслеживает реестр контейнеров. Как только туда поступает новая версия, она меняет версию изображения в самой диаграмме и применяет изменения к кластерам.

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

Плюсы и минусы Argo CD

Плюсы:

Постоянная синхронизация. Если в нашем случае Helm выйдет из строя и зависнет, Argo CD будет постоянно пытаться применить изменения к инфраструктуре.
Дружественный интерфейс. Очень наглядное представление объектов, развернутых в Kubernetes.
Просмотр логов. Открываем модуль, переходим к описанию и видим вкладку Журналы. Он будет отображать все события, которые произошли. Вы можете просмотреть журналы всех запущенных и неудавшихся модулей. Пока логов немного, например 50 строк, все работает быстро. Но если их количество увеличивается, стоит использовать для просмотра веб-интерфейс отдельной системы сбора логов.

Минусы:

Добавление приложений вручную. Например, мы купили новый кластер и хотим что-то в него добавить. Нам придется вручную добавить новое «приложение» в репозиторий и указать, куда и откуда мы добавляем проекты. Из-за сложности добавления новых приложений есть еще один недостаток.
Невозможность динамического создания окружения. Невозможно отследить момент, когда разработчик что-то запихивает в ветку. Нам все равно придется идти в другой репозиторий, создавать там «приложение», и только тогда появится наше приложение. Но есть два решения этой проблемы.

Фактически эти недостатки решены в Argo CD. Рассмотрим это далее, сравнив два подхода к их решению.

Argo CD API и push-модель

Если мы использовали Helm, мы удаляем команду Helm Upgrade и вместо этого делаем kubectl create app.yaml,kubectl upgrade app.yaml. Соответственно, компакт-диск Argo начнет отслеживать все изменения. Когда мы создаем новую динамическую среду, мы создаем эти настраиваемые ресурсы через Argo CD API или напрямую публикуем YAML с манифестом в кластер Kubernetes. Результатом является автоматическая динамическая конфигурация компакт-диска Argo.

Рассмотрим второй вариант решения проблемы: использование мощного инструмента ApplicationSet.

ApplicationSet: оставаться в рамках модели вытягивания

Argo CD имеет ApplicationSet, собственный инструмент для динамического создания «приложения» в модели пула.

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

1.Шаблон, то есть описание того, что генерировать.
2.Правила

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

Важный момент: с компакт-диском Argo вы можете работать с репозиториями SCM, такими как GitLab, GitHub и Bitbucket. Также вы можете следить за появлением в них новых веток. Правила можно комбинировать, то есть делать умножение. Например, вы можете умножить кластеры на папку Git с диаграммами. Таким образом, набор карт из этой папки будет установлен в каждом кластере.

Примеры использования ApplicationSet

Настройка кластера

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

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

Как здесь помогает ApplicationSet? Мы настраиваем его для отслеживания папки с диаграммами и развертывания этих диаграмм на всех кластерах. Когда мы добавляем новый кластер на компакт-диск Argo, он сразу начинает разворачивать в него все эти карты. Контроллер Ingress, cert-manager и VictoriaMetrics появятся в качестве примера стека мониторинга. Таким образом, вы можете убедиться, что все кластеры имеют необходимый набор инструментов инфраструктуры. Здесь нет ручных действий: кроме добавления кластера, все остальное сделает Argo CD. Если мы хотим добавить новый элемент во все кластеры, мы просто добавляем его в папку диаграммы инфраструктуры, и все будет развернуто автоматически.

Динамические среды

Пример. Есть команда разработчиков, которые работают над двумя проектами. Они используют общую методологию и разрабатывают фичи в отдельных ветках с именами вроде фича-‹номер задачи›. Мы создаем ApplicationSet, настраиваем его на группу Gitlab, содержащую эти проекты, и указываем, что вы хотите отслеживать ветки типа feature-*. В результате Argo CD будет генерировать сущности «приложения» для каждой отдельной ветки разработчика.

Полная автоматизация (крайний вариант)

Это пример для тех, кто не боится экспериментировать. Здесь мы создаем несколько объектов ApplicationSet. Затем разработчик просто создает проект в нужной группе. Argo CD и его ApplicationSets видят, что в группе появился новый проект. Они сразу разворачивают для него продакшн, стадию и динамическое окружение, когда разработчик создает ветки в этих репозиториях.

Как выглядит ApplicationSet

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata: ...
spec:
 generators:
   - scmProvider:
       # ...
       filters:
         - branchMatch: ^feature
           repositoryMatch: ^backend
       gitlab:
         allBranches: true
         api: "https://gitlab.team.ktsstudio.ru"
         group: applicationset
         ...

В разделе «генераторы» указываем правила генерации «приложений». В этом случае мы указываем GitLab, отслеживаем все репозитории, которые начинаются с «бэкэнд», и развертываем только ветки, которые начинаются с «функции».

В разделе «шаблон» указываем шаблон, используемый для создания «приложения». Обратите внимание, что внутри вы можете использовать различные готовые переменные с компакт-диска Argo (например, «репозиторий» и «ветвь»).

template:
 metadata:
   name: >-
     {{ printf "{{ repository }}-{{ branch }}" }}
 spec:
   destination:
     namespace: >-
       {{ printf "{{ repository }}-{{ branch }}" }}
     name: dev-cluster
   project: my-service
   source:
     # ...path, repoURL, targetRevision
     helm:
       parameters:
         - name: "ingressHost"
           value: >-
             {{ printf "{{ branch }}.example.com" }}

Пример генерации:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
 name: backend-auth-feature-1
 namespace: argocd
spec:
 destination:
   namespace: backend-auth-feature-1
   name: dev-cluster
 project: my-service
 source:
   # path, repoURL, targetRevision...
   helm:
     parameters:
       - name: "ingressHost"
         value: feature-1.example.com

Итог: плюсы и минусы подхода GitOps

Классическая push-модель везде использует CD Jobs, и вносить изменения можно только через них. Отсюда и проблема. Например, если вы хотите изменить способ получения сертификата, вам нужно заходить в каждый репозиторий отдельно, вносить изменения, запускать пайплайны, и только потом все синхронизируется.

С компакт-диском Argo вы можете удалить этот шаг. Argo нужны только GitLab и Docker Registry, с помощью которых он будет генерировать объекты «приложения» и обновлять их. То есть этим инструментом мы решаем все проблемы с синхронизацией.

Плюсы и минусы подхода GitOps