Комментарии 17
Я в свое время написал 100+ чартов и сейчас считаю, что Хелм это зло. Он приносит кучу добавленной сложности в замен так называемых "релизов" которые, как правило, оказываются сломаны в тот момент, когда они особенно нужны, например, когда надо срочно чинить прод. Мы года 4 назад перешли на kustomize и с тех пор забыли про Хелм как про страшный сон, чего и вам желаю.
Добрый вечер! По поводу опции в голосовании вы правы - упустил этот момент, но уже поздно(
Пока Helm кажется идеальным решением, чтобы облегчить возню с деплоем приложении. Это открывает большие возможности - сейчас у нас десяток микросервисов и для каждого своя папка с YAML манифестами, с хелмом получится удалить все эти манифесты и обойтись одной командой helm install, только лишь изменив некоторые значения параметром --set. С kustomize признаюсь почти не работал, единственное для чего пытался его использовать, так это для создания секрета со значениями из .env файлика, но впоследствии отказался от этого. В любом случае, спасибо за совет, но я пока остановлюсь на Helm :)
Кастомайз всё же лучше как мне кажется, попробуйте!
- Делаете для ci шаблон делоя, сервиса, конфиг-мапы и тд.
- Дальше в зафисимости от среды деплоя(можно папками разделить) главный(например dev). В нем описываете откуда секреты тянуть и тд.
- Делаете папки с наименованиями стендов
- Делаете там kustomization.yml и переопределяете то что нужно и отличается от dev
В целом по основному всё :)
Есть моменты, не спорю, когда helm может порешать. Но я их вижу только в рамках официальных чартов того же vault, например.
Подскажите, пожалуйста, один момент на Вашем опыте. Я для себя открыл helm, когда столкнулся с необходимостью параметризовать манифесты в CI/CD. Конкретнее, в случае, когда я хотел деплоить приложения на dev и prod окружения. Я использовал values.yaml, чтобы указать там имя секрета, доменное имя для ingress и прочие вещи, которые могут различаться в разных окружениях.
Я согласен с вашим мнением про добавленную сложность, но как тогда решить проблему, когда тебе действительно нужна параметризация?
тут есть два варината:
1) можно при вызове helm указывать флаги --set ingress.baseHost=example.domain
2) держать 2 values.yaml по типу values-dev.yaml и values-prod.yaml, указывая также при вызове helm какой файлик вы хотите использовать helm -f values-dev.yaml
Спасибо за ответ) Я как раз так и делал.
Я хотел поинтересоваться у автора комментария, как он в случае с Kustomize решает такую же проблему, если вообще с ней сталкивается
В kustomize есть такая вещь, как слои.
Обычно делают базовый слой, где лежит не параметризованный набор манифестов и оверлеи, которые ссылаются на базовый слой как родительский и в которых накладываются патчи с конкретными значениями, которые нужно поменять для окружений. Вот годная статья от Фланта https://habr.com/ru/companies/flant/articles/469179/
Кастомайз идеальный, если у тебя 2-4 слоя. А если у тебя один продукт и 120 клиентов (читай слоев). В продукте десяток микросервисов, и кучу параметров в них, которые меняются в зависимости от клиента.
И тут тебе надо добавить в паре микрух новые переменные.. управление таким кодом становится адовым..
Тут один Хельм и 120 x-values.yaml рядом редактировать на порядок проще.
В голосовании не хватает опции "использую только для сторонних чартов. Многие вендоров распространяют свое ПО только в виде чартов.
Как бы решали вопрос с миграциями в базу ?
Есть 3-4 микросервиса и база для них, нужно при каждом релизе запускать джобу, которая тушит один микросервис (скалирует в ноль), проверяет базу на миграции (и вкатывает, если приехали новые), потом скалирует сервис на заданное в чарте значение и применяет все остальное.
Скопируем манифесты из kubectl и перенесем в папку templates:
копировать - вставить
1. откуда берутся значения {{ .Release.Name }} и {{ .Release.Namespace }}? Почему на выходе получилось не spring-app а test-app?
2. как Вы заполняете значения DB_USER, DB_PASSWORD и пр.?
1) .Release.Name и .Release.Namespace - это встроенные переменные, когда вы деплоите чарт, указываете название и неймспейс релиза:
helm install \
-n nginx-helm \
nginx ./helm-chart
В таком случае .Release.Name=nginx, а .Release.Namespace=nginx-helm
2) В конкретной статье - через интеграцию Yandex Lockbox с Kubernetes Secrets. Можно вручную создать секрет через kubectl create или же использовать другую систему управления секретами, например Vault
Практическое руководство по созданию Helm чарта или как избавиться от рутины при работе с YAML манифестами