Creating vSphere VM templates with Packer (part 3) - Variables, builders and provisioners
In part 3 of this series I cover some of the configuration and terminology required to get going with builds and that will be used in the rest of the series.
Having covered my environment and preparation in the previous post, it's time to start digging in to the different pieces that make up a Packer build.
The word "template" means something different in Packer-speak. For Packer, a template is a JSON file that defines one or more builds that are made up of the various components within Packer. Those components are: variables; builders; provisioners; post-processors. I didn't spend any time on post-processors and so I'm not going to cover them here.
The minimum required is a template file. For example:
packer build template.json (this would build a machine based on the definition in the template.json file
Variables
Variables are just like in any other scripting language. They're a memory location that contains a piece of data (or an array of data items). Except that in a Packer build it's maybe more accurate to think of them as constants. They can be set but are not changed during Packer build execution.
Variables can be defined either on the command line at request time, defined in the template file or separately in a variable file (also JSON) that is supplied alongside the request. For example:
- packer build -var 'var_name=foo' template.json (this adds the variable "var_name" with value "foo" to the build execution)
- packer build -var-file=variables.json template.json (this adds all of the variables in variables.json to the build execution)
It's also possible to define variables within the template file itself.
Builders
Builders can be thought of as plugins perhaps. They are the components that interface with the likes of Vagrant, vSphere, AWS, Azure etc to build machines. A Packer template can contain multiple builder definitions. Each definition can use a different builder or the same one. And each definition maps exactly to one machine and one machine only.
Packer comes with a number of built-in builders and can be extended with more if needed.
Most builders need to be associated with a communicator. These communicators (usually SSH or WinRM) are used to communicate with the provisioned machine or the underlying platform that it's on. The vsphere-iso builder requires the use of either the SSH or WinRM communicator.
Provisioners
Provisioners are built-in or third-party software / scripts that are used to configure the machine images after they first boot. Often used provisioners include "shell" and "powershell". They can be used to execute commands on the provisioned machine or scripts local to where Packer is being executed.
I mentioned another (third-party) provisioner in my previous post. That one manages the installation of Windows updates, which I've found to be much more effective than any script that I can craft.
So, those are the pieces of the puzzle that I'll be describing in the next few posts. In part 4 I'll go in to the vSphere variables used in the vsphere-iso builder. There will be some actual code in there!!!
Other posts in this series:
- Introduction
- Configuring Packer server and required files
- Variables, builders and provisioners <-- $this
- vSphere variables
- Windows Server templates
- CentOS templates
- Further plans (including scheduling packer)
My public Packer repository:
mpoore