Packer is an open source tool developed by HashiCorp that lets you create identical images using the same source. It helps in implementing and managing golden images across your organization. I will be using Packer in a vSphere environment only and not be using its multi platform support. The use case I am looking at is managing VM templates applying infrastructure as code concepts.
The workflow I am implementing is using base VM templates made of basic OS installation, VMware tools and networking connectivity. These base templates do not need any management except for periodic updates/patches. The base VMs then are customized into project specific templates using Packer. The process installs any given project customization such as additional users, software packages, devices and creates a new template to be used as the source for prod deployment. Packer will not replace a configuration management tool, but it will reduce the time to deploy and configure the prod (or running) instances. It is faster to have a prepped template than to wait for packages to install on each of your instances during prod deployment. The diagram below exemplifies the intended process:
In this workflow, Packer plays a crucial role allowing for fast and repeatable automation of the VM templates based on specific requirements. All credentials are kept in a dedicated secrets manager, called Vault. I will not enter into details about Vault, just keep it in mind as it is used to store any credentials used by Packer. A new set of templates results at the end of the customization process and these are used to run the prod instances.
Packer will also ensure that any changes to the base VM template are tracked and can be repeated in any other infrastructure while they are written in a human readable format. Let's look at a simple example where we modify a CentOS 7 base template. For our project we will use the the following folder structure:
There are 3 files:
- variables.pkr.hcl - keeps all variable definitions
- tmpl-linux.auto.pkrvars.hcl - keeps the initialized input variables and it will be loaded during run; this allows to only change this file when moving to another environment
- tmpl-linux.pkr.hcl - main Packer file
Packer uses HashiCorp Configuration Language (HCL). Let's look at variables.pkr.hcl file contents:
variable "vcenter_server" {
type = string
description = "FQDN or IP address of the vCenter Server instance"
}
variable "build_user" {
type = string
description = "user name for build account"
}
locals {
timestamp = regex_replace(timestamp(), "[- TZ:]", "")
}
local "linux_user_pass" {
expression = vault("/kv/data/linux_workshop", "${var.ssh_user}")
sensitive = true
}
local "build_user_pass" {
expression = vault("/kv/data/build_user", "${var.build_user}")
sensitive = true
}
There are 2 types of variables - input variables and local variables. Input variables need to be initialized from a default value, command line, environment or variable files (we are using auto.pkvras.hcl file for this). Local variables cannot be overridden at run time and can viewed as some kind of constants. In the example above the real number of variables has been truncated to keep it readable. You can see the input variables such as "vcenter_server" and "build_user". There are also 2 local variables - "timestamp" which is calculated from a function and used in our case in the note field of the VM and "build_user_pass" which keeps the password for our build user and it takes this value from Vault secrets manager. The "build_user_pass" is marked as sensitive which will hide it from the output.
Next, let's look the variable initialization file tmpl-linux.auto.pkrvars.hcl
vcenter_server = "vcsa.mylab.local"
build_user = "build_user@vsphere.local"
We chose to initialize the variables from a separate file. In it, we just assign values to our input variables. If we need to modify any variable this is the only place where we make the changes which makes it easier to manage. Again, for ease of reading the file has been truncated.
Time to see what the tmpl-linux.pkr.hcl file contains. In the customization we'll apply to our template we are looking at two things:
- add a new disk to the target image
- install software packages in the target image
We'll look at each section in the packer fil. First we define the required plugins - in our case vsphere. You can make sure that a certain version is loaded.
packer {
required_version = ">= 1.8.5"
required_plugins {
vsphere = {
version = ">= v1.1.1"
source = "github.com/hashicorp/vsphere"
}
}
}
Next we define the source block which has the configuration needed by the builder plugin (vsphere plugin loaded above).
source "vsphere-clone" "linux-vm-1" {
# vcenter server connection
vcenter_server = "${var.vcenter_server}"
insecure_connection = "true"
username = "${var.build_user}"
password = local.build_user_pass
# virtual infrastructure where we build the templates
datacenter = "${var.datacenter}"
host = "${var.vsphere_host}"
datastore = "${var.datastore}"
folder = "Templates/${var.lab_name}"
# source template name
template = "${var.src_vm_template}"
# build process connectivity
communicator = "ssh"
ssh_username = "${var.ssh_user}"
ssh_password = local.linux_user_pass
# target image name and VM notes
vm_name = "tmpl-${var.lab_name}-${var.new_vm_template}"
notes = "build with packer \n version ${local.timestamp} "
# target image hardware changes
disk_controller_type = ["pvscsi"]
storage {
disk_size = var.extra_disk_size
disk_thin_provisioned = true
disk_controller_index = 0
}
convert_to_template = true
}
In the source we let the build plugin know how to connect to vCenter Server, what virtual infrastructure to use (datastores, hosts), what is the source template that we will use, how to connect to it and what is the configuration for the target template that we build. At the end we instruct the plugin to convert the newly created image to a VM template. Notice the communicator defined as "ssh". Communicators instruct Packer how to upload and execute scripts in the target image. It supports: none, ssh and winrm. Please mind some builders have their own communicators, such as Docker builder.
With the current configuration we can actually define our build process. We've already accomplished half of our customization - adding the new disk is defined in the source block. In the build block we place the configuration that is needed by our build plugin. We will actually use a shell provisioner to install two packages - htop and tree. In my example, shell provisioner is sufficient to do the job, basically run in the target image "yum install". However I would recommend using a proper configuration management tool such as Ansible instead of directly running commands.
build {
sources = ["source.vsphere-clone.linux-vm-1"]
provisioner "shell" {
execute_command = "echo '${local.linux_user_pass}' | sudo -S sh -c '{{ .Vars }} {{ .Path }}'"
inline = ["yum install tree htop -y"]
}
}
Notice execute_command - this is a customization of the command we want to run (yum) and we use it to send the sudo password. The password itself is take from the local variable which is initialized with the value from kept in Vault secrets manager (as defined in variables.pkr.hcl).
The only thing left to do is to validate your configuration and run the build process.
packer validate .
packer build .
Please note that variable files in this post have been truncated for ease of reading. If you intend to use this example, you would need to fill in the missing variables and initialize them according to your environment.
