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

Kate

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

232afad86bd786d216b66b757b69720e.png

Введение​

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 в нем
«Эталонный» цикл 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-кластер совместно, используя сильные стороны обоих для достижения лучшего результата. Новый режим пока еще находится в разработке и тестируется, но попробовать его можно уже сейчас, выполнив ряд инструкций из документации.

 
Сверху