Masalah tentang menginginkan semacam templating sering dibuka. Ini akan menggantikan variabel di dalam file statis dengan informasi dari packer baik selama penyedia file atau di dalam floppy_files atau http_server
Berikut beberapa contohnya:
- 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
Saya tidak percaya packer harus berada dalam bisnis menyediakan templating, karena menurut saya itu di luar cakupan packer. Namun, sepertinya itu sering diminta.
Saya ingin membahas di sini solusi yang mungkin, tetapi saat ini saya tidak punya.
mwhooker
Semua 3 komentar
jika packer ditulis dengan python, jawabannya adalah menggunakan jinja2, yang merupakan bahasa templating yang sangat kuat dan mudah digunakan. Sepertinya seseorang mencoba port go beberapa tahun yang lalu: https://github.com/jmoiron/jigo
WeatherGod
pada 14 Feb 2017
Beberapa usecase untuk dipertimbangkan. Saat ini, saya memiliki seorang rekan yang membuat program JS untuk menghasilkan semua konfigurasi pengepakannya, tetapi logika dalam skrip JS itu cukup mudah, dan akan menyenangkan untuk menyimpan semua itu di satu tempat. Dia juga membutuhkan skrip JS terpisah untuk setiap file json target, yang merupakan masalah pemeliharaan.
Saya menemukan diri saya dalam situasi di mana file json saya dapat mengambil manfaat dari komentar sehingga orang lain dapat memahaminya dengan lebih baik. Hal lain yang saya lakukan adalah menyalin-n-menempel entri penyedia unggahan file yang dapat dengan mudah diselesaikan dengan konstruksi jinja for-loop.
Kemungkinan masalah dengan templating jinja2 dari file JSON adalah masalah koma yang tertinggal dengan JSON. Templat harus cukup pintar untuk mengetahui apakah koma diperlukan atau tidak (mungkin masuk akal untuk beralih ke YAML?).
WeatherGod
pada 14 Feb 2017
Kasus penggunaan lain: meneruskan variabel pengepak (seperti builder_type, ...) ke skrip di autounattend (windows) atau kickstart/preseed (linux).
Misalnya: pembuat vsphere-iso menggunakan alat vmware untuk mendapatkan IP dan melanjutkan langkah "Menunggu IP". Memiliki variabel builder_type (atau sesuatu seperti fase penyediaan variabel env PACKER_BUILDER_TYPE) memungkinkan untuk menggunakan peralihan skrip yang lebih umum ke langkah menginstal alat vmware pada waktu pembuatan, menghindari duplikasi kode.
Saya pikir memiliki variabel pada tahap awal memungkinkan lebih banyak fleksibilitas dan kode KERING.
Roxyrob
pada 29 Apr 2020
Masalah terkait
Tensho
·
3Komentar
paulcdejean
·
3Komentar
mvermaes
·
3Komentar
tleyden
·
3Komentar
wduncanfraser
·
3Komentar
Komentar yang paling membantu
Beberapa usecase untuk dipertimbangkan. Saat ini, saya memiliki seorang rekan yang membuat program JS untuk menghasilkan semua konfigurasi pengepakannya, tetapi logika dalam skrip JS itu cukup mudah, dan akan menyenangkan untuk menyimpan semua itu di satu tempat. Dia juga membutuhkan skrip JS terpisah untuk setiap file json target, yang merupakan masalah pemeliharaan.
Saya menemukan diri saya dalam situasi di mana file json saya dapat mengambil manfaat dari komentar sehingga orang lain dapat memahaminya dengan lebih baik. Hal lain yang saya lakukan adalah menyalin-n-menempel entri penyedia unggahan file yang dapat dengan mudah diselesaikan dengan konstruksi jinja for-loop.
Kemungkinan masalah dengan templating jinja2 dari file JSON adalah masalah koma yang tertinggal dengan JSON. Templat harus cukup pintar untuk mengetahui apakah koma diperlukan atau tidak (mungkin masuk akal untuk beralih ke YAML?).