Gitops и ArgoCD: отслеживание изменений образов

Данная статья написана по итогу успешного прохождения курса Инфраструктурная платформа на основе Kubernetes

С развитием методологии Gitops - имплементации непрерывной поставки при которой описание и изменение системы производятся декларативно с использованием системы контроля версий, а также являющейся естественным продолжением и развитием infrastracture as a code - появляются удобные инструменты для внедрения данного метода. В первую очередь хочется выделить  самые популярные инструменты непрерывной поставки по версии CNCF - ArgoCD и Flux. Оба приложения реализуют схожий функционал - синхронизацию git и кластера kubernetes. Если сравнивать два этих решения ,то  заметно, что у Flux  есть ряд ограничений:

• Работа и управление одним Кластером;

• Один кластер - один репозиторий.

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

Напомню ключевые особенности :

• Приложение имплементируется как контроллер в кластере, отслеживает изменения в git ,сравнивая с текущим состоянием, и ,в случае изменений в исходном коде, помечает приложение как рассинхронизированное , и автоматически применяет изменения(или в ручном  режиме, в зависимости от настройки);

• Имеется поддержка большого количества инструментов для применения в кластере (Kustomize, Helm, Ksonnet, Jsonnet, plain-YAML);

• Откат к любому возможному комиту,зафиксированному в системе контроля версий;

• Удобная визуализация.

Во время внедрения и  эксплуатации появился важный вопрос:

если мы осуществляем деплой микросервисов в кластер kubernetes ,то очень важным моментом будет являться обновление образа в репозитории. Например мы разрабатываем приложение, настроили CI для сборки образа и дальнейшей его отправки в container registry ,и хотим ,чтобы оно как можно скорее оказалось в кластере, используя инструмент CD.Но ведь манифесты деплоя  у нас не изменились, при добавлении нового образа ArgoCD не увидит этого, а в переменной helm у нас хранится статичная версия образа. Да - конечно мы можем вручную изменить, сделать коммит и ArgoCD автоматически обновит состояние кластера, но как это автоматизировать ,используя текущий стэк?

Вернемся к сравнению с flux:

при использовании этого инструмента мы работаем с helm оператором, интегрированным в кластер и его сущностями - helmrelease. Мы добавляем отслеживание container registry в манифест helmrelease для приложения по определенному паттерну, например используя общепринятое семантическое версионирование  semver :

apiVersion: helm.fluxcd.io/v1
kind: HelmRelease
metadata:
  name: frontend
  namespace: microservices-demo
  annotations:
    fluxcd.io/ignore: "false"
    fluxcd.io/automated: "true"
    flux.weave.works/tag.chart-image: semver:~v0.0
spec:
  releaseName: frontend
  helmVersion: v3
  chart:
    git: git@gitlab.com:wenger23/microservices-demo.git
    ref: master
    path: deploy/charts/frontend
  values:
    image:
      repository: registry.gitlab.com/wenger23/microservices-demo/frontend
      tag: v0.0.40
    imagePullSecrets:
    - name: registry-credentials

Теперь  Flux отслеживает изменения тэга в container registry ,и если появилась новая  версия - сам вносит изменения в код!

Таким образом мы запустили процесс  обновления приложения в кластере. Замечу в свою очередь ,что такие изменения в git доставляют ряд неудобств - в случае коммита в переменные helm, необходимо не забывать сделать пул последних изменений, которые внес flux, иначе будет  merge конфликт .

До недавнего времени у ArgoCD отсутствовала такая функциональная возможность ,и при изменении образа приходилось делать коммит вручную, фиксируя новую версию образа в коде. Сейчас - появилось отдельное приложение - Argo CD Image Updater. Это специальная утилита ,которая интегрируется в текущую установку ArgoCD и позволяет  отслеживать изменения в используемом container registry, автоматически обновляя приложение.Из  основных возможностей хотелось  бы отметить :

• Поддержка большого количества видов container registry (как публичных так и частных);

• Отслеживание обновлений , используя различные cтратегии версионирования;

• Параллельное обновление приложений.

Также важно сказать об ограничениях :

• Приложение должно обязательно быть  под управлением ArgoCD;

• Поддержка только Helm и Kustomize, причем ,при использовании helm - image.tag должен быть обязательно шаблонизирован (вынесен в переменные).

Согласно  документации -наиболее удобным и правильным будем являться установка в текущую инсталляцию ArgoCD, в тот же namespace(хотя и есть возможность установить в другой кластер). Установка осуществляется применением манифеста из репозитория проекта.Затем нам нужно сказать  какие  applications (сущности ArgoCD)  необходимо отслеживать: для этого необходимо добавить аннотации с параметрами в зависимости от выбранной стратегии :

   argocd-image-updater.argoproj.io/image-list: <image_spec_list>

- указать адрес container registry ,например :

argocd-image-updater.argoproj.io/image-list: frontend:~v0.0

Подобная стратегия позволить отслеживать изменения версий внутри минорного релиза v0.0

По умолчанию используется стратегия версионирования semver ,но можно  сделать и другую используя аннотацию :

argocd-image-updater.argoproj.io/<image_name>.update-strategy: <strategy>

Следующим наиболее важным параметром, настраиваемым в виде аннотации к application является выбор политики обратной записи(как нам фиксировать изменения в коде в случае изменения образа) :

• Императивный метод -  используя ArgoCD api (не фиксирует);

• Декларативный метод - фиксирует изменения в гит;.

Императивный метод фактически выполняет argocd app set --parameter, и он является персистентным только пока приложение не удалено из ArgoCD.  Данный  метод удобен если приложения создаются через webui. Также он применяется по умолчанию.

Если мы хотим использовать второй способ -то нам необходима аннотация:

argocd-image-updater.argoproj.io/write-back-method: git

В случае использования хранения в системе контроля версий ,в нем создается манифест .argocd-source-<appName>.yaml, в котором будет обновляться версия тэга :

Важно отметить что в отличие от flux ,никакое другое приложение не  использует этот файл ,что минимизирует возможность merge конфликтов.Также для получения доступа  в гит и внесения изменений argocd image updater использует авторизацию уже настроенную в ArgoCD, но при этом есть возможность прописать отдельные credentials.

Настроенное приложение ArgoCD для работы с argocd image updater будет выглядеть примерно так :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  annotations:
    argocd-image-updater.argoproj.io/image-list: registry.gitlab.com/microservices28/frontend:~v0.0
    argocd-image-updater.argoproj.io/write-back-method:  git
  name: frontend
  namespace: argocd
spec:
  destination:
    namespace: microservices28
    server: https://kubernetes.default.svc
  project: microservices
  source:
    helm:
      valueFiles:
      - values.yaml
    path: deploy/charts/frontend
    repoURL: https://gitlab.com/microservices28/frontend.git

Конечную целевую схему можно отобразить следующим образом :

Таким образом и без того мощная утилита дополняется важным функционалом, благодаря чему все большее количество людей будет ее выбирать в качестве основного CD инструмента .Argo CD Image Updater  сейчас находится в стадии активной разработки -текущая версия 0.9.2 ,и. по заверениям разработчиков до версии 1.0. может быть ряд крупных изменений, влияющих на функционал.

Используемая документация :

Flux;

ArgoCD;

Argocd image updater.