Лучшие ИТ-работодатели 2020
Комментарии
13
Проблема большинства helm чартов в том, что они совершенно нечитаемы. Авторы все делают правильно, ведь для клиента чаще всего важен только файл values.yaml. Но весь вот этот обвяз из include, define и остальной кучи шаблонизации создает мультизлаковую кашу, которую дебажить — одно "удовольствие". Я могу ошибаться, но мне кажется, что такая гибкость в большинстве случаев не нужна, если чарт приватный внутренний. Как по мне, лучше пусть будет один простой и очевидный if else для, допустим, прода и прочих окружений, чем эта вся эта мишура.
Действительно, если к чартам особых требований нет, то лучше держать всё максимально простым. Но если однотипных чартов становится много + сложность каждого отдельного чарта растёт, то в любом случае у тебя получится куча шаблонизации. Просто эта сложность не будет вынесена в include/define'ы, а будет в каждом чарте повторяться снова и снова. Каждый раз реализована по-новому, каждый раз с новыми багами/фичами, и без возможности всё это централизованно править.
Реализация некоторой логики в шаблонах вообще получается слишком сложной, чтобы каждый раз её повторять, поэтому либо выносишь её в «функцию», либо не пишешь вообще и миришься с ограничениями.
В остальном у меня не меньше горит с helm-шаблонов, особенно сложных. Собственно всё это на самом деле для того чтобы упростить работу с ними, а не усложнить.
Реализация некоторой логики в шаблонах вообще получается слишком сложной, чтобы каждый раз её повторять, поэтому либо выносишь её в «функцию», либо не пишешь вообще и миришься с ограничениями.
В остальном у меня не меньше горит с helm-шаблонов, особенно сложных. Собственно всё это на самом деле для того чтобы упростить работу с ними, а не усложнить.
и без возможности всё это централизованно править.
ну, это не совсем так. sed по пачке репозиториев или search&replace в современных редакторов очень мощны. Настолько, что даже Сысоев рекомендовал в конфигурации nginx писать максимально ясно и развернуто, а не пытаться сворачивать блоки и увеличивать сложность конфета для понимания...
На практике если логика продублирована — в большинстве случаев это значит что она изначально была реализована по-разному (и вероятно разными людьми), а потом ещё и правилась, и тоже по-разному, в разноё время и разными людьми. В итоге начинается дрифт этой логики/конфигурации, и простым sed'ом уже не пройдешься.
Конечно, если логики не много, и пишется она небольшим кол-вом людей, то часто проще дублировать и не париться.
Конечно, если логики не много, и пишется она небольшим кол-вом людей, то часто проще дублировать и не париться.
Он это рекомендует, наверное, последние лет 10)
Что хуже — нет каких-то стандартов. Где-то имена образов подставляются как единый параметр, в других же чартах — отдельно репо, отдельно имиджнейм, отдельно тег (и это правильно). Последним подходом, например, пользуется битнами, за что им респект.
Всё так, у всех свои практики складываются, стандартизации нет. При этом подводных в helm-шаблонах полно, поэтому пока выработаешь какие-то действительно работающие лучшие практики, шишек набьешь кучу.
Думал может в отдельной статье поделиться практиками по структуре чартов/values, которые показали себя рабочими по крайней мере у нас, может кому полезно будет.
Думал может в отдельной статье поделиться практиками по структуре чартов/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 использовать.
Найс, разве что только в списке функций в третьем хельме не вижу этого, видимо не завезли в него, но это не точно. Зато в werf должно работать.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Продвинутая Helm-шаблонизация: выжимаем максимум