Packer variables
This blog entry will demonstrate how to use variables inside Packer Template file.
In the previous post we’ve build our first vSphere Windows image using Packer. Today I will show you how to use variables inside Packer template file.
Packer variables
Packer variables allow you re-use same Packer template file multiple times within different vSphere environments. If we would hardcode all settings inside template file, like we did in my previous post, we would then have to create Packer template file for each vSphere instance. You will probably agree that this is not very efficient as we need change only few settings inside existing template file , mostly for vCenter server objects, to re-use it within different environment..
My assumption is that you want to build your images across different vCenter instances. Even with single vCenter instance variables can be quite helpful as you could use same template file to build Windows Server 2016 and Windows Server 2019.
Since we want to fully automate image build process using Azure DevOps, it’s advised to use variables for security and flexibility reasons.
Define variable inside template file
To define variables we need to first define variables section inside Packer template file. Variable naming convention is up to you, but I suggestto use names that are self explanatory. Also do not use spaces naming your variables.
Below is an example how to define variable section:
|
|
In this example we want to set three variables for vCenter server name, vCenter username and vCenter password. Next we need to define those variables inside Packer template file:
|
|
Define variable values
To define values for our variables we need to create dedicated variable file. Same as Packer template file, variable file is stored in JSON format. You can use random naming convention, but for simplicity, let’s name our file vars.json and store it in same directory as Packer template file. Variable file should look like this:
|
|
Which values should you store as variable?
Packer is very flexible and allow to store each option in template file as variable. This is very handy. For example, you can store patch to you answer file as variable, place answer files in dedicated directories and point Packer to proper answer file depending which OS you want to create. From the other hand I don’t see the point of storing options like CPU number or amount of memory as variable. Basically those values are not important as, at the end, we change those values during provision process based on system/user requirements. So what values should be stored as variable? From my experience those should be:
| Variable | Description |
|---|---|
| vsphere_server | Stores vCenter server name. |
| vsphere_user | Stores vCenter username. |
| vsphere_password | vSphere password for account that has required permissions to create images. |
| vsphere_folder | Stores vCenter Folder path where our image will be placed. |
| vsphere_dc_name | Stores vCenter datacenter name. |
| vsphere_cluster | Stores vCenter cluster name where our image will be placed. |
| vsphere_host | Stores ESXi host name where our image will be placed |
| vsphere_portgroup_name | Stores vCenter portgroup name where our image will be connected to. |
| vsphere_datastore | Store vCenter datastore name where our image will be deployed. |
| winadmin_password | Windows password used by WinRM to connect with image to perform customization. |
| os_iso_path | Path to datastore where Windows installation media is placed. |
| vmtools_iso_path | Path to datastore where VMware Tools installation media is placed. |
| autounattend_path | Path to autounattend.xml answer file. |
| template_name | Image name that we want to apply on the image. |
| version | VM hardware version that we want to apply on our image. |
You may wonder why we need to put so many variables into single template file? Well - because each vSphere environment can be different. You may have vSphere 6 and 6.7 that you manage so for each environment image hardware version can be different etc. It will make more sense later on once we start build our images fully automatically, trust me.
Ok, but why I have specified “vsphere_host” since “vSphere _cluster” has been set as variable? The thing is that account that we specified and assigned through terraform, provides permissions on cluster level without propagation. We assign sufficient permissions on host level to better secure our environment.
At the end you should get one additional file inside your folder and all listed variables should be offloaded from your template file.
Under 03 - Packer variables folder you will find working set of files with offloaded variable files. You can simply place your sensitive values inside vars.json file and run: packer build -var-file=".\vars.json" windows-server-2016.json command once you are in directory with your template file.
This command will tell Packer to use vars.json as variable file and windows-server-2016.json as main template file.
|
|
Variables inside Windows answer file
You are probably wonder if variables can be used inside answer file to re-use autounattend.xml file with different Windows versions? Autounattend.xml does not support variables natively, but with help of Azure DevOps third party tools we can bypass variables into autounattend.xml as well. This will be demonstrated in later posts once we will start to create our images using Azure DevOps.
In next blog we will tweak our image using provisioners and post-processors.
Thanks for reading!