Комментарии 13

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

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

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

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

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

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

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

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

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