Helmwave — еще один инструмент для деплоя helm-чартов

Для деплоя приложений в Kubernetes существует огромное количество различных инструментов. Если посмотреть на соответствующий раздел в CNCF Landscape, то можно потеряться в разнообразии. Поэтому иногда хорошо иметь в своем арсенале «серебряную пулю», которая подойдет для большинства задач. Helmwave вполне может стать именно таким инструментом.

В последнее время моим самым любимым инструментом для описания декларативных деплоев в Kubernetes был Helmfile. Три неочевидные, но полезные возможности Helmfile я рассмотрела в отдельной статье на Medium: “3 Helmfile features you don’t know”. 

Фичи Helmfile, которые важно отметить:

• Встроенная возможность шаблонизации.

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

• Интеграция с HashiCorp Vault, AWS KMS и другими инструментами для работы с секретами.

• Поддержка плагина helm diff.

Несмотря на то что GitOps и инструменты, которые реализуют этот подход, сейчас на пике популярности, к ним есть много вопросов с точки зрения надежности, управляемости и наблюдаемости. Поэтому я всегда слежу за новыми проектами: они могут оказаться проще в использовании или лучше справляться с решением конкретных проблем. Так я и нашла Helmwave.

Что такое Helmwave

Readme проекта на Github довольно емко и кратко описывает основную задачу проекта:

Helmwave — это docker-compose для @helm.

Helmwave — это инструмент для декларативного описания деплоя helm-чартов. 

Давайте разберемся, чем он лучше или хуже конкурентов.

Особенности Helmwave

В Helmwave есть все необходимые стандартные фичи: everything-as-code, деплой в несколько окружений и возможность настройки дефолтной конфигурации. 

Но есть и несколько неочевидных:

• Пошаговый деплой (depends_on, allow_failure).

• Отслеживание ресурсов Kubernetes в реальном времени при помощи kubedog.

• Отсутствие внешних зависимостей: достаточно скачать бинарный файл helmwave и можно начинать деплой.

Пример использования Helmwave

Для примера я попробую решить стандартную задачу: настроить деплой в несколько окружений из одного репозитория с возможностью оверрайда конфигурации.

Для начала рассмотрим структуру проекта:

. ├── .github/ ├── .kube-linter/ │   └── config.yaml ├── README.md ├── charts/ │   ├── adservice │   ... │   └── shippingservice ├── envs-values/ │   ├── prod │   └── stage ├── helmwave.yml ├── helmwave.yml.tpl └── releases.yaml

• В директории .github/ находится конфигурация для CI/CD, в моем случае это Github Actions.

• В .kube-linter/ — файл конфигурации для линтинга манифестов.

• В charts/ — helm-чарты для microservices-demo.

• В envs-values/ хранятся значения для сред stage и production.

• helmwave.yml  — это файл, который рендерится из шаблона (helmwave.yml.tpl).

• helmwave.yml.tpl — это шаблон конфигурации деплоя.

• releases.yaml — файл со списком нужных helm-релизов и их конфигураций для деплоя.

helmwave.yml.tpl

В начале этого файла прописана версия Helmwave. Последняя версия — 0.19.5.

version: 0.19.5  .options: &options   namespace: microservices-demo   wait: true   timeout: 300s   create_namespace: true  releases: {{- with readFile "releases.yaml" | fromYaml | get "releases" }} {{ range $v := . }} - name: {{ $v | get "name" }}   chart:     name: charts/{{ $v | get "name" }}   tags: [{{ $v | get "name" }}]   values:     - envs-values/{{ requiredEnv "CI_ENVIRONMENT_NAME"}}/{{ $v | get "name" }}.yaml   <<: *options {{ end }} {{- end }}

В этом файле мы можем использовать якорь с параметрами по умолчанию (.options) и указать его в разделе releases, когда это необходимо. Таким образом мы получим максимально DRY-конфиг. Обычно в этом месте задается ряд значений по умолчанию: namespace, helm options и т.д. Полный список параметров ищите в документации.

В разделе releases задается список релизов helm, которые нужно задеплоить. Этот список можно найти в файле releases.yaml. Каждому релизу нужно задать имя и чарт, из которого должен осуществляться деплой. Другие параметры опциональны. 

Каждый релиз также содержит:

