Issues about wanting some kind of templating are opened frequently. This would be replacing variables inside static files with information from packer either during the file provisioner or inside floppy_files or the http_server
Here are some examples:
- https://github.com/mitchellh/packer/issues/3961
- https://github.com/mitchellh/packer/issues/1673
- https://github.com/mitchellh/packer/issues/2867
- https://github.com/mitchellh/packer/issues/4451
I don't believe packer should be in the business of providing templating, as it's out of scope of packer in my opinion. However, it does seem to be requested often.
I'd like to discuss here possible solutions, but right now I don't have any.
mwhooker
All 3 comments
if packer was written in python, the answer would be to use jinja2, which is an extremely powerful and easy-to-use templating language. Looks like someone tried a go port of it a couple years ago: https://github.com/jmoiron/jigo
WeatherGod
on 14 Feb 2017
Some usecases to consider. Right now, I have a colleague who made a JS program to generate all of his packer configs, but the logic in that JS script is fairly straight-forward, and would be nice to simply keep all of that in one place. He also needs a separate JS script for each target json file, which is a maintenance headache.
I find myself in situations where my json file could benefit from comments so that others can understand it better. Another thing I find myself doing is copying-n-pasting file upload provisioner entries which could easily be solved with a jinja for-loop construct.
A possible problem with jinja2 templating of JSON files is the trailing comma problem with JSON. The templating would have to be smart enough to know whether or not a comma is needed (perhaps it would make sense to switch to YAML?).
WeatherGod
on 14 Feb 2017
Another use case: passing packer variables (like builder_type, ...) to scripts in autounattend (windows) or kickstart/preseed (linux).
E.g.: vsphere-iso builder uses vmware tools to get IP and go next "Waiting for IP" step. Having builder_type variable (or something like provisioning phase PACKER_BUILDER_TYPE env variable) allow to use more generic script switching to step installing vmware tools at build time, avoiding code duplication.
I think having variables at earlier stages allow more flexibility and DRY code.
Roxyrob
on 29 Apr 2020
Related issues
sourav82
·
3Comments
Tensho
·
3Comments
jesse-c
·
3Comments
shantanugadgil
·
3Comments
tleyden
·
3Comments
Most helpful comment
Some usecases to consider. Right now, I have a colleague who made a JS program to generate all of his packer configs, but the logic in that JS script is fairly straight-forward, and would be nice to simply keep all of that in one place. He also needs a separate JS script for each target json file, which is a maintenance headache.
I find myself in situations where my json file could benefit from comments so that others can understand it better. Another thing I find myself doing is copying-n-pasting file upload provisioner entries which could easily be solved with a jinja for-loop construct.
A possible problem with jinja2 templating of JSON files is the trailing comma problem with JSON. The templating would have to be smart enough to know whether or not a comma is needed (perhaps it would make sense to switch to YAML?).