Packer: Build Identical Machine Images Everywhere

Why it exists

Manually configuring servers or applying scripts after they launch leads to configuration drift, where no two environments are truly identical. Packer solves this by shifting configuration into the image-building phase, creating immutable, pre-configured artifacts that guarantee consistency.

The mental model

Think of Packer as a recipe for baking a cake, where the cake is a machine image. You write a single recipe (a Packer template) that defines the base ingredients (OS), extra fillings (software packages, security patches), and baking instructions. Packer then bakes identical cakes (AMIs, Docker images, VMware images) for different ovens (AWS, Docker, vSphere). If you need to change the cake, you change the recipe and bake a new one; you don't try to inject more flour into a finished cake.

How it works

Packer orchestrates a build process defined in a single source configuration file (a template). The process has three main stages. First, a Builder plugin creates a temporary machine on a target platform, like an EC2 instance on AWS. Second, Provisioner plugins connect to that machine to install and configure software using tools like shell scripts or Ansible. Finally, after the machine is configured, Packer creates a reusable image from it. Optional Post-Processor plugins can then run to tag the image, copy it to other regions, or publish it to a catalog.

When to use it

Use Packer to create "golden images" for your cloud infrastructure (AWS AMIs, Azure Images, GCP Images). It's also used for building standardized developer environments for Vagrant, creating container images, and in any scenario where you need a repeatable, automated process for producing a consistent starting point for a compute resource.

When not to use it

Packer is a build-time tool, not a run-time tool. Do not use it for configuration management of running instances; that is the job of tools like Ansible, Puppet, or Chef. Packer creates the immutable image; other tools deploy and manage instances created from that image.

One canonical example

A CI/CD pipeline can be triggered by a code change. The pipeline runs packer build, which launches a temporary VM, installs the latest security patches and application code, and then saves the result as a new Amazon Machine Image (AMI). The new AMI ID is then passed to Terraform, which performs a rolling update of the production fleet, replacing old instances with new ones based on the fresh, immutable image.