• Переменные для нужного окружения, окружение задается переменной CI_ENVIRONMENT_NAME.

• Тег с названием приложения, который можно использовать для фильтрации деплоя конкретных сервисов.

• Параметры из якоря, добавляемые через  << : *options.

releases.yaml

Структура releases.yaml не требует дополнительных пояснений:

releases:   - name: adservice   - name: cartservice ...   - name: shippingservice

helmwave.yml

В этом файле будет находится отрендеренный шаблон helmwave.yml.tpl. Чтобы его сгенерировать, можно выполнить следующую команду:

$ CI_ENVIRONMENT_NAME=stage helmwave yml  version: 0.19.5  .options: &options   namespace: microservices-demo   wait: true   timeout: 300s   create_namespace: true  releases:  - name: adservice   chart:     name: charts/adservice   tags: [adservice]   values:     - envs-values/stage/adservice.yaml   <<: *options  ...  - name: shippingservice   chart:     name: charts/shippingservice   tags: [shippingservice]   values:     - envs-values/stage/shippingservice.yaml   <<: *options

Процесс деплоя

Для реализации CI/CD я выбрала GitHub Actions, потому что они бесплатно доступны в GitHub. Более того, разработчики Helmwave сделали для них action, который помогает быстро и удобно использовать различные версии Helmwave в пайплайнах.

Процесс деплоя состоит из трех шагов: подготовка, запуск тестов и запуск деплоя в выбранном окружении.

Подготовка

На этапе подготовки устанавливаем необходимые инструменты — Helmwave и kind, который создаст Kubernetes кластер с помощью контейнеров. Далее в зависимости от значения CI_ENVIRONMENT_NAME подготавливаем план изменений с помощью helmwave.

Чтобы определить окружение, можно написать bash-скрипт или использовать возможности выбранной CI/CD платформы.

Пример для Github Actions:

- name: Set environment for branch   run: |     if [[ $GITHUB_REF == 'refs/heads/main' ]]; then         echo "CI_ENVIRONMENT_NAME=prod" >> "$GITHUB_ENV"     else         echo "CI_ENVIRONMENT_NAME=stage" >> "$GITHUB_ENV"     fi

Для тестирования и деплоя нам необходимо отрендерить helm-charts в готовые Kubernetes манифесты. Для этого нужно выполнить одну из следующих команд:

# если вы уже запускали helmwave yml helmwave build  # сгенерировать helmwave.yml и все манифесты сразу helmwave build --yml 

Эти команды создают директорию .helmwave, где содержатся необходимые манифесты и план.

Тестирование

Для тестирования я использую самые популярные инструменты:

• kube-linter

• kubeval

• pluto

Они похожи, но каждый имеет свои особенности реализации и тестируемые кейсы, поэтому я решила использовать все три в одном пайплайне.

На этом этапе можно использовать ту же команду, что и для генерации плана. Но если деплой выполняется во временной среде (как в моем случае), нужно задать дополнительный параметр diff-mode=local, который будет рендерить diff изменений локально, не отправляя запросы в кластер Kubernetes. Такой вариант также подходит для использования в CI.

helmwave build --yml --diff-mode=local

Чтобы развернуть приложение, выполните следующую команду:

helmwave up  # если хотите увидеть ход процесса деплоя  helmwave up --kubedog  # или все сразу helmwave up --yml --build --kubedog

Очистка

Чтобы удалить все созданные ресурсы, нужно выполнить одну из следующих команд:

helmwave down  # или удалить namespace в Kubernetes kubectl delete microservices-demo

Helmwave — это полноценная альтернатива helmfile и другим похожим инструментам. Несмотря на то что проект достаточно молодой, у него есть полезные и неочевидные функции, и я с интересом буду смотреть за его развитием.

От себя могу рекомендовать использовать его в ситуации, когда вам нужно быстро настроить деплой приложения и иметь возможность наблюдать за процессом деплоя в режиме реального времени. Также helmwave хорошо подойдет для CI и тестовых окружений из-за полноценной поддержки шаблонизации, возможности получать логи приложения при его непосредственном деплое и смотреть diff между тем, что уже есть в кластере, и планируемыми изменениями.

Полезные ссылки

1. Репозиторий со всем кодом и конфигурацией

2. Документация Helmwave

3. Helmwave на Github