Comments 18
Проблема большинства helm чартов в том, что они совершенно нечитаемы. Авторы все делают правильно, ведь для клиента чаще всего важен только файл values.yaml. Но весь вот этот обвяз из include, define и остальной кучи шаблонизации создает мультизлаковую кашу, которую дебажить — одно "удовольствие". Я могу ошибаться, но мне кажется, что такая гибкость в большинстве случаев не нужна, если чарт приватный внутренний. Как по мне, лучше пусть будет один простой и очевидный if else для, допустим, прода и прочих окружений, чем эта вся эта мишура.
Реализация некоторой логики в шаблонах вообще получается слишком сложной, чтобы каждый раз её повторять, поэтому либо выносишь её в «функцию», либо не пишешь вообще и миришься с ограничениями.
В остальном у меня не меньше горит с helm-шаблонов, особенно сложных. Собственно всё это на самом деле для того чтобы упростить работу с ними, а не усложнить.
и без возможности всё это централизованно править.
ну, это не совсем так. sed по пачке репозиториев или search&replace в современных редакторов очень мощны. Настолько, что даже Сысоев рекомендовал в конфигурации nginx писать максимально ясно и развернуто, а не пытаться сворачивать блоки и увеличивать сложность конфета для понимания...
Конечно, если логики не много, и пишется она небольшим кол-вом людей, то часто проще дублировать и не париться.
Что хуже — нет каких-то стандартов. Где-то имена образов подставляются как единый параметр, в других же чартах — отдельно репо, отдельно имиджнейм, отдельно тег (и это правильно). Последним подходом, например, пользуется битнами, за что им респект.
Думал может в отдельной статье поделиться практиками по структуре чартов/values, которые показали себя рабочими по крайней мере у нас, может кому полезно будет.
Мне вот не хватает рекурсивной проверки по ключу. Приходится лопатить нечто подобное:
{{ if .Values.key1 }}
{{ if .Values.key1.key2 }}
{{ if .Values.key1.key2.key3 }}
- bla.bla-{{ .Values.key1.key2.key3 }}
{{ end }}
{{ end }}
{{ end }}
Хотелось бы сразу:
{{ if .Values.key1.key2.key3 }}
- bla.bla-{{ .Values.key1.key2.key3 }}
{{ end }}
{{ if .Values.key1.key2.key3 }}
особо то никак и не обернешь в include. Единственный вариант который в голову приходил — это сделать define, в который аргументом пробрасывается строка типа ".Values.key1.key2.key3", а внутри это как-то разбивать (по точкам?) на массив и по очереди проверять каждый ключ на существование.Но всё это довольно чудно и, вероятно, требует прилично логики чтобы все исключения обработать, так что реализовывать не стал.
Функция dig в sprig есть для этого. Если в качестве дефолта поставить пустое значение, то можно в if использовать.
Если у меня есть несколько сервисов которые могут разворачиваться независимо друг от друга (в разных комбинациях в зависимости от инсталляции), но в целевом варианте интегрируются и работают друг с другом — с точки зрения хелм — это отдельный чарт под каждый микросервис, или один чарт с зависимыми чартами? Какой сервис выбрать основным, а какой зависимым, если нет прямой зависимости?
Или есть третий вариант?
третий вариант — вы никогда в "реальной" среде не будете разворачивать сервисы вместе — а фактически единицей развертывания является реальный один сервис. Убер (амбрелла) чарт в этом случае будет стопором для развертывания, например, нескольких версий одного сервиса для разных окружений или изменения версии одного сервиса, т.к. это ответственность одной команды…
еще раз — один хельм чарт — это одна единица развертывания (=один микросервис). Может быть один продукт (=несколько микросервисов + БД+ еще что-то), но тут думать нужно о границах, чтобы не напороть больше проблем, чем преимуществ
если бек и фронт сделать отдельными чартами, а в перспективе может это еще поделится на пяток микросервисов, читай чартов — есть ли какой-то оркестратор чартов?
Ответы на Ваши вопросы
- Конфиги инфры (истио объекты, ингрессы, егерем, сетевые политики) — это очевидно неотъемлемая часть чарта приложения или сервиса. Потому что без него они смысла не имеют. Если приложение может быть задеалоено в разные окружения, то через флаги values.yaml вы можете переключать включение или отключение конкретной настройки. Например, нет истио — он в чарты есть, но мы отключаем istio related ресурсы
- Оркестратора чартов нет. Это всего лишь способ упаковки приложения и части ресурсов, с ним связанных. Для управления и деплоя можно посмотреть на spinnaker или GitOps тулинги вроде FluxCD (с объектом HelmRelease, реализованным через helm controller) или ArgoCD.
- Если чарты сделаны по принципу per microservice, а не per product, тогда опять возвращаемся к идее с umbrella chart, в нем же могут быть описаны инфра штуки из п.1 (что является атрибуцией не самого сервиса, а их совокупности), но мне такой подход, как я уже сказал, не очень нравится.
просто в зависимости от инсталляции разворачиваться может и бек и фронт, а может только бек.
Опять же — values.yaml, в котором мы выбираем комбинацию компонентов (бек и фронт или только бек, или только фронт) и условные блоки в темплейтах
Продвинутая Helm-шаблонизация: выжимаем максимум