What do the balenalib images do?

Product support
1

Beyond the obvious support for different architectures and some drivers for using device specific feature what else distinguishes the balenalib images from normal images? With the arrival of multi-arch across the Balena system I am looking to switch to official images provided by the makers.

I use the following labels:

  io.balena.features.dbus: '1'
  io.balena.features.supervisor-api: '1'
  io.balena.features.balena-socket: '1'

And I use the UDEV feature for usb support, which seems to rely on an entry script: base-images/entry.sh at master · balena-io-library/base-images · GitHub

Is there anything else I would need to switch images? Any implications on preloading?

3

Hi @maggie0002, balena base images are meant to make it easier to get started operating with balenaOS and different device architectures, but there is nothing in our platform that prevents other images of the right architecture for being run on balena devices. Preloading should work normally as well as it just copies whatever images are in the registry into the OS image before flashing.

As you already figured out, the extra utility of the images comes from some included tools and scripts that reduce the time for users to get their app running on a device. An example of this is UDEV, as you mention, but also the inclusion of dbus and curl, as well as our cross build tools.

If you install the right dependencies I would not expect you to have any problems.

Regarding the labels, those are read by the supervisor so they don’t depend on the base image.

  • the dbus label mounts the dbus socket from the host into the container filesystem, so any dbus client can connect to it
  • the supervisor-api label gives the container access to the supervisor network and adds an API key environment variable in the container
  • the balena-socket label just mounts the host socket into the container, which can be accessed by any client

Please let us know if this information helps you, or you run into any issues creating apps using official images.

1 Like
5

Most helpful, thanks. Managed to cut the image sizes 50% with the official ones and the multi arch benefit for my dev env. Using the udev script and a few packages from the dockerfile of the balena image looks like it all works great.

6

That’s great to hear, I’m glad we could help. Just a question, what is the main advantage you are looking for in official images? Is it just size? Or is it about support too? Thanks for your help.

8

Size primarily. Although the multi arch images are beneficial. I was using official images for my dev env and balena for my prod because balena requires specifying the arch in the title. So developers on Mac M1 had to change the image name manually while older Mac users with another arch had to use the amd label. This is for a local dev env and would prefer dev and prod env were as familiar as possible.

Having the %%etc%% labels were only compatible with Balena, nothing else like GitHub Workflows or local docker.

There are always missing images from the Balenalib library, I usually post on the forum here to get the gaps filled and it takes a while to get them built. Creates delays and makes bumping versions a pain.

The Balenalib hosting in Docker Hub is really hard to navigate. There are so many images and dockers website hard to navigate without a search function for within a particular users account. When you combine that with BalenaLib’s container name conventions which has dates on the end as tags to identify fixed images rather than something like semver versioning it becomes very frustrating.

Safe to say I’m not going to miss the Balenalib images.

If I used the devices for their hardware specific components, linking to switches and sensors and so forth, I would certainly be staying with the Balena Lib images though,