If you are following our #IoTOps series, you will find that we strongly believe that containers, and particularly Kubernetes, are the way to go when you want to run your software on IoT edge devices. Also, if you have tried to put your workloads on edge devices, you’ve surely noticed that all the images available in the Docker hub, unfortunately, are not available for the architecture we like the most, which means that there is no ARM support for everything out there.

The trend is to run Kubernetes everywhere, and that means not only Intel-based architectures, but also ARM, or even MIPS (take a look at the MIPS article, it’s really good).

So, we’ll go over what we have found on this journey and some useful approaches.

Base images

It’s common practice to use someone else’s work (the ‘do not repeat yourself’ mantra), and this approach generally works, except when we want to use not-so-popular architectures (like armv8 aka aarch64). When trying to rebuild an image, if you are using someone else’s images, make sure that the base image is available for your architecture.

Searching the image at Docker Hub is a simple way to see the supported architectures and find good candidates for your Base Image.

Use Manifests

The definition on the Docker site states that “a manifest is a list of information of an image, that is identical in function for different os/arch combinations”. To handle them you have to enable the experimental features and, for us, it’s the best way to handle images for every need, using always the same name and tags, regardless of the architecture.

Contribute

A lot of people out there need to have their software running, so be considerate and publish the images into a popular and public repository.

Automate

Automation is the key to having updated images. Software changes evolve, and also develops vulnerabilities; automate your images and keep them as updated as possible. When looking at an image to work with, people usually try to search first for fresh and updated ones.