В этой статье мы рассмотрим новый экспериментальный режим совместной работы Open Source-утилиты werf и инструмента для непрерывной доставки Argo CD, объединяющий в себе возможности и удобства обоих проектов в рамках одного CI/CD-процесса. Сейчас идет активная разработка этих возможностей werf, но в первом приближении функционал уже доступен и готов к использованию. Argo CD и werf — инструменты для доставки приложений в кластер Kubernetes с использованием Git-репозитория в качестве единственного источника истины. Они выполняют схожие задачи, но делают это немного по-разному, поэтому напрямую противопоставлять их друг другу не совсем корректно. Argo CD представляет собой Kubernetes-оператор непрерывной доставки, реализующий метод GitOps: он работает внутри K8s-кластера, мониторит репозиторий с кодом или container registry с собранными артефактами и отвечает за развертывание приложения в кластере и его соответствие состоянию репозитория. Он довольно универсален, и с его помощью мы получаем возможность удобного отслеживания и управления выкатом со сложными стратегиями наподобие Blue-green и Canary, которые реализованы в Argo Rollouts. werf — это утилита, встраиваемая в любую систему CI/CD, будь то GitLab, GitHub Actions или любая другая привычная разработчикам или пользователям система управления доставкой. С ее помощью можно настроить выкат приложения в любое окружение, например, в тестовый контур, реализовать быструю сборку артефактов в соответствии с любыми минимальными изменениями в Git-репозитории, а также быстро поднять локальное окружение для разработки на своей рабочей машине. Оба этих инструмента покрывают требования CI/CD, но выполняют немного разные задачи и имеют разный подход. Основным отличием werf от Argo CD можно назвать тот факт, что werf не является оператором, который может следить за состоянием кластера и приводить его в соответствие с нужной схемой и версиями приложений (т.н. self-healing). По крайней мере, пока утилита не запущена конкретно из терминала пользователя или пайплайна CI/CD. Argo CD же, как оператор, выполняет такие задачи и уже хорошо зарекомендовал себя в широком сообществе, поэтому объединение этих двух инструментов может сделать процесс разработки и выката приложений в кластер еще более удобным. Более подробно о том, какие части «эталонного» цикла CI/CD покрывает каждый из инструментов, можно увидеть на этой схеме: Как видно из рисунка, Argo CD берет на себя только два последних пункта: приемочное тестирование и непосредственно выкат в кластер. werf же позволяет дополнить этот функционал такими вещами, как локальная разработка, сборка и публикация готовых образов в container registry, быстрое тестирование коммитов в пайплайне, подготовка релизных артефактов и запуск приемочных тестов (опционально). Связка из werf и Argo CD позволяет полностью интегрировать между собой любую CI/CD-систему и Argo CD. При этом от каждого из инструментов берутся свои возможности и особенности. Например, werf во время работы вешает на собранные артефакты лейблы и теги, по которым можно отследить, из какой ветки и какого коммита был собран тот или иной образ (для этого подготовлен специальный плагин для Argo CD, подробнее об этом ниже). Также в качестве опции, не совсем соответствующей парадигме GitOps, можно запустить деплой с помощью argo sync прямо в Job пайплайна. Преимущества, получаемые от Argo CD: Pull-модель работы системы, когда за артефактами и состоянием кластера следит работающий в нем оператор, подтягивая изменения по собственному расписанию и настройкам, реализуя self-healing-кластер (возврат кластера к состоянию из Git или container registry в случае каких-либо ручных изменений). Удобный web-интерфейс, позволяющий отслеживать состояние кластера и процессов в нем в реальном времени, а также управлять его составляющими. Возможность мультикластерной работы, когда один оператор управляет несколькими контурами. Cold cluster — резервный кластер, который синхронизируется с основным и позволяет быстро восстановить работоспособность системы в целом в случае каких-либо поломок. Argo Rollouts — возможность реализовать такие сценарии деплоя, как Blue-green или Canary (подробнее об этих и других стратегиях деплоя можно прочитать в обзорной статье). Преимущества, получаемые от werf: Вся необходимая информация для разработки и отладки находится в CI-системе. Консистентный и эффективный метод разработки и публикации конечных артефактов для выката в production: локальная разработка приложений на машинах разработчиков (пример с minikube); тестирования (Unit-тесты, linter’ы, интеграционные и acceptance-тесты и т.д.); простая организация review-окружений. Стандартизация конфигурации сборки и деплоя проекта с возможностью из коробки объединить сборку и публикацию релизов приложения. Возможность интеграции с любой CI/CD-системой. Этот режим имеет довольно широкую аудиторию охвата, начиная от разработчиков и заканчивая администраторами кластеров. Первым он дает возможность пользоваться удобной и привычной системой CI/CD, которая предоставляет интеграцию с Git, pull requests, возможность выкатывать в review-окружения и хороший observability для pipeline’ов и Job’ов с привязкой к Git. Администраторам же он дает гарантии того, что единой точкой внесения всех изменений в кластер является Git и Argo CD. Когда все уже настроено (ссылки на инструкции приведены ниже), для конечного пользователя процесс будет выглядеть приблизительно так: Пользователь разрабатывает проект локально на своей рабочей машине: собирает образы; может выкатывать приложение в локальный кластер Kubernetes. Следующим шагом он push’ит свои изменения в ветку Git-репозитория и создаёт pull request. CI/CD-система триггерит созданный PR, собирает для него образы и запускает быстрые тесты (Unit-тесты и линтеры) с помощью werf. При необходимости пользователь имеет возможность по нажатию кнопки в интерфейсе CI/CD-системы выкатить приложение в review-окружение с помощью werf. Затем, если все нормально, PR мержится в основную ветку проекта. Публикуется релизный артефакт, готовый для дальнейшего тестирования и для выката в production-like или production-окружение. Запускаются долгие тесты: acceptance, e2e и так далее. Выполнить это можно двумя способами: через выкат релизного артефакта с помощью werf или Argo CD. Релизный артефакт выкатывается в контур Kubernetes через Argo CD. Более подробно про этот процесс можно почитать в документации. Условно процесс можно разделить на две части: werf отвечает за подготовку и публикацию релизного артефакта в container registry — так называемый bundle. Argo CD выкатывает релизный артефакт из container registry в production. Рассмотрим каждый этап подробнее. В начале статьи был рисунок с «эталонным» процессом CI/CD. Он очень четко отражает суть того, что происходит на этапе подготовки и публикации релизных артефактов.  Сначала пользователь локально разрабатывает новый функционал приложения или вносит в него какие-то изменения. werf в данном случае сильно упрощает работу, т.к. имеет разные настройки, способствующие удобству локальной разработки — например, отслеживание изменений в файлах или отслеживание новых коммитов в локальном Git-репозитории, находящемся в каталоге с проектом (каталог .git).  Далее следует коммит изменений в репозиторий. В локальной разработке это приводит к пересборке и перевыкату приложения в локальный кластер, а в удаленном репозитории — к триггеру CI/CD-системы и запуску сборки с помощью werf уже на ее worker’е. Далее наступает фаза тестов: приложение тестируется и проверяется, после чего werf подготавливает так называемый bundle — артефакт релиза, при этом обеспечивается сборка всех необходимых образов, публикуются Helm-чарты, настроенные на использование собранных образов, в container registry, формируя бандл (bundle).  Задача Argo CD в том, чтобы отследить появление нового бандла в container registry и развернуть его в кластере. Сделано это может быть как в ручном режиме после соответствующей команды пользователя, так и автоматически, если настроен Argo CD Image Updater с соответствующим патчем. Этот патч следит за появлением новых бандлов от werf и запускает развертывание новой версии приложения в кластере. Для Argo CD был подготовлен специальный плагин в виде готового образа (registry.werf.io/werf/werf-argocd-cmp-sidecar:VERSION), который отвечает за описанную выше интеграцию werf и Argo CD. Именно этот плагин отвечает за рендеринг опубликованного бандла. Использование плагина опционально, но без него не будет работать связь между CI/CD-системой и развернутым приложением, т.к. именно он позволяет соотносить элементы развернутого приложения с соответствующими коммитами в исходном Git-репозитории. Без него все так же будет работать, но посмотреть теги и лейблы, проставленные werf во время сборки, будет невозможно. Подробнее о возможностях плагина и патча можно прочитать в официальной документации. Попробовать новый режим можно уже сейчас, убедившись, что у вас установлена последняя версия werf. Для этого необходимо подготовить Kubernetes-кластер, установив Argo CD и нужные зависимости, а затем настроить свою CI/CD-систему для работы с Argo CD и werf. Мы рассмотрели новый экспериментальный режим werf, в котором пользователю предлагается воспользоваться возможностями двух инструментов для доставки приложений в K8s-кластер совместно, используя сильные стороны обоих для достижения лучшего результата. Новый режим пока еще находится в разработке и тестируется, но попробовать его можно уже сейчас, выполнив ряд инструкций из документации. Мы будем рады обратной связи, замечаниям и предложениям!  Technical writer, Linux-user