Debian Containers for Torizon
Introduction
Toradex provides a set of lightweight, Debian-based Docker container images for Torizon, derived from the Debian Slim Image variant of the current Debian stable release. These containers serve as foundations for application development on Torizon, offering a hierarchy of images with minimal installed packages and disabled manual pages.
While you can use any container, Toradex’s containers simplify tasks such as:
- Running graphical applications.
- Accessing specific hardware features like GPU and VPU.
- Utilizing maintained images tested for specific modules.
- Operating without running as root by default.
The container offerings include:
- Console-only base container.
- Container with a modern Wayland-based Weston compositor.
- Qt-Wayland-based container supporting common Qt backends like Wayland and EGLFS.
- Chromium and Cog-based containers for displaying web content and single-page applications.
- .NET Containers for both Console and GUI applications.
- Containers containing Cross-Compilers.
- Containers to test products during the hardware bring-up phase.
Each container builds upon the previous one, adding more features to closely match the minimal dependencies of various applications. Being Debian-based, they allow further package installation using the apt command as required by user applications. The container images are freely available on Docker Hub. These containers are also used as a base when using the templates from the Torizon IDE extension.
This article complies with the Typographic Conventions for Torizon Documentation.
Platform-specific Torizon Debian Containers
We support variations of the same container images for each of the SoC families present in the Toradex portfolio. This is due to the specific userspace libraries needed to properly make use of the vendor-maintained kernels.
Each SoC-specific container will have the SoC family name in the container name. For example, the container responsible for the Wayland-based Weston compositor for the AM62 SoC is named torizon/weston-am62. The same principle applies to, for example, the console-only base Debian image for the i.MX8 platform, torizon/debian-imx8.
Additionally, we provide containers that don't have a platform specifier appended to the image names (using the previous example, this image would be just torizon/weston). These images are used when the upstream kernel is selected to be shipped with Torizon OS (for the i.MX6 and i.MX7 families, for example).
Each SoC-specific container family has a custom Debian package feed maintained by Toradex, with the packages themselves being attested from our GitHub builds under the torizon organization.
Tags and Versioning
Our Debian container images use semantic versioning for releases and are tagged accordingly. Notably, we avoid using the latest tag, which is the default tag when pulling an image without tags. Instead, we recommend users use the CT_TAGS environment variables that are available in all Torizon OS deployments. To learn more, read our dedicated article Torizon OS Containers Tags and Versioning.
Details about our Images
This section gives more details about our Debian-based images and how they can improve the development process.
In contrast with previous versions of Torizon Debian, images are built for the specific architecture of the SoC family (for example, the i.MX8 family only contains 64-bit cores, so all images for those particular devices are only built for the arm64 instruction set architecture) with the exception of the upstream images (those images that do not contain a SoC specifier), which are built for arm64, armv7 and amd64 architectures.
When pulling an image, the architecture choice will match the one of the host, although issuing a --platform specifier such as docker pull --platform=linux ... can be used to forcefully specify the intended architecture. Similarly, when building on top of Torizon images, docker build --pull --platform=<IMAGE_ARCH> ... can be used to enforce the build architecture as well.
Two points from our base image (which are carried through to the other images that inherit from it) are worth highlighting. For this, please take a look at our upstream variant base Dockerfile hosted on GitHub.
Firstly, we configure a default, non-root torizon user inside each container. The user is added to the correct groups by a custom script which simplifies permissions and access to the base Torizon OS system from the container.
COPY users-groups.sh /users-groups.sh
RUN ./users-groups.sh \
&& rm users-groups.sh
Secondly, the enablement of the package repository feed provided by Toradex is performed by the following Dockerfile instructions:
echo "Types: deb\n\
URIs: https://feeds1.toradex.cn/debian/snapshots/$TORADEX_SNAPSHOT\n\
Suites: testing\n\
Components: main non-free\n\
Signed-By: /usr/share/keyrings/toradex-debian-repo.gpg" > /etc/apt/sources.list.d/toradex.sources \
&& echo "Package: *\nPin: origin feeds1.toradex.cn\nPin-Priority: 900" > /etc/apt/preferences.d/toradex-feeds
For more information about how our custom Debian feeds enable hardware acceleration from the container, read our engineering-oriented blog about Hardware Acceleration in Containers.
Aditionally, each image has automated tests for the hardware-specific portions, which guarantee that the hardware and kernel are properly working from the base containers. For more information about tests and our release cycle, refer to our Containers Tags and Versioning page.
You can browse our GitHub repository toradex/torizon-containers and see exactly what is included in each of our Debian images.
Docker Auto Prune
Docker-auto-prune is a systemd service in Torizon OS that periodically removes:
- all stopped containers
- all networks not used by at least one container
- all dangling images
- all dangling build cache
This service is disabled by default because randomly removing a stopped container could lead to container loss. To enable it:
# sudo systemctl enable docker-auto-prune.timer && sudo systemctl start docker-auto-prune.timer
This service is mostly useful during development, when one or more people often push several container images without care for removing them after use.
During production, Docker prune is part of the Application Update process, and thus the Docker Auto Prune service becomes unnecessary.