Docker: Why multi-arch images matters?
Whoa whoa whoa… what does multi-arch mean?
To answer to this question, we have to speak about computer architecture; I’ll try to be as clear as possible.
Let’s think about your laptop, desktop PC or Mac: all of these devices have probably a CPU made by Intel or AMD with an x86 architecture at 64 bits, also technically called x86_64 or AMD64. The oldest has an x86 architecture at 32 bits and you can also find them with the names of x86 or i386.
What about your smartphones, tablets or IoT devices? Their CPU are probably made by Apple, Qualcomm, Broadcom or other manufacturers and use a different type of architecture: the ARM architecture. Also in this case we have the division between 64 bits (armv8) and 32 bits (armhf, armv6…).
Ok, it makes sense, but what are the differences between them?
In addition to the fields in which they are applied, the biggest difference lies in the instruction set: x86 uses the Complex Instruction set Computer (CISC), while ARM uses the Reduced Instruction Set Computer (RISC).
This means that a software that is compiled for an x86 CPU, can’t be executed on an ARM CPU…and the same goes for the containers!
I think I don’t understand where you want to go…
Take a look at Docker Hub: “the world’s largest library and community for container images”. There you can find a lots of images, but I want you to focus on the official MySQL image.
As you can see, for each tag there’s a OS/ARCH column: in the above image is highlighted by the a red rectangle. Its content indicates that this image produces a Linux container which can only be run on amd64 platforms, so only on x86 architectures at 64 bits.
If you try to execute it on a Raspberry PI 2 (ARM architecture at 32 bits), you’ll see a message like this:
Now it’s time to compare it with the official Redis image:
In this case there are a lots of supported platforms, even the one needed by the Raspberry PI… and that’s why the official Redis image is a multi-arch image!
So, what is the purpose of this article?
The aim of this paper is to emphasize the importance of multi-arch images and to suggest you a proper way to create them.
I use containers only on x86 architectures, I don’t need multi-arch.
This can be a good point of conversation, and it’s partially true: the majority of the servers uses an x86 architecture, but we can’t say the same for the clients: for example, in the IoT world ARM is the most popular.
Consider that now ARM CPUs have enough power to run small Kubernetes clusters, therefore the things could change quickly! So, why you should limit the number of the platforms in which you can ship your software?
Ok, you convinced me! Let’s do this!
Starting from Docker 19.03.0, the Docker Team added to the Community Edition (CE) of the software the support for buildx, an experimental feature born precisely for this purpose.
You don’t have to install anything: it is already bundled in your Docker installation, but if you want you can build the latest version using the instruction provided in the official repository.
To use it, you must enable the Docker’s experimental features using one of the suggested options:
- follow the instructions available in the official CLI’s repository.
- declare the DOCKER_CLI_EXPERIMENTAL=enabled environment variable.
The second choice can be more volatile than the first one.
If you begin to love this tool, I advice you to follow the first path and then configure buildx as default builder 😁 In addition to all that, you don’t have to adapt your Dockerfile in order to use this approach, but just make a one-time configuration to your pipeline.
Do you suggest/use any tool in addition to this?
In order to avoid any kind of configuration and be focused on the image deploy, I’ve made a GitHub Action to do that.
If you are interested, you can take a look in the GitHub Marketplace:
While if you want to contribute, feel free to fork and make a pull request in the dedicated repository:
