Podman (Docker) Containers

Podman is a container management tool integrated into Motorcortex, enabling users to deploy, manage, and monitor containerized applications with ease. It offers compatibility with Docker images and commands, supports hardware access, and can be managed through both command-line and visual interfaces, streamlining the operation and maintenance of Motorcortex systems.

  3 minute read  

Motorcortex has Podman installed by default to allow users to deploy and manage containerized applications. Podman is fully compatible with Docker images, containers and commands. Please refer to the Podman documentation for more information on how to use Podman.

A visual interface for managing Podman containers is available through Cockpit. For more information on using Cockpit in Motorcortex, please refer to our Cockpit documentation.

Hardware Access & Device Mapping

Podman in Motorcortex allows hardware access by mapping the devices using the --device option when running a container. This allows the containerized application to communicate with hardware components connected to the Motorcortex controller.

Real-Time Behaviour

Podman in Motorcortex runs on non-real-time cores of the CPU. Therefore, applications running inside Podman containers do not have real-time capabilities. To ensure real-time performance of the Motorcortex control application, it is recommended to avoid using the cpu options such as --cpuset-cpus when running Podman containers, as this may interfere with the real-time cores.

System versus User Podman Containers/Images

Because Podman is daemonless, it can run containers and manage images in two different scopes: system-wide and user-specific. Podman runs each container as the host user running the Podman container. The host user can be the root user or a non root user. Use sudo podman [command] to run Podman commands as the root user for system-wide containers/images, or run podman without sudo for user-specific containers/images.

Running Podman containers as a service

1. Systemd service units

  • Rootful containers: Create a systemd service file (a .service file in /etc/systemd/system/) that starts the Podman container at boot. Podman can generate this file automatically using podman generate systemd --name <container_name> --files. Then enable the service with sudo systemctl enable <generated_service_file>.

  • Rootless (user) containers: Create a systemd user service file (a .service file in ~/.config/systemd/user/) that starts the Podman container at boot. Podman can generate this file automatically using podman generate systemd --name <container_name> --files. Then enable the service with systemctl --user enable <generated_service_file>. Note: By default the systemd user instance is killed after the last session for the user is closed. The systemd user instance can be started at boot and kept running even after the user logs out by enabling lingering using loginctl enable-linger <username>.

    For more options and details, please refer to the Podman documentation on generating systemd units.

2. Container –restart run option

The container is not an actual service but can be configured to run automatically on boot.

  • Rootful containers: Run the Podman container with the --restart=always option and enable the podman-restart service. The container will automatically restart if it exits while the Podman service is running.
  • Rootless (user) containers: The --restart=always option does not reliably start the container on system boot, even with lingering enabled, because the user runtime and storage may not yet be fully initialized before the podman-restart service is run. To ensure automatic startup on boot, a systemd user service should be used.