[Перевод] Как перейти с монорепозитория Helm на версионированные чарты12.06.2024 13:15

80cb57f3d0cb5ea54af60f9d5ae01f95.png

Предыстория

В Альтенаре много лет был монорепозиторий хелма, где лежали все чарты компонентов и library чарт.

Выглядело это примерно так: 

.
├── project_1
├── ...
├── project_x
└── library
    ├── Chart.yaml
    └── templates

Работает такой вариант очень просто — вы держите в мастер ветке только актуальные чарты, они не версионируются и все имеют одну версию чарта `0.1.0`.

Все чарты имеют в зависимостях library чарт, по локальному пути: 

# component/Chart.yaml
dependencies:
-  name: library
   version: 0.1.1
   repository: file://../library

А в templates содержат просто инклюды нужных темплейтов из библиотеки: 

# component/templates/deployment.yaml
{{- include "templates.deployment" . -}}

В самой библиотеке есть много разных шаблонов, например деплойменты, сервисы и прочие кронджобы. Пример этот мы взяли изначально отсюда https://faun.pub/dry-helm-charts-for-micro-services-db3a1d6ecb80 (вероятно потому что в документации хелма раньше было меньше примеров)

В CI пайплайне на агенте скачивается репозиторий и упаковывается в артефакт, который версионируется и передается в CD пайп.

Затем в CD части выполняются несколько bash команд, примерно таких: 

$ cd component
$ helm dependency update .
$ helm upgrade --install component -f values.yaml .

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

Это успешно работало много лет, но всегда есть что улучшить.

Некоторое время назад мы производили работы с флакс монорепой (можно почитать в прошлой статье) и в одном из новых проектов появилась идея использовать флаксовые объекты HelmRelease для деплоя наших компонентов.

На самом деле, это не просто блажь, а дальше мы планируем разработать оператор для управления логически связанными компонентами, где один из вариантов это как раз использование HelmRelease объектов, но об этом будет уже в другой статье.

И пришла пора начать собирать наконец-то чарты с версионированием и хранить их в своём реджистри, так как для этих объектов нужны нормальные версионированные чарты.

Почему версионированные чарты лучше

  1. Dependencies: Версионирование позволяет точно указывать, какая версия библиотеки нужна для работы конкретного чарта. А их может быть и больше одной.

  2. Stability: Обновления или изменения в библиотеке не затронут текущие конфигурации. Если чарт успешно живет на старой версии либы — не надо ничего дополнительно делать, semver успешно сигнализирует о несовместимых изменениях.

  3. Reuse: Можно повторно использовать старые версии чартов, что позволяет гарантировать одинаковое состояние в разных средах.

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

  5. Changelog: И если вы приучили друг друга читать изменения в версиях — вы знаете, что поменялось в чарте\либе

В общем, использование версионирования улучшает управляемость, надежность и предсказуемость деплоя чартов.

И еще один момент. Для HelmRelease объектов нам необходимы уже собранные и доступные из реджистри чарты. Подробнее тут https://fluxcd.io/flux/components/source/helmcharts/#version

А если не указывать версию и тащить всегда latest, то вы и сами знаете, чем это закончится. Если не знаете, почитайте этот опус про антипаттерны (там про докер образы, но смысл тот же) https://habr.com/ru/companies/timeweb/articles/557320/

Чтобы обкатать неизвестный на практике подход, я поигрался с демкой и решил оформить её в два репозитория, которые демонстрируют и помогут повторить мой путь.

Подготовка library chart

В моём случае у меня есть практически готовая библиотека, но надо было понять, как её собирать, версионировать и загружать в какой-то реджистри.

Для опытов с OCI реджистри я выбрал quay.io и гитхаб для хранения кода.

За основу кода взял официальные примеры

Все команды подробно описаны в репозитории demo-helm-library

В двух словах — вам надо создать свой реджистри, залогиниться в нем хелмом

helm registry login -u $QUAY_USERNAME -p $QUAY_PASSWD_ENCRYPTED quay.io

Затем упаковать чарт и запушить его в реджистри

helm package .
helm push demo-library-0.1.1.tgz oci://quay.io/$QUAY_USERNAME/test-helm

После этого у вас будет library chart, загруженный на ваш реджистри.

Использование library chart в других чартах

Тут всё ещё проще, надо добавить в ваш чарт библиотеку как зависимость

dependencies:
- name: demo-library
  version: 0.1.1
  repository: oci://quay.io/greengrunt/test-helm

Затем построить эти зависимости, собрать и запушить чарт в реджистри

helm dependency update .
helm package .
helm push demo-chart-0.1.0.tgz oci://quay.io/$QUAY_USERNAME/test-helm

Всё также подробно расписано в другом репозитории demo-helm-chart

© Habrahabr.ru