Packer: Building Reproducible Docker Images Without the Guesswork

The Reproducibility Problem

When you build Docker images by hand, small differences in the build environment, package versions, or OS base layers can cause subtle failures that only appear in production. You might have a working image today, but tomorrow a dependency update breaks it. Packer solves this by treating image creation as code - with versioned templates, validated builds, and consistent outputs across any platform.

Why Packer for Docker?

Packer's docker builder lets you define your image in a declarative template, ensuring every build starts from the same foundation. Unlike the Dockerfile approach which can vary by context, Packer captures the entire build context - including the base image, build steps, and final configuration - in a single, version-controlled file.

The Core Workflow

A Packer template has three key parts: a source defining your base image, builders specifying how to create the image, and provisioners that run commands inside the image. This separation lets you swap builders (local Docker, AWS, GCP) without rewriting your build logic.

A Practical Example: Building a Node.js Image

Let's create a reproducible Node.js 20 image with a specific application. Here's a minimal HCL2 template that validates, builds, and verifies the result:

variable "image_name" {
  type    = string
  default = "my-node-app"
}

source "docker" "node_image" {
  image  = "node:20-alpine"
  commit = true
}

build {
  sources = ["source.docker.node_image"]

  provisioner "shell" {
    inline = [
      "apk add --no-cache git make",
      "node --version",
      "npm --version"
    ]
  }

  # Copy application files
  provisioner "file" {
    source      = "app/"
    destination = "/app/"
  }

  # Install dependencies and build
  provisioner "shell" {
    working_dir = "/app"
    inline      = [
      "npm ci --only=production",
      "npm run build"
    ]
  }

  # Verify the build
  provisioner "shell" {
    working_dir = "/app"
    inline      = [
      "node -e \"console.log('Build verified at', new Date().toISOString())\""
    ]
  }
}
>

Running this template:

1. packer init . - Downloads the Docker builder plugin
2. packer validate docker.pkr.hcl - Checks template syntax
3. packer build docker.pkr.hcl - Executes the build

If validation passes, Packer creates an image tagged my-node-app. You can verify it exists with docker images.

Key Trade-offs and Limitations

Not a replacement for Dockerfiles: Packer excels at building images but doesn't handle multi-stage builds or image optimization the same way. For complex Node.js builds with native dependencies, a Dockerfile might be more natural.

Build context handling: Packer's file provisioner copies files but doesn't automatically exclude .dockerignore patterns. You'll need to manage what gets copied manually or use a separate cleanup step.

Platform-specific considerations: The Docker builder creates images locally, but pushing to registries requires the post-processor configuration. AWS ECR, for instance, needs login credentials and may require specific IAM permissions.

Verification Checklist

• packer init completes without errors
• packer validate reports the template is valid
• Build completes and shows your verification output
• docker run the image and confirm expected behavior

Actionable Next Steps

Start with a simple template for your existing image build process. Add validation to your CI pipeline to catch template errors early. Then experiment with Packer's post-processors to automate pushing to your container registry. The key is treating your image builds as code from day one - it pays off when you need to reproduce or audit your images later.