Reducing Image Drift with Multi-Cloud Packer Templates

The Problem: Fragmented Image Pipelines

When engineering for multi-cloud environments, teams often fall into the trap of maintaining separate image scripts for every provider. You might have a Bash script for AWS AMIs and a separate set of instructions for Google Compute Engine (GCE) images. This fragmentation leads to "image drift," where a security patch is applied to the AWS image but forgotten in the GCP version, creating inconsistent security postures across your infrastructure.

The solution is to decouple the infrastructure definition (where the image lives) from the provisioning logic (what is installed on the image). By using Packer's HCL2 (HashiCorp Configuration Language), you can define a single build pipeline that targets multiple cloud providers simultaneously using a shared set of provisioners.

Decoupling Sources from Builds

In HCL2, Packer separates the source block from the build block. A source block defines the cloud-specific requirements—such as the machine type, SSH keys, and the base image ID. The build block, however, defines the sequence of actions to take once the machine is booted.

By defining multiple source blocks in one template, you tell Packer to spin up parallel instances across different clouds. You then apply a single set of provisioners to all of them. This ensures that whether the image ends up as an Amazon Machine Image (AMI) or a GCP Image, the installed software versions and configurations are identical.

Worked Example: Cross-Cloud Base Image

The following configuration demonstrates how to target both AWS and GCP using a shared shell provisioner to install a web server. This example assumes you have the necessary cloud credentials configured in your environment variables.

# Save as multi-cloud.pkr.hcl
variable "web_port" {
  type    = string
  default = "80"
}

source "amazon-ebs" "ubuntu" {
  ami_name      = "web-server-{{timestamp}}"
  instance_type = "t3.micro"
  region        = "us-east-1"
  source_ami    = "ami-0c55b159cbfafe1f0"
  ssh_username  = "ubuntu"
}

source "googlecompute" "ubuntu" {
  project_id            = "my-gcp-project"
  source_image_family   = "ubuntu-2204-lts"
  zone                  = "us-central1-a"
  ssh_username         = "ubuntu"
  image_name            = "web-server-{{timestamp}}"
}

build {
  sources = [
    "source.amazon-ebs.ubuntu",
    "source.googlecompute.ubuntu"
  ]

  provisioner "shell" {
    inline = [
      "sudo apt-get update",
      "sudo apt-get install -y nginx",
      "sudo systemctl enable nginx"
    ]
  }
}

Running the Build

Run these commands from your terminal in the directory containing the file. You will need administrative permissions for the cloud accounts specified.

• Validation: Run packer validate . to check for HCL2 syntax errors.
• Execution: Run packer build . to initiate the parallel builds.
• Risk: If one provider's API is down or a quota is exceeded, the entire build may fail depending on your version settings. Use the -debug flag to trace API communication if a builder hangs.

Handling Cloud-Specific Divergence

While the goal is parity, cloud providers handle initialization differently. For example, AWS uses cloud-init via User Data, while GCP uses its own metadata server. If you need to perform a task that is unique to one provider—such as attaching a specific AWS IAM role—you cannot put that in the shared build block.

To handle this, you can use conditional provisioners or separate build blocks for provider-specific tweaks, though the most maintainable approach is to keep the shared build as the "golden" standard and use configuration management tools (like Ansible) to handle the final 5% of cloud-specific tuning at boot time.

Limitations and Verification

The primary limitation of this approach is the "lowest common denominator" effect. If one cloud provider has a slower disk I/O or a more restrictive firewall during the build phase, your entire pipeline's speed is limited by that provider. Additionally, large images can trigger timeouts during the snapshot phase in GCP or AWS if the network throughput is throttled.

How to verify the result:

1. Log into the AWS Console and GCP Console.
2. Locate the images created with the web-server- prefix.
3. Launch a temporary instance from each image and run systemctl status nginx to confirm the provisioner executed successfully on both platforms.

Actionable Closing

To implement this in your workflow, start by auditing your current image scripts. Identify the commonalities—security patches, monitoring agents, and runtime environments. Move those into a shared HCL2 build block and isolate the cloud-specific IDs into source blocks. This transition reduces the maintenance burden from N scripts to one single source of truth.