Skip to main content
Version: Torizon OS 6.x.y

Best Practices with Containers

Introduction​

Torizon, as explained on the Torizon OS Technical Overview, provides the container runtime and Debian Containers for Torizon, among others listed on the List of Container Images for Torizon, to simplify the developer's life and keep the development model close to one of desktop or server applications. Even though we follow the desktop and server application standards as much as possible, some requirements are inherent to embedded systems development that are divergent. One typical example is hardware access.

Torizon also has its architecture-specific aspects of the system, like graphics and UI, that you should consider when developing your application or porting to an existing one. In this chapter, we will discuss some of those potential issues and how to handle it.

Prerequisites​

Running in a Container​

Running your application in a container means that it will run in a "sandboxed" environment.

This fact may limit its interaction with other components in the system. See below some examples of things that may not work when your application is running inside a container:

  • Changing configuration settings
  • Storing data permanently
  • Other operations

There are solutions for many of those scenarios and, usually, those aren't too hard to apply. In this article, we'll discuss some of them, keeping in mind best practices.

These best practices apply to leverage the extra layer of security provided by the containers. Sometimes, we may refer to what seem to be less secure approaches while they are not in fact. Keep in mind that, in a regular non-containerized embedded system, most likely the application would have access to the entire root filesystem. On the other hand, if you use a container from the community where you don't fully trust the software shipped with it, you may consider splitting critical logic to another smaller container that you have more control and trust over.

Storing Data Permanently​

Containers are transient by nature. Since a container can be destroyed and re-created, storing data inside the container's filesystem is not a good idea. It is also impossible to share such data with other containers, making it unsafely stored for all the containers(It disappear after removing the container) and hard to manage. Over-the-air updates also need to be taken into account when dealing with container's data, in order to avoid data loss you will need to safely store it. See how to overcome this in the next sub-sections.

Bind Mounts​

You can mount a directory from the host filesystem inside the container to store permanently non-volatile data on the SoM's flash memory. This technique is known as bind mount.

You may need to change or configure your application to store data in that location (or mount the folder where the application expects it).
Also, consider that the files' UID/GID will be shared with the underlying host OS, so using coherent IDs may help. Debian Containers for Torizon use the same users/UIDs and groups/GIDs from the base OS, keeping file permissions always clear.

Volumes​

You can also use docker volumes instead of providing an explicit path on the local filesystem. The runtime manages volumes created via the docker volume command or using docker-compose.

In order to avoid any data lost during updates, develop your container using volumes and bind mounts to keep all the data from your application. It will protect all the data and the updates won't overwrite it.



Send Feedback!