Skip to content
A reference example on how to build multi-arch Linux images using Azure Pipelines
Makefile Dockerfile
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
img
qemu
src
.azure-pipelines-job.yml
.azure-pipelines.yml
.dockerignore
.gitignore re-import Jun 22, 2019
LICENSE
Makefile
README.md

README.md

azure-pipelines-multiarch-docker

Docker Stars Docker Pulls Build Status

This is a shim/template repo for an Azure DevOps pipeline to build multi-architecture images:

Pipeline Structure

At the Azure Pipelines level, this creates:

stages

  • One independent stage for each CPU architecture
  • A "wrap-up" stage that runs after all the others that builds and publishes the Docker manifest file

Why?

Because I needed a simple, re-usable example of how to build multi-architecture images (in, this case, Linux for several different CPU architectures) that I could both re-use and share with customers.

How?

Images are created atop a local base (in this case Ubuntu) with a corresponding qemu-user-static binary embedded, which allows most CI systems to build ARM images atop an amd64 CPU.

The sample src/Dockerfile only installs zsh into that image, but the intent is that you can build this up from there.

Internals

Most of the image generation logic (including embedding QEMU and building the final manifest that allows for automatic discovery of architecture-specific tags) lives inside the Makefile.

This is done because:

  • Having a Makefile allows for easy local testing
  • It also allows for easy movement between different CI systems
  • The actual architecture tagging (and mapping between different styles of architecture references) can be maintained inside the Makefile
  • Encapsulating that logic makes the CI YAML files considerably more readable

Projects Using This

Caveats

  • This does not cover multi-OS (Linux/Windows) images--the principles are the same, but that needs to split on the CI side to allow for different stages inside different VM agents.
  • This only uses Docker Hub (and requires DOCKER_USERNAME and DOCKER_PASSWORD to be set as private global variables for the pipeline--I recommend using linked variables at the organization level).
  • This does not use the built-in Docker actions in Azure Pipelines (because they do not yet support the experimental mode settings that are still required, as of June 2019, to build manifests).
You can’t perform that action at this time.