Multi-Arch Docker Images

Things have been a little hectic recently and a whole month has slipped past without a blog post. The following is old news now but it’s still something that I wanted to call out. As of mid-September, all the official images on Docker Hub have been multi-arch enabled and many of them, including the websphere-liberty image, are now available for multiple platforms.

So what does that mean practically speaking? It means that, whether you are on x, p or z, hardware, you can now use the same docker run websphere-liberty command and have it pull the appropriate image for your architecture. That may seem like a trivial thing: what was so hard about docker run ppc64le/websphere-liberty after all? What it means though is that I can also use the same Dockerfiles, Compose files and Kubernetes configuration, regardless of what platform I’m on.

If you consider WebSphere Liberty, for example, we don’t have any architecture specific code but we are obviously dependent upon Java which has both native code and is dependent on platform specific libraries. That meant that, to build the ppc64le/websphere-liberty image, we had to change the Dockerfile to build from ppc64le/ibmjava. That’s no longer the case.

To take another example, with my Microservice Builder hat on we are building Helm charts that we want to run on multiple platforms. Previously we’d had to rely on multiple charts or overrides to select the correct image for the platform. That’s also no longer the case.

Now just to be 100% clear, this is not about having a single image that can run on multiple architectures: that would require a hypervisor or emulator. The magic here is purely that websphere-liberty is no longer an image, it is a manifest that points to the layers that make up the images for each architecture, and, when the image is pulled, that indirection is resolved by the client to select the image for the current platform.

If you want to know more of the technical detail and the journey to get this far, I suggest reading the blog posts by my colleagues Phil Estes and Utz Bacher. I also need to call out Tianon Gravi whose tireless work on the official images meant that enabling this support for WebSphere was entirely painless.

Comments are closed.