The majority of organizations are not going to use one specific provider to host their systems. Whether it be VMware on-premises, Azure in the cloud, AWS, or Hyper-V, most will be operating on more than one.
In the world of automation, ideally you want to have the ability to build machine images the same way, regardless of what provider they will run on. This is where the tool Packer, a wonderful open-sourced Hashicorp tool can help. With Packer, you can build machine images with the same tool, and then when it’s time to spit out an artifact of that image, you can do so to whatever platform you want and in parallel.
How does it work?
First, you can install and use Packer on all major operating systems (Linux, Windows, Mac). The main configuration for your machine images is in a JSON file which is referred to as a template.
Inside a template, there are three main sections: builders, provisioners and post-processors. The latter two are optional. You can have multiple “builders” sections that specify configurations for platforms, for instance, one for Virtualbox and one for Hyper-V. You can also specify multiple provisioners, which are meant mainly for installing software on your images. Of course you can have multiple post-processors as well performing actions on your image artifacts after a build is complete.
Inside a Packer template you can set things such as VM resources (CPU, memory), communicator settings (OpenSSH, WinRM), variables, and scripts. Since Packer is a CLI driven software, it is very agile.
Builders
Builders allow Packer to generate machine images for a specific platform, like Virtualbox or Azure. Within a given template you can specify multiple builders and have them spin up in parallel. For instance, this is a basic builder configuration for Virtualbox straight from the Packer website:
{
"type": "virtualbox-iso",
"guest_os_type": "Ubuntu_64",
"iso_url": "./Ubuntu.ISO",
"iso_checksum": "769474248a3897f4865817446f9a4a53",
"iso_checksum_type": "md5",
"ssh_username": "packeruser",
"ssh_password": "packer1234",
"shutdown_command": "echo 'packer' | sudo -S shutdown -P now"
}
Notice that I need to pass an ISO file to Packer in order for it to generate a VM. I also specify the SSH username and password so that Packer can connect to the virtual machine to run additional tasks after initial creation.
Provisioners
Packer provisioners allow you to configure your machine image using traditional configuration management tools like Puppet, Chef, Ansible or just plain shell scripts (Bash or PowerShell). Provisioners begin executing after your machine image initial OS install is complete. Here, I add a PowerShell provisioner to run a script:
{
"scripts": [
"./scripts/DoSomething.ps1"
],
"type": "powershell",
"valid_exit_codes": [0]
}
You may be asking yourself, how does Packer actually run that script though? Packer allows you to make scripts accessible to your VMs via a floppy drive in your builds configuration:
"floppy_files": [
"./scripts/DoSomething.ps1",
"./scripts/InstallChocolatey.ps1",
]
In this next example, I want my image to be configured by Puppet, so I can pass information along do it like the Puppet Server.
{
"type": "puppet-server",
“puppet_server”: “my_puppet_server”,
"options": "--test --pluginsync",
}
Post-Processors
The integration with many different solutions (AWS, Azure, VMware, Google etc) is what makes Packer a truly special product. Taking one configuration of a machine build and sending it off to all of these different platforms allows organizations the ability to never be tied to one.
Here, I will create a vSphere template VM from our Packer build.
{
"type": "vsphere-template",
"host": "vcenter.domain.com",
"insecure": true,
"username": "root",
"password": "myRootPassword",
"datacenter": "mydatacenter",
"folder": "/myTemplates"
}
Conclusion
The current state of IT operations may be “cloud first”, but that isn’t necessarily one cloud platform. In addition, most organizations operate in a hybrid mode, running on-premises and cloud services at the same time. Packer is the perfect tool to use as it allows IT operations to build systems the same way regardless of where the VM will ultimately run.