В этой статье пойдет речь об организации процесса непрерывной доставки и непрерывного развертывания приложения с помощью werf и модели GitOps. Будут рассмотрены следующие вопросы:

  • использование werf для сборки и публикации артефактов релиза;
  • использование GitOps-инструмента Argo CD для доставки артефактов релиза в Kubernetes;
  • объединение werf и Argo CD с помощью бандлов(bundles).

Ключевые моменты и принципы

В этом разделе будут определены ключевые моменты и принципы, необходимые для реализации процесса CI/CD.

Единый источник истины

В описываемом подходе Git-репозиторий проекта считается единственным источником истины. Он содержит:

  • исходный код приложения;
  • инструкции по сборке образов;
  • файлы Helm-чартов.

Артефакты релизов

  1. Артефакты релизов публикуются в container registry и включают:
    • собранные образы;
    • файлы Helm-чартов.
  2. Артефакт релиза может быть подготовлен и опубликован для произвольного Git-коммита.
  3. К опубликованным артефактам предъявляются два требования: они должны быть неизменяемыми и воспроизводимыми.
  4. В зависимости от настроек CI/CD, артефакты релиза могут публиковаться:
    • для каждого коммита в основной ветке, после чего развертываться в production;
    • только для Git-тэгов, соответствующим релизам приложения.
  5. Для подготовки артефактов релиза можно использовать любую распространенную систему CI/CD (например, GitLab CI/CD или GitHub Actions).

Развертывание в Kubernetes с помощью GitOps

В кластере развернут GitOps-оператор, реализующий pull-модель для развертывания релизов проекта. Он:

  • следит за новыми версиями артефактов релизов в container registry;
  • разворачивает определенную версию артефакта в кластер Kubernetes.

В зависимости от конфигурации CI/CD GitOps-оператор может развертывать новую версию артефакта релиза по команде пользователя (Continuous Delivery) или автоматически (Continuous Deployment).

Эталонный цикл CI/CD

Эталонный цикл CI/CD будет реализован с использованием двух основных инструментов: werf и Argo CD.

На схеме ниже блоки представляют собой стадии цикла и показаны инструменты их реализации.

1. Локальная разработка

Цикл начинается с локальной разработки, для которой werf предлагает следующий функционал:

  • Все команды werf поддерживают флаги --dev и --follow для упрощения работы с uncommitted-изменениями и дополнениями, внесенными в исходный код приложения;
  • werf позволяет использовать одну и ту же конфигурацию сборки и развертывания для развертывания приложения как локально, так и в production;
  • Специальные окружения (передаются параметром --env ENV) позволяют настроить конфигурации сборки и развертывания для развёртывания приложения в локальный кластер Kubernetes для локальной разработки.

2. Коммит

Этап Коммит подразумевает, что вся конфигурация сборки и развертывания werf, а также исходный код приложения должны быть обязательно загружены в Git-репозиторий проекта.

Например, при checkout’е коммита и выполнении инструкции CI/CD-системой, эти инструкции не должны случайно или намеренно генерировать какие-либо динамические входные конфигурационные файлы для конфигурации сборки и развертывания werf.

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

3. Сборка и публикация образов

werf поддерживает сборку образов с помощью Dockerfile или Stapel с их последующей публикацией в container registry. Он обеспечивает распределенное кэширование слоев и тегирование на основе содержимого, предотвращая ненужную пересборку образов.

Сборка образов осуществляется командой werf build. Дополнительную информацию можно почерпнуть из статьи Настройка CI/CD.

4. Быстрое тестирование коммитов

Важной частью подхода CI/CD является выполнение так называемого быстрого тестирования каждого коммита в Git-репозитории. Обычно на этом этапе выполняются unit-тесты и линтеры.

Как правило, тесты запускаются в одноразовых контейнерах с собранными образами. Для запуска таких одноразовых контейнеров werf предлагает следующие команды:

  • werf run — выполняет соответствующую команду в одноразовом контейнере на сервере Docker;
  • werf kube-run — выполняет соответствующую команду в одноразовом контейнере на кластере Kubernetes.

Дополнительную информацию можно почерпнуть из статьи Настройка CI/CD.

5. Подготовка артефактов релизов

На этом этапе необходимо подготовить артефакт релиза, воспользовавшись так называемыми бандлами werf.

Команда werf bundle publish:

  • обеспечивает сборку всех необходимых образов;
  • публикует файлы helm chart, настроенные на использование собранных образов, в container registry, формируя так называемый бандл (bundle).

Опубликованный бандл затем может быть развернут в кластере Kubernetes с помощью Argo CD как обычный OCI-чарт Helm.

6. Приемочные тестирования

Приемочные тесты — неотъемлемая часть CI/CD. Такие тесты, как правило, проходят в течение длительного времени и могут потребовать окружения, максимально приближенного к production.

Как правило, приемочное тестирование выполняется автоматически после слияния Pull Request’а с главной веткой.

Приемочное тестирование новых релизов не обязательно для Continuous Integration, но в большинстве случаев необходимо для Continuous Delivery. Другими словами, допустимо вносить новые коммиты и PR в главную ветку без проведения приемочных тестов, однако артефакт релиза должен успешно пройти приемочные тесты перед развертыванием в production.

werf позволяет задавать специальные тестовые окружения (с помощью параметра --env ENV).

  • В таких тестовых окружениях могут быть специализированные файлы конфигурации сборки и развертывания;
  • Кроме того, в тестовых окружениях также имеется специальный post-install Helm-ресурс Job.

Для запуска приемочных тестов werf предлагает следующие команды:

  • werf converge для развертывания в Kubernetes production-подобного окружения и запуска тестового Job‘а как post-install Helm-хука;
    • Для этой команды потребуется доступ в Git-репозиторий проекта;
  • werf dismiss для удаления ранее развернутого production-подобного тестового окружения;
  • werf bundle apply для развертывания в Kubernetes production-подобного окружения и запуска тестового Job‘а как post-install Helm-хука;
    • Этой команде не требуется доступ в Git-репозиторий, только доступ к бандлу, опубликованному в container registry.

Также приемочные тесты могут запускаться Argo CD с использованием опубликованного артефакта релиза — bundle’а werf. В этом случае Argo CD развернет в Kubernetes production-подобное окружение и запустит тестовый Job как post-install Helm-хук.

Дополнительную информацию можно почерпнуть из статьи Настройка CI/CD.

7. Развертывание в production

На этом этапе Argo CD должен развернуть опубликованный артефакт релиза для целевого коммита приложения в кластере Kubernetes.

В данном случае бандл werf выполняет функцию артефакта релиза. Argo CD воспринимает его как обычный OCI Helm-чарт.

Argo CD может развернуть целевой артефакт релиза после соответствующей команды пользователя.

Argo CD Image Updater с патчем Непрерывное развертывание приложений на основе OCI-совместимых Helm-чартов способен автоматически развертывать последнюю версию опубликованного артефакта релиза.

Дополнительную информацию можно почерпнуть из статьи Настройка CI/CD

назад
далее