The Cookie Cutter for Clouds
You could create a machine image manually: launch a cloud VM, SSH in, install your software, click "Create Image" in the console, and terminate the instance. This works once. But it is slow, undocumented, and impossible to reproduce exactly. The next engineer who needs to build an image will do it slightly differently, and you are back to drift — this time in your images rather than your servers.
HashiCorp Packer is an open-source tool that automates machine image creation. You define your image as code in a template file, and Packer handles the entire lifecycle: launching a temporary VM, running your installation scripts, capturing the result as an image, and cleaning up. The template is the source of truth. Anyone running packer build against the same template gets the same image.
Packer is cloud-agnostic. The same provisioning logic (your shell scripts or Ansible playbooks) can produce an AWS AMI, a GCP machine image, an Azure managed image, a VMware OVA, and a Docker image — all from one template. This is valuable in multi-cloud environments or when you need to test locally with a VM before publishing to a cloud.
Key Packer Components
Packer templates are composed of three building blocks:
1. Builders
A builder defines where and how to create the image. It specifies the cloud provider, the base image to start from, the instance type to use during the build, and authentication credentials. Common builders include:
amazon-ebs— Creates an AWS AMI by launching an EC2 instance, snapshotting its EBS volume, and registering the snapshot as an AMI.azure-arm— Creates an Azure managed image.googlecompute— Creates a GCP machine image.docker— Creates a Docker image (though Dockerfiles are more common for containers).
2. Provisioners
A provisioner defines what to install and configure inside the running temporary VM. Packer starts the VM using the builder, then hands control to the provisioners in sequence. Common provisioners include:
shell— Runs inline commands or a shell script.ansible— Runs an Ansible playbook against the temporary VM.file— Uploads files from your local machine into the VM.chef-solo— Runs Chef recipes.
3. Post-Processors
Post-processors run after the image is built and saved. They can tag the image, compress the artifact, push it to a registry, or write a manifest file. For example, a manifest post-processor writes a JSON file containing the new AMI ID — useful for passing the ID to a downstream Terraform pipeline.
HCL2 vs. JSON Templates
Packer originally used JSON templates. Since Packer 1.7, the preferred format is HCL2 (HashiCorp Configuration Language version 2), the same language used by Terraform. HCL2 supports variables, locals, expressions, and comments — making templates significantly more maintainable than JSON. All examples in this lesson use HCL2.
Key Point: Packer's value is not just automation — it is reproducibility. A Packer template checked into version control is an auditable, reviewable, testable specification of exactly what is in your image. When a security team asks "what is installed on your production servers?", you can point to a Git commit rather than trying to reconstruct the history of manual changes.