Balena releases 26k new container base images optimized for IoT and Edge Computing

Sometimes combinatorial explosion is your friend. Today we are proud to announce the release of over 26,000 new base images under the balenalib namespace over on DockerHub.

Over the last 4 years we’ve been maintaining and nurturing the most comprehensive set of base images for deploying containers on the edge. We’ve learned a lot by watching and listening to and supporting our users, such as how to slim down the distributions and how to ease access to hardware peripherals. Our new balenalib set of base images takes from and improves on those learnings, and we hope to see the base images continue to be relied upon by more and more projects, whether they use balenaCloud, openBalena, or none of our other products and projects at all.

How to Pick a Base Image

With over 26000 balenalib base images to choose from it can be overwhelming to decide which image and tag is correct for your project. To pick the correct image, it helps to understand how the images are named as that indicates what is installed in the image. In general the naming scheme for the balenalib image set follows the pattern below:

balenalib/<hw>-<distro>-<lang_stack>:<lang_ver>-<distro_ver>-(build|run)-<yyyymmdd>

Image Names:

• <hw> is either architecture or device type and is mandatory. If using Dockerfile.templates you can replace this with %%BALENA_MACHINE_NAME%% or BALENA_ARCH. For a list of available device names and architectures see the Device types.
• <distro> is the linux distribution, currently there are 4 distributions, namely Debian, Alpine, Ubuntu, and Fedora. This field is optional and will default to Debian if left out.
• <lang_stack> is the programming language pack, currently we support Node.js, Python, OpenJDK and Go. This field is optional and if left out, no language pack will be installed, so you will just have the distribution.

Image Tags:

In the tags, all of the fields are optional and if they are left out, they will default to their latest pointer.

• <lang_ver> is the version of the language stack, for example node.js 10.10, it can also be substituted for latest.
• <distro_ver> is the version of the linux distro, for example in the case of Debian there are 4 valid versions, namely sid, jessie, buster and stretch.
• For each combination of distro and stack we have two variants called run and build. The build variant is much heavier as it has a number of tools preinstalled to help with building source code. You can see an example of the tools that are included in the Debian Stretch variant here. The run variants are stripped down and only include a few useful runtime tools, see an example here.
  If no variant is specified, the image defaults to run
• the last optional field on tags is the date tag. This is useful for production deployments as these base images are non-moving tags, so no packages in these will update ever.

Feature Highlights

The new set of base images have a number of great features. First, they support 6 major CPU architectures, namely ARMv5e, ARMv6, ARMv7, AARCH64, amd64 and i386. We have also expanded the number of linux distributions we support; our base images now support Debian, Ubuntu, Alpine and Fedora for over 30 different device types, and each of these distros supports the latest version.

We also have included language “stacks” for Node.js, Python, Java (OpenJDK) and Golang for all 30+ device types supported on balenaCloud. Next up we will be adding .Net and Rust stacks as well.

To ease their use and make sure our users create slim and resilient builds, we have included a new utility called install_packages. This is a small script inspired by minideb that wraps around the distro package manager and ensures that all cache is cleaned out after package install, and adds retry logic in case of failed package mirrors.

Every ARM-based image in the balenalib set also includes our cross-build feature, which allows you to build ARM base images on any x86 machine, even DockerHub.

Last but not least, each balenalib base image has two variants, namely -build and -run. These variants make using Docker multistage builds a breeze. Simply define your first stage with a -build tag and then your final deployment stage with a -run tag, and you can rest easy knowing that your final deploy artifact will have only the runtime essentials. Every date-pinned base image has these variants as well, for those who want to ensure their production dependencies only update exactly when they need them to.

As a note to existing users of the resin/ imageset, this new set of base images will be our main focus going forward. We will be deprecating the resin/ image set and they will no longer be receiving updates, though the images will remain available for the foreseeable future. Please see the base images documentation for more information on migrating to balenalib. These new images are slimmer, and should not cause issues with plugged hardware such as cellular modems.

This new image set is just the start, and it creates the foundation for something we hope grows to be much bigger over time, as it represents a whole new way of building base images for scale. We hope you enjoy them as much as we do, and as with everything balena does, please share your feedback and help us improve the base images for everyone!