Containerizing applications¶
An alternative to packaging your software with RPM is to install your application or service in a Linux container. Deploying applications as containers can be advantageous because the container isolates the application from the OS, as well as from other containers. This means that you can build the application against a different base OS that is not necessarily compatible with AutoSD, with the exception of the kernel application binary interface (ABI). With this framework, you can have multiple applications that use different environments running on a single system.
In addition, containers have other advantages, such as the ability for each container to use different versions of dependencies and the improved robustness, security, and flexibility that comes from the kernel-level application isolation. This isolation forms the mixed-criticality architecture of the AutoSD application environment.
Mixed-criticality workloads
Building a container image for your software¶
A container image is a lightweight, standalone software package that includes the code, tools, libraries, and settings required to run a piece of
software. The configuration for a container image is stored in a file called a Containerfile
.
Prerequisites
- Podman
- An RPM package (
auto-apps
) in an RPM package repository (/var/tmp/my_repo
)
Procedure
-
Create a
Containerfile
that includes the RPM package that you created in Packaging your application source code with RPM: -
Copy the RPM repository from
/var/tmp/my_repo
to the same directory where you have created theContainerfile
file: -
Run
podman build
in the same directory as yourContainerfile
to build the container image, and name the container imageauto-apps
: -
Start a container from your
auto-apps
container image, -
From within the running container, verify that your RPM package is present.
If the auto-apps RPM was embedded successfully in the container, the output of the
rpm -q
command displays the version of your package:
Now that you have a functional auto-apps
container image, you can embed your
containerized applications in the OS image with OSBuild.
Embedding containerized applications in an OS image¶
After creating a container image for your application, you can embed it in an OS image.
Depending on your needs, you can use one of two methods to embed the container image in your operating system image:
- Recommended method: Create the container image and add it to a remote container registry. Then, pull the container image from the remote registry to include in the OS image. This method is the only reliable, reproducible method for OS image builds and is therefore recommended.
- Development method: Create the container image and add it to a local RPM repository. Then, pull the container image from your local repository to include in the OS image. Only use this method to build OS images for development and experimentation purposes.
Embedding container images from a remote registry¶
You can download and embed containerized applications from a remote container image registry when you build an AutoSD operating system (OS) image. Doing so makes the containerized application available for use from within the AutoSD OS after the system boots.
When you use this method, OSBuild pulls a container from a remote container image registry at build time and embeds it in the AutoSD image.
Important
If you want to include containerized applications in an OS image, pulling containers from a secure remote registry is the only reliable, reproducible, and recommended method for production OS image builds. Although you can also containerize applications locally and embed them from local storage when building an OS image, doing so is not the method recommended for building the OS image and is meant only for development or experimental purposes.
Prerequisites
- You are running a Linux-based host on your local machine.
- You have installed the following software on your local machine:
- You have used Git to recursively clone the AutoSD sample images directory.
- You have network access to a remote container image registry.
- You can access a containerized application image on the remote registry. This image can be the
auto-apps
image you built according to Building a container image for your software and then added to the registry. You can also use any other containerized application images available in the registry.
Sample procedure
This sample procedure explains how to create an OSBuild manifest and build an AutoSD operating system image in the qcow2
format
that you can boot in a QEMU virtual machine.
The resulting AutoSD OS image will include a containerized CentOS 10 application image pulled from the quay.io remote container image registry
and installed to /usr/share/containers/storage
in the AutoSD OS.
Note that you can customize the script and the manifest to pull your own containerized application images from any image registry to which you have access.
-
Go to the
sample-images
directory where you have recursively cloned the AutoSD sample images directory. -
Create a build manifest file named
remote_container.mpp.yml
: -
Open the
remote_container.mpp.yml
file in a text editor, add the following YAML code, and save the file:version: '2' mpp-vars: name: remote_container use_containers_extra_store: true pipelines: - name: rootfs build: name:build stages: # Install some special RPMs - type: org.osbuild.rpm options: gpgkeys: - mpp-eval: distro_gpg_keys disable_dracut: true exclude: docs: true inputs: packages: type: org.osbuild.files origin: org.osbuild.source mpp-depsolve: architecture: $arch ignore-weak-deps: true module-platform-id: $distro_module_id baseurl: $distro_baseurl_repo repos: mpp-join: - mpp-eval: image_repos - mpp-eval: extra_repos packages: mpp-join: - mpp-eval: image_rpms - - hostname - openssh-clients - openssh-server - podman - vim - wget excludes: - dracut-config-rescue # Get the CentOS 10 (cs10) base container from a remote container # registry (in this case, quay.io). You can replace these values # with your own registry and containerized application information. - type: org.osbuild.skopeo inputs: images: type: org.osbuild.containers origin: org.osbuild.source mpp-resolve-images: images: - source: quay.io/centos/centos # the source URL of the remote registry and repository tag: stream10-development # the tag for the remote repository name: localhost/cs10 # the name of the application options: destination: type: containers-storage storage-path: mpp-eval: containers_extra_store
-
Make the
automotive-image-builder
file executable: -
Export the value of your hardware architecture to a temporary variable:
-
Run the
automotive-image-builder
script to build an OS image that embeds the remote containerized application:$ sudo ./automotive-image-builder/automotive-image-builder \ --verbose --container \ --include=/var/lib/containers/storage/ \ build \ --distro autosd \ --target qemu \ --mode image \ --build-dir=_build \ --export qcow2 \ remote_container.mpp.yml \ remote_container.$arch.qcow2
Note
You can customize the
automotive-image-builder
command to set other options fordistro
name,mode
,target
, andexport
format. -
Verify that the script has created an AutoSD image file named
remote_container.<arch>.qcow2
in your present working directory.
After you have created the OS image, assuming that you have
installed QEMU, you can boot
the AutoSD image in a virtual machine by using the automotive-image-runner
utility
and verify that the containerized application is included in the built OS image:
-
Run the image in QEMU using the
automotive-image-runner
script:If necessary, substitute the filename of your
.qcow2
image file. -
After the image has booted in QEMU, log in with the user name
root
and the passwordpassword
. -
Verify that your containerized application image is available:
Sample output:
When you build your OS image, OSBuild copies the application container image from the remote container image
registry to your OS image.
As defined in the build manifest file, the containerized application is available at localhost/cs10
and can be run by using Podman.
However, you must first create container configuration files and configure OSBuild to copy these files to the
/etc/containers/systemd
directory in your OS image. For more information about these container configuration files, see
Running containers from systemd
.
Next steps
- If required, you can customize your image further. For more information, see Running containers from
systemd
, Configuring communication between ASIL containers, and Deploying applications in the QM partition.
Additional resources
Embedding local containerized applications¶
You can embed containerized applications from local storage when you build an AutoSD operating system (OS) image. Doing so makes the containerized
application available for use from within the AutoSD OS after the system boots.
This method uses the containers-storage
option in the build manifest so that OSBuild pulls containers from local container image storage at build
time and includes them into the OS image.
Important
Although you can containerize applications locally and embed them when building an OS image, doing so is not the recommended method of building the OS image and is meant only for development or experimental purposes. If you want to include containerized applications in an OS image, pulling containers from a secure remote container image registry is the only reliable, reproducible, and recommended method for OS image builds.
Prerequisites
- You are running a Linux-based host on your local machine.
- You have installed the following software on your local machine:
- You have created a container image named
auto-apps
that contains your application built according to Building a container image for your software - You have used Git to recursively clone the AutoSD sample images directory.
Sample procedure
This sample procedure explains how to create an OSBuild manifest and build an AutoSD operating system image in the qcow2
format
that you can boot in a QEMU virtual machine.
The resulting AutoSD OS image will include a containerized auto-apps application image pulled from local storage
and installed to the /usr/share/containers/storage
directory in the OS.
Note that you can customize the script and the manifest to pull your own containerized application images from local storage.
-
Go to the
sample-images
directory where you have recursively cloned the AutoSD sample images directory. -
Create a build manifest file named
local_container.mpp.yml
: -
Open the
local_container.mpp.yml
file in a text editor, add the following YAML code, and save the file:version: '2' mpp-vars: name: local_container use_containers_extra_store: true pipelines: - name: rootfs build: name:build stages: # Install some special RPMs - type: org.osbuild.rpm options: gpgkeys: - mpp-eval: distro_gpg_keys disable_dracut: true exclude: docs: true inputs: packages: type: org.osbuild.files origin: org.osbuild.source mpp-depsolve: architecture: $arch ignore-weak-deps: true module-platform-id: $distro_module_id baseurl: $distro_baseurl_repo repos: mpp-join: - mpp-eval: image_repos - mpp-eval: extra_repos packages: mpp-join: - mpp-eval: image_rpms - - hostname - openssh-clients - openssh-server - podman - vim - wget excludes: - dracut-config-rescue # Get the auto-apps container image from the local storage - type: org.osbuild.skopeo inputs: images: type: org.osbuild.containers origin: org.osbuild.source mpp-resolve-images: images: - source: "localhost/auto-apps" tag: latest name: "localhost/auto-apps" containers-transport: containers-storage options: destination: type: containers-storage storage-path: mpp-eval: containers_extra_store
-
Make the
automotive-image-builder
file executable: -
Export the value of your hardware architecture to a temporary variable:
-
Run the
automotive-image-builder
script to build an OS image that embeds the remote containerized application: -
Verify that the script has created an AutoSD image file named
local_container.<arch>.qcow2
in your present working directory.
After you have created the OS image, assuming that you have
installed QEMU, you can boot
the AutoSD image in a virtual machine by using the automotive-image-runner
utility
and verify that the containerized application is included in the built OS image:
-
Run the image in QEMU using the
automotive-image-runner
script:If necessary, substitute the filename of your
.qcow2
image file. -
After the image has booted in QEMU, log in with the user name
root
and the passwordpassword
. -
Verify that your containerized application image is available:
Sample output:
When you build your OS image, OSBuild copies the auto-apps
container image to your OS image. Your containerized auto-apps
application is
available at localhost/auto-apps
. You must also create container configuration files and configure OSBuild to copy these files to the
/etc/containers/systemd
directory in your OS image. For more information about these container configuration files, see
Running containers from systemd
.
Next steps
- Now that you have included your containerized application in your OSBuild manifest, you can build your AutoSD image. For more information, see Building an AutoSD image.
- Alternatively, you can continue customizing your image. For more information, see Running containers from
systemd
, Configuring communication between ASIL containers, and Deploying applications in the QM partition.
Additional resources
Running containers from systemd
¶
When you embed a container in an operating system (OS) image, you can start the container manually in the booted system with the podman run
command. However, the container does not start automatically at boot time. To configure a container to start at boot time, you must create a
systemd
service that starts the container at the right time, in the right way.
Quadlet is a tool that optimally runs Podman containers under systemd
. Rather than creating the systemd
service manually, use Quadlet to
automatically generate the corresponding systemd
service unit file at boot time. In this example, create Quadlet files for the sample applications
that are available in the AutoSD sample apps repository. If you want to use your own
containerized software, see the Podman documentation for more information
about creating your own Quadlet configuration files.
Prerequisites
- A container image available inside your OS image at
localhost/auto-apps
embedded according to Embedding containerized applications in the AutoSD image - A custom manifest file, such as the manifest file you created in Embedding RPM packages in the AutoSD image
Procedure
-
Create Quadlet unit files for the
radio-service
andengine-service
services in your sample applicationauto-apps
:radio.container
file[Unit] Description=Demo radio service container Requires=routingmanagerd.socket Wants=engine.service [Container] Image=localhost/auto-apps Volume=/run/vsomeip:/run/vsomeip Exec=/usr/bin/radio-service [Service] Restart=always [Install] WantedBy=multi-user.target
engine.container
file[Unit] Description=Demo engine service container Requires=routingmanagerd.socket [Container] Image=localhost/auto-apps Volume=/run/vsomeip:/run/vsomeip Exec=/usr/bin/engine-service Image=localhost/auto-apps Volume=/run/vsomeip:/run/vsomeip Exec=/usr/bin/engine-service [Service] Restart=always Restart=always [Install] WantedBy=multi-user.target
-
Configure your OSBuild manifest to copy the Quadlet unit files to the
/etc/containers/systemd/
directory during the OS image build process. Modify the manifest file and include a neworg.osbuild.copy
stage in therootfs
pipeline that contains the paths to your Quadlet unit files:- type: org.osbuild.copy inputs: inlinefile1: type: org.osbuild.files origin: org.osbuild.source mpp-embed: id: radio.container path: ../files/radio.container inlinefile2: type: org.osbuild.files origin: org.osbuild.source mpp-embed: id: engine.container path: ../files/engine.container options: paths: - from: mpp-format-string: input://inlinefile1/{embedded['radio.container']} to: tree:///etc/containers/systemd/radio.container - from: mpp-format-string: input://inlinefile2/{embedded['engine.container']} to: tree:///etc/containers/systemd/engine.container
Note
The
path:
option resolves a relative path. In this example, your Quadlet unit files are in the../files
directory.
Additional resources