Изначально werf — инструмент для сборки контейнеров и деплоя в Kubernetes — был построен на основе нашего форка Helm 3. Со временем этот форк оброс значительным количеством новых возможностей и исправлений по сравнению с оригинальным Helm 3. Но некоторых пользователей werf интересовало только развёртывание, без сборки образов и остальной функциональности.
Специально для таких пользователей мы даже поддерживали команды werf helm …, которые предоставляли прямой доступ к нашему форку Helm 3. По мере усложнения подсистемы развёртывания werf мы решили выделить её в отдельный проект Nelm, который запустили в конце декабря 2023 года. И вот теперь, с выходом Nelm CLI, Nelm достиг важной вехи — версии 1.0!
Что такое Nelm
Nelm — это Open Source CLI-утилита для управления Helm-чартами и их развёртыванием в Kubernetes. Взяв за основу кодовую базу Helm 3, Nelm не только делает почти все то, что может делать Helm, но делает это лучше, а также предлагает дополнительную функциональность. Nelm обратно совместим с Helm-чартами и Helm-релизами, что сильно упрощает процесс миграции для пользователей Helm. Если вы уже работали с werf, то Nelm — это werf, но без гитерминизма, сборки, доставки и очистки образов.
Давайте подробнее рассмотрим преимущества Nelm по сравнению с Helm 3.
Продвинутое управление порядком развёртывания ресурсов
Начать стоит с того, что подсистема развёртывания, унаследованная от Helm, в Nelm была переписана с нуля. В процессе развёртывания Nelm формирует направленный ациклический граф (Directed Acyclic Graph, DAG), включающий все операции, которые предполагается выполнить в кластере при релизе, после чего те выполняются. Направленный ациклический граф позволил реализовать продвинутое управление порядком развёртывания ресурсов:
Аннотация
werf.io/weight: похожа наhelm.sh/hook-weight, но работает не только для хуков, но и для обычных ресурсов; ресурсы с одинаковым весом деплоятся параллельно.Аннотация
werf.io/deploy-dependency-<id>: позволяет дождаться готовности другого ресурса (или просто убедиться в его наличии в кластере) перед деплоем аннотированного ресурса. Это наиболее гибкий и эффективный метод управления порядком развёртывания в Nelm.Аннотация
<id>.external-dependency.werf.io/resource: позволяет дождаться готовности внешних ресурсов (не из текущего релиза), например созданных сторонними операторами.Стандартные механизмы управления порядком в Helm (хуки и их веса) также поддерживаются.
Server-Side Apply заменил 3-Way Merge
В Nelm Server-Side Apply заменил проблемный Helm 3-Way Merge.
3-Way Merge (3WM) — это механизм, работающий на стороне клиента, который создаёт патч для обновления ресурса в кластере. Главная его проблема в том, что он исходит из предположения, что все манифесты из предыдущего релиза успешно применились в кластере. Но так бывает не всегда!
Например, какие-то ресурсы могли не обновиться, потому что были некорректными или потому что релиз прервался раньше времени. Тогда при следующем запуске 3WM может создать неправильный патч. В итоге Helm-релиз выглядит как успешный, но на деле в кластер незаметно применились некорректные изменения, что является серьёзной проблемой.
Не так давно в Kubernetes появился новый механизм обновления ресурсов — Server-Side Apply. Суть SSA в том, что патчи создаются на стороне сервера, в Kubernetes, а не на стороне клиента, как в Helm. SSA решает проблемы 3WM, и его уже используют многие другие инструменты для деплоя, например Flux.
Увы, заменить 3WM на SSA в самом Helm очень непросто. Но так как в Nelm движок развёртывания был переписан с нуля, мы с самого начала разрабатывали его под SSA, что позволило решить застарелые проблемы 3-Way Merge.
Отслеживание состояния ресурсов
Nelm включает мощную систему отслеживания ресурсов, созданную с нуля:
Надёжное определение готовности, наличия, отсутствия или ошибок ресурсов.
Готовность Custom Resources определяется эвристически по status-полям (работает примерно для половины CR, без ложных срабатываний).
Зависимые ресурсы (например, поды у Deployment'ов) обнаруживаются автоматически и отслеживаются отдельно.
В процессе деплоя периодически выводится таблица с текущим состоянием отслеживаемых ресурсов (статусы, ошибки и т. д.).
Параметры отслеживания можно настроить отдельно для каждого ресурса через аннотации.
Вывод логов и событий в процессе развёртывания
Во время деплоя Nelm находит поды развёртываемых ресурсов релиза и периодически выводит логи их контейнеров в консоль. Кроме того, аннотация werf.io/show-service-messages: "true" позволяет выводить и события ресурсов. Вывод логов и событий можно настроить с помощью аннотаций.
Зашифрованные values и зашифрованные файлы
Набор команд nelm chart secret предназначен для управления values-файлами, такими как secret-values.yaml, а также произвольными зашифрованными файлами (например, secret/mysecret.txt). Оба типа файлов расшифровываются в памяти на этапе шаблонизации. Доступ к данным из них в шаблонах осуществляется через .Values.my.secret.value для values-файлов и через вызов функции {{ werf_secret_file "mysecret.txt" }} для произвольных файлов.
Планирование релизов
Команда nelm release plan install генерирует детальный план предстоящих изменений в кластере при следующем релизе. Она выводит точные diff'ы между текущей конфигурацией ресурсов в кластере и их ожидаемым состоянием после развёртывания. Точность достигается за счёт использования Server-Side Apply в холостом (dry-run) режиме, в отличие от других, менее надёжных методов на стороне клиента.
Планы на будущее
А теперь несколько слов о наших планах. Мы намерены:
реализовать альтернативу шаблонизации Helm;
добавить возможность загрузки чартов напрямую из Git;
реализовать публичный Go API для встраивания Nelm в стороннее ПО;
улучшить опыт работы с CLI, добавив новые команды, и реимплементировать некоторые старые Helm-команды, которые мы пока используем без изменений;
полностью переработать управление зависимостями чартов;
мигрировать встроенные секреты на Mozilla SOPS.
Как попробовать
Установите Nelm и следуйте инструкциям из руководства по быстрому началу работы. Нам важно ваше мнение — пожалуйста, поделитесь им в комментариях!