This document discusses multi-architecture support in the Docker registry to allow Docker images to run on different CPU architectures and operating systems. It proposes a "fat manifest" format that references single-architecture manifests for each supported architecture. This would allow a single image to be pulled that contains binaries for different architectures. It also outlines open issues like content trust, cross-compilation, and the need for new Docker commands to assemble fat manifests from individual architecture images.

1. Fattening up your Docker Images: Multi-architecture
support in the Docker Registry
Phil Estes
IBM Senior Technical Staff, Docker core maintainer
IBM Cloud Open Technologies

2. Current State of the Image World:
2
What should happen
when I run...

3. Well, hopefully something like this:
3

4. 4
But what if I have something like ...

5. What really happens:
5

6. —Vincent Batts
@vbatts
“Oh
mans.”
6

7. Hacking Multi-architecture
Creating special Hub repositories for an architecture’s images:
★ Example: a repo named “ ” for little-endian POWER 64-bit images
Standardized prefix for all images for a given architecture:
★ Example: Hypriot project “ “ images for Raspberry Pi
Using tags to denote architecture
★ Example: Architecture in tag, like , ,
Today’s workarounds

8. The Right Solution
Properly handles and records runtime architecture information
★ Assembled on ` `
Adds a new “fat manifest” type referencing single-architecture manifests
★ Keyed on architecture details (e.g. os, arch, & model)
★ Feature of ` ` to combine multiple single-architecture manifest references into a fat
manifest wrapper
A new proposed manifest format
https://github.com/docker/distribution/pull/1068
( Which was preceded by PR #993, which was preceded by PR #62 .. )

9. What Should Happen?
Looking into the future

10. How will it all come together?
Docker engine runtimes for new CPU architectures & operating systems
★ ARM: Hypriot/Raspberry Pi support underway; POWER/System z: IBM has builds/some distros
will be shipping Docker on ppc64le; Windows: Microsoft has TP3; FreeBSD: port available, etc.
Images created for each engine runtime platform
★ Will require design of new subcommand to handle the assembly of disparate “architecture/os-
specific” images into a fat manifest ( command?)
★ Engine manifest parsing algorithm will be updated to parse both single-platform and fat (multi-
platform) manifests automatically
★ Considerations: Docker Content Trust (push fat manifest/images from a single system with keys),
cross-compilation scenarios (e.g. hand-built container image from cross-compiled binaries), ?
What are the ingredients..

11. Thank you!
Phil Estes
@estesp
estesp@gmail.com