Новые возможности werf: CI-CD на основе werf и Argo CD

В этой статье мы рассмотрим новый экспериментальный режим совместной работы Open Source-утилиты werf и инструмента для непрерывной доставки Argo CD, объединяющий в себе возможности и удобства обоих проектов в рамках одного CI/CD-процесса. Сейчас идет активная разработка этих возможностей werf, но в первом приближении функционал уже доступен и готов к использованию.

Введение

Argo CD ^[1] и werf ^[2] — инструменты для доставки приложений в кластер Kubernetes с использованием Git-репозитория в качестве единственного источника истины. Они выполняют схожие задачи, но делают этого немного по-разному, поэтому напрямую противопоставлять их друг другу не совсем корректно.

Argo CD представляет собой Kubernetes-оператор непрерывной доставки, реализующий метод GitOps ^[3]: он работает внутри 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 (подробнее об этих и других стратегиях деплоя можно прочитать в обзорной статье ^[4]).

Преимущества, получаемые от werf:

• Вся необходимая информация для разработки и отладки находится в CI-системе.

• Консистивный и эффективный метод разработки и публикации конечных артефактов для выката в production:

  • локальная разработка приложений на машинах разработчиков (пример с minikube ^[5]);

  • тестирования (Unit-тесты, linter’ы, интеграционные и acceptance-тесты и т.д.);

  • простая организация review-окружений ^[6].

• Стандартизация конфигурации сборки и деплоя проекта с возможностью из коробки объединить сборку и публикацию релизов приложения.

• Возможность интеграции с любой CI/CD-системой.

Этот режим имеет довольно широкую аудиторию охвата, начиная от разработчиков и заканчивая администраторами кластеров. Первым он дает возможность пользоваться удобной и привычной системой CI/CD, которая предоставляет интеграцию с Git, pull requests, возможность выкатывать в review-окружения и хороший observability для pipeline’ов и Job’ов с привязкой к Git. Администраторам же он дает гарантии того, что единой точкой внесения всех изменений в кластер является Git и Argo CD.

Процесс разработки с точки зрения пользователя

Когда все уже настроено (ссылки на инструкции приведены ниже), для конечного пользователя процесс будет выглядеть приблизительно так:

• Пользователь разрабатывает проект локально ^[7] на своей рабочей машине:

  • собирает образы;

  • может выкатывать приложение в локальный кластер 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.

Более подробно про этот процесс можно почитать в документации ^[8].

Как это работает на принципиальном уровне

Условно процесс можно разделить на две части:

• werf отвечает за подготовку и публикацию релизного артефакта в container registry — так называемый bundle ^[9].

• Argo CD выкатывает релизный артефакт из container registry в production.

Рассмотрим каждый этап подробнее.

werf

В начале статьи был рисунок с «эталонным» процессом CI/CD. Он очень четко отражает суть того, что происходит на этапе подготовки и публикации релизных артефактов. 

Сначала пользователь локально разрабатывает новый функционал приложения или вносит в него какие-то изменения. werf в данном случае сильно упрощает работу, т.к. имеет разные настройки, способствующие удобству локальной разработки — например, отслеживание изменений в файлах или отслеживание новых коммитов в локальном Git-репозитории, находящемся в каталоге с проектом (каталог .git). 

Далее следует коммит изменений в репозиторий. В локальной разработке это приводит к пересборке и перевыкату приложения в локальный кластер, а в удаленном репозитории — к триггеру CI/CD-системы и запуску сборки с помощью werf уже на ее worker’е.

Далее наступает фаза тестов: приложение тестируется и проверяется, после чего werf подготавливает так называемый bundle — артефакт релиза ^[10], при этом обеспечивается сборка всех необходимых образов, публикуются Helm-чарты, настроенные на использование собранных образов, в container registry, формируя бандл (bundle). 

Argo CD

Задача Argo CD в том, чтобы отследить появление нового бандла в container registry и развернуть его в кластере. Сделано это может быть как в ручном режиме после соответствующей команды пользователя, так и автоматически, если настроен Argo CD Image Updater с соответствующим патчем ^[11]. Этот патч следит за появлением новых бандлов от werf и запускает развертывание новой версии приложения в кластере.

Для Argo CD был подготовлен специальный плагин в виде готового образа (registry.werf.io/werf/werf-argocd-cmp-sidecar:VERSION), который отвечает за описанную выше интеграцию werf и Argo CD. Именно этот плагин отвечает за рендеринг опубликованного бандла. Использование плагина опционально, но без него не будет работать связь между CI/CD-системой и развернутым приложением, т.к. именно он позволяет соотносить элементы развернутого приложения с соответствующими коммитами в исходном Git-репозитории. Без него все так же будет работать, но посмотреть теги и лейблы, проставленные werf во время сборки, будет невозможно.

Подробнее о возможностях плагина ^[12] и патча ^[13] можно прочитать в официальной документации.

Как попробовать

Попробовать новый режим можно уже сейчас, убедившись, что у вас установлена последняя версия werf. Для этого необходимо подготовить Kubernetes-кластер ^[14], установив Argo CD и нужные зависимости, а затем настроить свою CI/CD-систему ^[15] для работы с Argo CD и werf.

Заключение

Мы рассмотрели новый экспериментальный режим werf, в котором пользователю предлагается воспользоваться возможностями двух инструментов для доставки приложений в K8s-кластер совместно, используя сильные стороны обоих для достижения лучшего результата. Новый режим пока еще находится в разработке и тестируется, но попробовать его можно уже сейчас, выполнив ряд инструкций из документации. Мы будем рады обратной связи, замечаниям и предложениям!