Pull to refresh

Comments 18

Проблема большинства helm чартов в том, что они совершенно нечитаемы. Авторы все делают правильно, ведь для клиента чаще всего важен только файл values.yaml. Но весь вот этот обвяз из include, define и остальной кучи шаблонизации создает мультизлаковую кашу, которую дебажить — одно "удовольствие". Я могу ошибаться, но мне кажется, что такая гибкость в большинстве случаев не нужна, если чарт приватный внутренний. Как по мне, лучше пусть будет один простой и очевидный if else для, допустим, прода и прочих окружений, чем эта вся эта мишура.

Действительно, если к чартам особых требований нет, то лучше держать всё максимально простым. Но если однотипных чартов становится много + сложность каждого отдельного чарта растёт, то в любом случае у тебя получится куча шаблонизации. Просто эта сложность не будет вынесена в include/define'ы, а будет в каждом чарте повторяться снова и снова. Каждый раз реализована по-новому, каждый раз с новыми багами/фичами, и без возможности всё это централизованно править.

Реализация некоторой логики в шаблонах вообще получается слишком сложной, чтобы каждый раз её повторять, поэтому либо выносишь её в «функцию», либо не пишешь вообще и миришься с ограничениями.

В остальном у меня не меньше горит с helm-шаблонов, особенно сложных. Собственно всё это на самом деле для того чтобы упростить работу с ними, а не усложнить.
и без возможности всё это централизованно править.

ну, это не совсем так. sed по пачке репозиториев или search&replace в современных редакторов очень мощны. Настолько, что даже Сысоев рекомендовал в конфигурации nginx писать максимально ясно и развернуто, а не пытаться сворачивать блоки и увеличивать сложность конфета для понимания...

На практике если логика продублирована — в большинстве случаев это значит что она изначально была реализована по-разному (и вероятно разными людьми), а потом ещё и правилась, и тоже по-разному, в разноё время и разными людьми. В итоге начинается дрифт этой логики/конфигурации, и простым sed'ом уже не пройдешься.

Конечно, если логики не много, и пишется она небольшим кол-вом людей, то часто проще дублировать и не париться.
Он это рекомендует, наверное, последние лет 10)

Что хуже — нет каких-то стандартов. Где-то имена образов подставляются как единый параметр, в других же чартах — отдельно репо, отдельно имиджнейм, отдельно тег (и это правильно). Последним подходом, например, пользуется битнами, за что им респект.

Всё так, у всех свои практики складываются, стандартизации нет. При этом подводных в helm-шаблонах полно, поэтому пока выработаешь какие-то действительно работающие лучшие практики, шишек набьешь кучу.

Думал может в отдельной статье поделиться практиками по структуре чартов/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", а внутри это как-то разбивать (по точкам?) на массив и по очереди проверять каждый ключ на существование.
Но всё это довольно чудно и, вероятно, требует прилично логики чтобы все исключения обработать, так что реализовывать не стал.
Поделитесь бест практис, пожалуйста
Если у меня есть несколько сервисов которые могут разворачиваться независимо друг от друга (в разных комбинациях в зависимости от инсталляции), но в целевом варианте интегрируются и работают друг с другом — с точки зрения хелм — это отдельный чарт под каждый микросервис, или один чарт с зависимыми чартами? Какой сервис выбрать основным, а какой зависимым, если нет прямой зависимости?
Или есть третий вариант?

третий вариант — вы никогда в "реальной" среде не будете разворачивать сервисы вместе — а фактически единицей развертывания является реальный один сервис. Убер (амбрелла) чарт в этом случае будет стопором для развертывания, например, нескольких версий одного сервиса для разных окружений или изменения версии одного сервиса, т.к. это ответственность одной команды…


еще раз — один хельм чарт — это одна единица развертывания (=один микросервис). Может быть один продукт (=несколько микросервисов + БД+ еще что-то), но тут думать нужно о границах, чтобы не напороть больше проблем, чем преимуществ

да вот именно эти границы и интересуют — я не имел в виду поднять из чарта что-то огромное — разговор о, например бекенде и фронтенде, который разрабатывается одной командой. просто в зависимости от инсталляции разворачиваться может и бек и фронт, а может только бек. а если еще добавляются ингресс/егресс истио с его конфигами — это отдельные чарты?
если бек и фронт сделать отдельными чартами, а в перспективе может это еще поделится на пяток микросервисов, читай чартов — есть ли какой-то оркестратор чартов?

Ответы на Ваши вопросы


  1. Конфиги инфры (истио объекты, ингрессы, егерем, сетевые политики) — это очевидно неотъемлемая часть чарта приложения или сервиса. Потому что без него они смысла не имеют. Если приложение может быть задеалоено в разные окружения, то через флаги values.yaml вы можете переключать включение или отключение конкретной настройки. Например, нет истио — он в чарты есть, но мы отключаем istio related ресурсы
  2. Оркестратора чартов нет. Это всего лишь способ упаковки приложения и части ресурсов, с ним связанных. Для управления и деплоя можно посмотреть на spinnaker или GitOps тулинги вроде FluxCD (с объектом HelmRelease, реализованным через helm controller) или ArgoCD.
  3. Если чарты сделаны по принципу per microservice, а не per product, тогда опять возвращаемся к идее с umbrella chart, в нем же могут быть описаны инфра штуки из п.1 (что является атрибуцией не самого сервиса, а их совокупности), но мне такой подход, как я уже сказал, не очень нравится.

просто в зависимости от инсталляции разворачиваться может и бек и фронт, а может только бек.

Опять же — values.yaml, в котором мы выбираем комбинацию компонентов (бек и фронт или только бек, или только фронт) и условные блоки в темплейтах

Для сопровождения взаимосвязанной группы чартов можно использовать helmfile
Sign up to leave a comment.