Для деплоя приложений в Kubernetes существует огромное количество различных инструментов. Если посмотреть на соответствующий раздел в CNCF Landscape, то можно потеряться в разнообразии. Поэтому иногда хорошо иметь в своем арсенале «серебряную пулю», которая подойдет для большинства задач. Helmwave вполне может стать именно таким инструментом. В последнее время моим самым любимым инструментом для описания декларативных деплоев в Kubernetes был Helmfile. Три неочевидные, но полезные возможности Helmfile я рассмотрела в отдельной статье на Medium: “3 Helmfile features you don’t know”.  Фичи Helmfile, которые важно отметить: Встроенная возможность шаблонизации. Окружения с возможностью указать дефолтную конфигурацию. Интеграция с HashiCorp Vault, AWS KMS и другими инструментами для работы с секретами. Поддержка плагина helm diff. Несмотря на то что GitOps и инструменты, которые реализуют этот подход, сейчас на пике популярности, к ним есть много вопросов с точки зрения надежности, управляемости и наблюдаемости. Поэтому я всегда слежу за новыми проектами: они могут оказаться проще в использовании или лучше справляться с решением конкретных проблем. Так я и нашла Helmwave. Readme проекта на Github довольно емко и кратко описывает основную задачу проекта: Helmwave — это docker-compose для @helm. Helmwave — это инструмент для декларативного описания деплоя helm-чартов.  Давайте разберемся, чем он лучше или хуже конкурентов. В Helmwave есть все необходимые стандартные фичи: everything-as-code, деплой в несколько окружений и возможность настройки дефолтной конфигурации.  Но есть и несколько неочевидных: Пошаговый деплой (depends_on, allow_failure). Отслеживание ресурсов Kubernetes в реальном времени при помощи kubedog. Отсутствие внешних зависимостей: достаточно скачать бинарный файл helmwave и можно начинать деплой. Для примера я попробую решить стандартную задачу: настроить деплой в несколько окружений из одного репозитория с возможностью оверрайда конфигурации. Для начала рассмотрим структуру проекта: В директории .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. Последняя версия — 0.19.5. В этом файле мы можем использовать якорь с параметрами по умолчанию (.options) и указать его в разделе releases, когда это необходимо. Таким образом мы получим максимально DRY-конфиг. Обычно в этом месте задается ряд значений по умолчанию: namespace, helm options и т.д. Полный список параметров ищите в документации. В разделе releases задается список релизов helm, которые нужно задеплоить. Этот список можно найти в файле releases.yaml. Каждому релизу нужно задать имя и чарт, из которого должен осуществляться деплой. Другие параметры опциональны.  Каждый релиз также содержит: Переменные для нужного окружения, окружение задается переменной CI_ENVIRONMENT_NAME. Тег с названием приложения, который можно использовать для фильтрации деплоя конкретных сервисов. Параметры из якоря, добавляемые через  << : *options. Структура releases.yaml не требует дополнительных пояснений: В этом файле будет находится отрендеренный шаблон helmwave.yml.tpl. Чтобы его сгенерировать, можно выполнить следующую команду: Для реализации CI/CD я выбрала GitHub Actions, потому что они бесплатно доступны в GitHub. Более того, разработчики Helmwave сделали для них action, который помогает быстро и удобно использовать различные версии Helmwave в пайплайнах. Процесс деплоя состоит из трех шагов: подготовка, запуск тестов и запуск деплоя в выбранном окружении.  На этапе подготовки устанавливаем необходимые инструменты — Helmwave и kind, который создаст Kubernetes кластер с помощью контейнеров. Далее в зависимости от значения CI_ENVIRONMENT_NAME подготавливаем план изменений с помощью helmwave. Чтобы определить окружение, можно написать bash-скрипт или использовать возможности выбранной CI/CD платформы. Пример для Github Actions: Для тестирования и деплоя нам необходимо отрендерить helm-charts в готовые Kubernetes манифесты. Для этого нужно выполнить одну из следующих команд: Эти команды создают директорию .helmwave, где содержатся необходимые манифесты и план. Для тестирования я использую самые популярные инструменты: kube-linter kubeval pluto Они похожи, но каждый имеет свои особенности реализации и тестируемые кейсы, поэтому я решила использовать все три в одном пайплайне. На этом этапе можно использовать ту же команду, что и для генерации плана. Но если деплой выполняется во временной среде (как в моем случае), нужно задать дополнительный параметр diff-mode=local, который будет рендерить diff изменений локально, не отправляя запросы в кластер Kubernetes. Такой вариант также подходит для использования в CI. Чтобы развернуть приложение, выполните следующую команду: Чтобы удалить все созданные  ресурсы, нужно выполнить одну из следующих команд: Helmwave — это полноценная альтернатива helmfile и другим похожим инструментам. Несмотря на то что проект достаточно молодой, у него есть полезные и неочевидные функции, и я с интересом буду смотреть за его развитием. От себя могу рекомендовать использовать его в ситуации, когда вам нужно быстро настроить деплой приложения и иметь возможность наблюдать за процессом деплоя в режиме реального времени. Также helmwave хорошо подойдет для CI и тестовых окружений из-за полноценной поддержки шаблонизации, возможности получать логи приложения при его непосредственном деплое и смотреть diff между тем, что уже есть в кластере, и планируемыми изменениями. Репозиторий со всем кодом и конфигурацией Документация Helmwave Helmwave на Github  DevOps engineer