Новые возможности werf: CI/CD на основе werf и Argo CD
В этой статье мы рассмотрим новый экспериментальный режим совместной работы 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 покрывает каждый из инструментов, можно увидеть на этой схеме:
«Эталонный» цикл CD/CD и роль werf и Argo 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.
Рассмотрим каждый этап подробнее.
werf
В начале статьи был рисунок с «эталонным» процессом CI/CD. Он очень четко отражает суть того, что происходит на этапе подготовки и публикации релизных артефактов.
Сначала пользователь локально разрабатывает новый функционал приложения или вносит в него какие-то изменения. werf в данном случае сильно упрощает работу, т.к. имеет разные настройки, способствующие удобству локальной разработки — например, отслеживание изменений в файлах или отслеживание новых коммитов в локальном Git-репозитории, находящемся в каталоге с проектом (каталог .git).
Далее следует коммит изменений в репозиторий. В локальной разработке это приводит к пересборке и перевыкату приложения в локальный кластер, а в удаленном репозитории — к триггеру CI/CD-системы и запуску сборки с помощью werf уже на ее worker«е.
Далее наступает фаза тестов: приложение тестируется и проверяется, после чего werf подготавливает так называемый bundle — артефакт релиза, при этом обеспечивается сборка всех необходимых образов, публикуются Helm-чарты, настроенные на использование собранных образов, в container registry, формируя бандл (bundle).
Argo CD
Задача 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-кластер совместно, используя сильные стороны обоих для достижения лучшего результата. Новый режим пока еще находится в разработке и тестируется, но попробовать его можно уже сейчас, выполнив ряд инструкций из документации. Мы будем рады обратной связи, замечаниям и предложениям!
