DockerHub Official Images Go Multi-platform!

So, every once in awhile you get the immense pleasure of seeing an idea through from start to finish. Multi-platform container images may not be exciting for everyone, but it’s a topic I’ve been thinking about and working on since a team at IBM first approached me about helping figure this out in November 2014.

I was a relatively new contributor to the Docker engine (a few months of PRs under my belt), and the Golang Docker “v2” distribution project wasn’t even out yet! We were poking around the python code of the “v1” registry trying to figure out the best way to support the image format, knowing we had upcoming ports of Docker engine for our POWER and z Systems (a.k.a. the IBM LinuxONE) platforms. We wanted all users of the Docker engine to have the simplicity of that docker run redis experience no matter the CPU architecture.

Fast forward a year and lots of the image format details had been worked out (the v2.2 image spec was close to finalized), and I put up this forward looking slide at the end of my lightning talk at DockerCon EU in Barcelona:

It seemed pretty simple from here: the engine will do the work, find the matching image entry and run that container image after assembling/downloading its layers! We’ll skip all the blood, sweat, and tears from that point until now, but as of today we are no longer “Looking into the future” as that slide stated. Today, September 12th, 2017 you can simply type docker run redis on seven different Linux OS architectures (64 and 32-bit Intel, 2 variants of arm 32-bit, arm 64-bit, ppc64le, and s390x) and you will have a running redis server!

As of today, the official images are finally provided via manifest lists! https://t.co/3EaJZjJWUy ??? (special thanks @estesp; cc @yosifkit)

— Tianon Gravi ✿ (@tianon) September 13, 2017

Along the way, I wrote a tool to do this assembly of what became known as “manifest list” objects in the v2.2 image spec. You can find out more about manifest-tool from its GitHub project page, or from my blog post on this topic from last April. Lots of people have contributed to making this tool more useful along the way, including Lucas Käldström (better known as @kubernetesonarm on Twitter), the LinuxKit team (who already went “multi-arch” several weeks ago), and of course Tianon and his merry band of official image creators at InfoSiftr.

The good news is that in addition to the manifest-tool project, work is well underway to have a Docker client command to interact with manifest objects (including manifest list creation); you can find a lot more of that discussion and implementation in docker/cli PR #138. Thanks to IBM colleague Christy Perez who took up the monumental task of creating more than one PR/implementation of a brand new client subcommand and handling all the review, updates, rebases, and commentary that has generated since! You can read her blog post on creating multi-arch images, and definitely check out Christy and fellow IBMer Chris Jones’s talk from DockerCon Austin earlier this year on the topic.

Of course, more work is still underway related to the UI elements of DockerHub visually showing information about manifest lists, as well as broadening support of official images across architectures (and platforms, too!) Speaking of platforms, Windows is part of this multi-platform family of support via manifest lists. Fellow Docker Captain Stefan Scherer has a great talk on this topic via Slideshare. Remember that for an image on DockerHub to have a full slate of entries in the manifest list, it must be buildable/supportable across those CPU architectures and platforms. So, IBM, ARM Ltd, Raspberry Pi enthusiasts, Microsoft, and many others are still at work building out further support across the popular and official open source software images.

So, how can you tell if your favorite image has support for your platform or architecture of choice? Today the easiest way is to use the manifest-tool inspect command against a repository/image reference (or fully specified registry URL and image in the case of private registries) and retrieve a listing of the supported platform entries within that image, if it is a manifest list object. This capability will also be available in the Docker client when the earlier mentioned PR is finalized. See the releases page of the manifest-tool to easily download a pre-built binary for your platform of choice.

Finally, a few more words of thanks. I started bugging the original Docker distribution team about this topic several years ago. Initially Olivier Gambier was kind enough to get a regular call started with a community of interested parties, which then led to me harassing Stephen Day and Derek McGowan on a regular basis to get the v2.2 image spec finalized, agreed to, implemented, and ready for use. Thanks additionally to Aaron Lehman who ended up doing the initial work/PRs for handling manifest lists in the registry code and the Docker engine.

The good news (well, for those not tired of the topic yet) is that I won’t stop talking about multi-platform image support quite yet, as Michael Friis and I are speaking at DockerCon EU next month in Copenhagen on this very topic: “Docker Multi-arch All The Things.” We’ll be showing off the open source and Docker Enterprise enablement of multi-platform clusters with hybrid nodes using Windows, Linux on amd64 and Linux on z & POWER systems!

I’m really excited to watch and see how today’s next big step forward in enabling multi-arch and multi-platform support impacts the viability of container native solutions across more architectures and platforms as we head into the future.