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

Мы в компании периодически партнёримся с интересными ребятами и вместе организуем мероприятия: встреча предпринимателей, онлайн-квартирник, День продакт-менеджмента. Этот цикл из трёх статей — текстовая версия выступления со Дня Техдира. Выступление было подготовлено совместно с Southbridge и у него два автора:

Сергей Маленко

руководитель DevOps-юнита KTS

Сергей Бондарев

архитектор Southbridge

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

Всего на основе доклада мы подготовили три статьи, которые пойдут по порядку:

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

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

Как управлять инфраструктурой в GitOps с помощью Crossplane
новый подход к IaC и как его можно объединить с ArgoCD

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

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

Содержание:

• Основы ArgoCD

  • Схема работы

  • Интерфейс

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

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

• API Argo CD 

• ApplicationSet

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

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

• К чему приходим в итоге: плюсы и минусы GitOps-подхода

Основы ArgoCD

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

• Обычные манифесты

• Kustomize

• Jsonnet

• Helm-чарты

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

Основные сущности, которыми оперирует этот инструмент — это:

• кластер

• репозиторий

• application

Application — это корневая сущность в Argo CD, в которой указано, что и куда развертывать. Сущность application привязана к одному объекту Project, который нужен для разграничения прав доступа. Project внутри ArgoCD может быть много, условно это папки для разграничения прав доступа и удобной иерархии приложений.

Как выглядит манифест application:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
 name: app
 namespace: argocd
spec:
 # Что
 source:
   path: app
   repoURL: https://gitlab.ktsstudio.ru/argocd/app.git
   targetRevision: HEAD
 # Куда
 destination:
   namespace: app
   server: https://kubernetes.default.svc
 # Проект
 project: default

Все, чем оперирует ArgoCD, хранится в самом кластере — все сущности являются отдельными Custom resource со своим apiVersion и kind.

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

Схема работы

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

Интерфейс

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

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

Обновлять приложения в Argo CD можно вручную и автоматически.

Вручную

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

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

Естественно, нас больше интересует этот вариант. В Argo CD есть отдельно ставящийся компонент Image Updater, который постоянно следит за Container Registry. Как только там появляется новая версия, он сам меняет версию образа в чарте и применяет изменения в кластерах. 

При этом мы можем не только просто брать каждый раз последнюю версию, но и использовать стратегии посложнее: например, работать по regex или использовать семантические версии.

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

Плюсы: 

1. Постоянная синхронизация. Если Helm в нашем случае будет сбоить и зависать, то Argo CD будет постоянно пытаться применять изменения к инфраструктуре. 

2. Удобный интерфейс. Очень наглядное представление развернутых в Kubernetes сущностей.

3. Просмотр логов. Открываем под, переходим к описанию и видим вкладку Logs, на которой будут отображаться все происходившие события. Можно посмотреть логи всех запущенных подов и подов со сбоями. Пока логов немного, например 50 линий, все работает быстро. Но если их количество выросло, то стоит использовать веб-интерфейс отдельной системы сбора логов для просмотра.

Минусы:

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

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

На самом деле эти минусы решаются в ArgoCD. Мы рассмотрим это дальше, сравнив два подхода к их решению.

API Argo CD и Push модель

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

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

ApplicationSet — остаемся в рамках Pull-модели

В Argo CD есть свой инструмент для динамического создания application в рамках пулл-модели — ApplicationSet.

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

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

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

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

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

Сетап кластеров

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

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

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

Динамические окружения

Пример. есть команда разработчиков, которые делают два проекта. Они используют общую методологию и разрабатывают фичи в отдельных ветках с названиями вида feature-<номер задачи>. Мы создаём ApplicationSet, настраиваем его на группу Gitlab, в которой находятся эти проекты и указываем, что следить нужно за ветками вида feature-*. В итоге ArgoCD будет генерировать сущности application для каждой отдельной ветки разработчика.

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

Это пример для тех, кто не боится экспериментировать. Здесь мы создаём несколько объектов ApplicationSet. Затем разработчик просто создаёт проект в нужной группе. Argo CD и его ApplicationSet’ы видят, что появился новый проект в группе. Под него они сразу же разворачивают production-контур, stage-контур и динамический контур, когда разработчик создаёт ветки в этих репозиториях. 

Как выглядит 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
         ...

В секции generators указываем, по каким правилам генерировать Application’ы. В данном случае мы указываем GitLab, отслеживаем все репозитории, которые начинаются на backend, и развёртываем только ветки, начинающиеся на feature. 

В секции template указываем шаблон, по которому будет создаваться Application. Обратите внимание, что внутри можно использовать различные готовые переменные от ArgoCD (например, repository и branch)

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-подхода

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

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

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

Плюсы: 

1. Контроль действий над инфраструктурой. Мы видим все действия и можем управлять доступом к инфраструктуре через GitLab

2. Постоянная синхронизация. Если кто-то вручную внесёт изменения, Argo CD будет постоянно пытаться откатить их обратно. То есть мы получаем защиту от ненужных правок. При этом в Argo CD можно отключить синхронизацию, например если вам нужно что-то протестировать. 

3. Проще управление большой инфраструктурой. Например, Argo CD очень помогает, если нужно в каждый кластер разросшейся инфраструктуры добавить новый Ingress-контроллер или поправить настройки стека мониторинга. 

Минусы:

1. Более сложное внедрение. Если проект один и мало инфраструктуры, то проще использовать обычные пайплайны и push модель.

Следующая часть доклада будет касаться управление самой инфраструктурой с использованием нового инструмента Crossplane. Он позволит нам создавать любые объекты в облаках, синхронизировать их состояние используя только кластер Kubernetes.