Комментарии 14
Я в свое время написал 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 микросервиса и база для них, нужно при каждом релизе запускать джобу, которая тушит один микросервис (скалирует в ноль), проверяет базу на миграции (и вкатывает, если приехали новые), потом скалирует сервис на заданное в чарте значение и применяет все остальное.
Практическое руководство по созданию Helm чарта или как избавиться от рутины при работе с YAML манифестами