packer
Create identical machine images for multiple platforms
TLDR
Build an image
Check the syntax of a Packer image config
Format a Packer image config
SYNOPSIS
packer
Examples:packer build example.pkr.hcl
packer validate template.json
PARAMETERS
-color=
Controls colorized output from Packer. Defaults to true.
-machine-readable
Outputs Packer log lines in a machine-readable format, useful for programmatic consumption.
-timestamp-format=
Specifies the Go time format for timestamps in machine-readable output (e.g., '2006-01-02T15:04:05Z07:00').
DESCRIPTION
Packer is an open-source tool developed by HashiCorp for creating identical machine images from a single source configuration. It automates the generation of various types of machine images, including AMIs for AWS, VHDs for Azure, VMDKs for VMware, and Docker images, among others. The primary goal of Packer is to enable reproducible and consistent infrastructure by allowing organizations to create "golden images" that are pre-configured with operating systems, software, security patches, and application dependencies. This approach significantly reduces deployment time, minimizes configuration drift, and ensures environments are consistent from development to production.
Packer uses a JSON or HCL (HashiCorp Configuration Language) template to define the image creation process. A template consists of three main components: builders, which define the target platforms (e.g., AWS EC2, VirtualBox); provisioners, which install and configure software on the running machine during the build process (e.g., Shell scripts, Ansible, Chef); and post-processors, which take the output of a builder and process it further (e.g., compressing an image, uploading to a repository). This modular design makes Packer highly flexible and extensible, integrating with a wide array of cloud providers, virtualization technologies, and configuration management tools.
CAVEATS
Building images with Packer can be resource-intensive, requiring significant CPU, memory, and network bandwidth, especially for large images or multiple parallel builds.
While Packer automates image creation, it requires a solid understanding of the underlying cloud or virtualization platform and the provisioning tools being used.
Debugging failed builds can be challenging as issues often occur within the guest operating system or provisioning scripts, requiring detailed logging and iterative refinement.
TEMPLATE COMPONENTS
Packer templates, written in JSON or HCL, define the entire image build process. They primarily consist of:
Builders: Define the target platform (e.g., AWS EC2, VirtualBox) and how the base image is initially spun up.
Provisioners: Install and configure software on the running instance during the build. Common provisioners include shell scripts, Ansible, Chef, and Puppet.
Post-processors: Take the output of a builder (the created image) and perform additional actions, such as compressing it, uploading it to a specific registry, or converting it to another format.
IMMUTABILITY AND CONSISTENCY
Packer promotes the concept of "immutable infrastructure." Once an image is built, it is not modified; any updates or changes necessitate building a new, updated image. This approach ensures consistency across environments, simplifies rollbacks (by deploying an older image), and reduces configuration drift, making deployments more reliable and predictable.
KEY SUB-COMMANDS
Packer's functionality is accessed via various sub-commands, each serving a specific purpose in the image building workflow:
build: The primary command for executing a template and building machine images.
init: Initializes a configuration directory by downloading necessary plugins.
validate: Checks the syntax and validity of a Packer template without performing a build.
inspect: Provides a summary of the builders, provisioners, and post-processors defined in a template.
fmt: Formats Packer HCL configuration files to a canonical style.
version: Displays the Packer version and plugin versions.
HISTORY
Packer was first released by HashiCorp in 2013. Its development was driven by the need to streamline the creation of consistent, immutable infrastructure across diverse environments. Before Packer, teams often managed disparate image creation processes for different platforms, leading to "image sprawl" and inconsistencies. Packer offered a unified workflow and template language to address this, quickly gaining traction in DevOps and cloud engineering communities. Over time, it has evolved to support a broader range of builders (e.g., cloud platforms, containers, serverless runtimes) and provisioners, and adopted HashiCorp Configuration Language (HCL2) for enhanced template readability and maintainability.