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:
— указать адрес container registry, например :
argocd-image-updater.argoproj.io/image-list: frontend:~v0.0
Подобная стратегия позволить отслеживать изменения версий внутри минорного релиза v0.0
По умолчанию используется стратегия версионирования semver, но можно сделать и другую используя аннотацию :
argocd-image-updater.argoproj.io/
Стратегия | Описание |
semver | Обновление до версии согласно политике |
latest | обновление до наиболее последней версии |
name | Обновление до наиболее последней версии, отсортированной по имени в алфавитном порядке |
Следующим наиболее важным параметром, настраиваемым в виде аннотации к application является выбор политики обратной записи (как нам фиксировать изменения в коде в случае изменения образа) :
Императивный метод — используя ArgoCD api (не фиксирует);
Декларативный метод — фиксирует изменения в гит;.
Императивный метод фактически выполняет argocd app set --parameter, и он является персистентным только пока приложение не удалено из ArgoCD. Данный метод удобен если приложения создаются через webui. Также он применяется по умолчанию.
Если мы хотим использовать второй способ -то нам необходима аннотация:
argocd-image-updater.argoproj.io/write-back-method: git
В случае использования хранения в системе контроля версий , в нем создается манифест .argocd-source-
Важно отметить что в отличие от 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.
