Packer: шаблонная мета-проблема

если бы упаковщик был написан на python, ответом было бы использование jinja2, который является чрезвычайно мощным и простым в использовании языком шаблонов. Похоже, пару лет назад кто-то попробовал его порт: https://github.com/jmoiron/jigo

Некоторые варианты использования, которые следует рассмотреть. Прямо сейчас у меня есть коллега, который создал программу JS для генерации всех своих конфигураций упаковщика, но логика в этом сценарии JS довольно проста, и было бы неплохо просто хранить все это в одном месте. Ему также нужен отдельный JS-скрипт для каждого целевого json-файла, что является головной болью при обслуживании.

Я оказываюсь в ситуациях, когда мой файл json может выиграть от комментариев, чтобы другие могли его лучше понять. Еще одна вещь, которую я делаю, - это копирование и вставка записей инициатора загрузки файлов, что можно легко решить с помощью конструкции jinja for-loop.

Возможная проблема с jinja2-шаблонами файлов JSON - это проблема с конечной запятой в JSON. Шаблон должен быть достаточно умным, чтобы знать, нужна ли запятая (возможно, имеет смысл переключиться на YAML?).

Другой вариант использования: передача переменных упаковщика (например, builder_type, ...) в скрипты в autounattend (windows) или kickstart / preseed (linux).

Например: vsphere-iso builder использует инструменты vmware для получения IP и перехода к следующему шагу «Ожидание IP». Наличие переменной builder_type (или чего-то вроде переменной env фазы подготовки PACKER_BUILDER_TYPE) позволяет использовать более общий сценарий переключения на пошаговую установку инструментов vmware во время сборки, избегая дублирования кода.

Я думаю, что наличие переменных на более ранних этапах дает большую гибкость и СУХОЙ код.