Podman Containerization on CentOS

Podman represents a paradigm shift in how containerized applications are managed within the Linux ecosystem, specifically for those utilizing the CentOS family of distributions. As a free, open-source, and Linux-native tool, Podman provides the necessary infrastructure to run, build, share, and deploy applications using containers. Its primary architectural distinction lies in its daemonless nature. Unlike traditional container engines that rely on a centrally managed daemon to handle all requests, Podman operates as a daemonless containerization engine. This structural difference is the primary driver for its rapid adoption among developers who seek a more robust, secure, and flexible replacement for Docker. By removing the central daemon, Podman eliminates a single point of failure and reduces the security overhead associated with elevated privileges.

Within the CentOS landscape, Podman is not merely an alternative but is integrated as the default container engine for the RHEL ecosystem. This integration is most evident in CentOS Stream, where Podman is shipped as a core component to provide a stable yet current platform. CentOS Stream 9, acting as the upstream for Red Hat Enterprise Linux, offers immediate access to the latest Podman features before they are officially incorporated into RHEL 9. This ensures that developers and system administrators can leverage cutting-edge containerization capabilities while maintaining a level of stability suitable for production workloads. For those utilizing CentOS Stream 10 (Coughlan), the integration is even more streamlined, with Podman included by default in non-minimal installations, such as server, server with GUI, and workstation editions.

The capabilities of Podman extend beyond simple container execution. It allows for the comprehensive management of container images, the orchestration of volumes mounted into containers to ensure data persistence, and the creation of pods. Its compatibility with the OCI (Open Container Initiative) standards ensures that images created in other environments can be seamlessly ported to a CentOS environment. Whether the goal is to deploy a simple Nginx web server or to build complex, multi-container microservices architectures, Podman provides the toolset necessary to move from basic container operations to full-scale production workloads.

Deployment Architecture Across CentOS Distributions

The process of installing Podman varies depending on the specific version of CentOS being utilized, reflecting the evolution of the distribution's package management and its relationship with the RHEL ecosystem.

Installation on CentOS 8

For systems running CentOS 8, Podman is not always available in the default base repositories, requiring the addition of the Extra Packages for Enterprise Linux (EPEL) repository. The EPEL repository serves as a critical extension, providing a wider array of high-quality software packages that are not included in the standard distribution.

To initiate the installation on CentOS 8, the EPEL repository must first be installed using the following command:

dnf install epel-release -y

Once the EPEL repository is active, the installation of the Podman engine can be completed with:

dnf install podman -y

Following the installation, users should verify the operational status and version of the software. A basic version check is performed via:

podman --version

In a standard CentOS 8 environment, this may return a version such as podman version 3.0.2-dev. To obtain an exhaustive technical breakdown of the environment, the following command is used:

podman info

The output of podman info provides a dense layer of system specifications, including:

• Host Architecture: Typically amd64.
• Buildah Version: For example, 1.19.8.
• Cgroup Manager: Set to systemd.
• Cgroup Version: v1.
• Conmon Details: Package conmon-2.0.26-3.module_el8.4.0+830+80201c4.x86_64 located at /usr/bin/conmon.
• Kernel Version: Example 4.18.0-193.6.3.el8_2.x86_64.
• OCI Runtime: runc version 1.0.2-dev using go1.15.7.

Installation on CentOS Stream 9

CentOS Stream 9 provides a more integrated experience, as Podman is available in the default repositories. This distribution tracks just ahead of RHEL, making it an ideal platform for users who need the latest features.

The standard installation procedure involves installing Podman along with several essential companion tools that extend its functionality. These include podman-compose for multi-container management, buildah for advanced image construction, and skopeo for image inspection and transport.

The installation command is:

sudo dnf install -y podman podman-compose buildah skopeo

To ensure the installation was successful, users can run:

podman --version

podman info

For users who require the absolute latest version of Podman beyond what is provided in the base repositories, the container-tools module can be enabled. This module allows the system to pull the most recent updates from the RHEL ecosystem. First, list the available modules:

sudo dnf module list container-tools

Then, install the latest version of the module:

sudo dnf module install -y container-tools:latest

Installation on CentOS Stream 10 (Coughlan)

CentOS Stream 10 further simplifies the deployment process. In non-minimal installations—including Server, Server with GUI, and Workstation—Podman is included by default. However, if the software is missing or if a minimal installation was performed, it can be installed via the DNF package manager.

Prerequisites for installation on CentOS Stream 10 include root (administrator) privileges. It is recommended to update the system first to ensure all dependencies are current:

sudo dnf update -y

The system version can be verified by checking the release file:

cat /etc/centos-release

This should return CentOS Stream release 10 (Coughlan).

To install Podman, execute:

sudo dnf install -y podman

This command downloads the Podman binary and all required dependencies. Verification is then performed with:

podman --version

A typical output for this version might be podman version 5.5.1. For those transitioning from Docker, the optional installation of podman-compose is recommended to manage complex, multi-container applications.

Rootless Container Configuration

Rootless containers represent the recommended operational approach for the majority of container workloads. In a traditional rootful environment, the container engine requires root privileges, which creates a significant security risk; if a container is compromised, the attacker potentially gains root access to the host. Rootless containers mitigate this by allowing users to run containers without needing administrative privileges.

Configuring UID and GID Mappings

For rootless containers to function, the system must map the user's UID (User Identifier) and GID (Group Identifier) to a range of subordinate IDs. This allows the user to act as "root" inside the container while remaining a standard user on the host.

Users should first check for existing mappings:

cat /etc/subuid

cat /etc/subgid

If these files are empty or the specific user is missing entries, mappings must be added. For example, to add a range of 65,536 IDs:

sudo usermod --add-subuids 100000-165535 --add-subgids 100000-165535 $USER

After modifying the mappings, the Podman system must be migrated to recognize these changes:

podman system migrate

Verifying Rootless Operationality

To ensure that rootless mode is functioning correctly, users can verify the UID map from within the container's context:

podman unshare cat /proc/self/uid_map

Additionally, running a lightweight Alpine Linux container to check the identity of the process serves as a practical verification:

podman run --rm docker.io/library/alpine:latest id

Container Lifecycle Management

Managing containers involves a series of operations ranging from pulling images to executing and removing containers. Podman's command-line interface is designed to be largely compatible with Docker, easing the transition for experienced users.

Pulling and Executing Containers

The first step in running a container is pulling the image from a registry. To pull a standard Nginx image:

podman pull docker.io/library/nginx:latest

Once the image is local, the container can be started. To run an Nginx web server in detached mode, mapping host port 8080 to container port 80, use:

podman run -d --name webserver -p 8080:80 docker.io/library/nginx:latest

The -d flag ensures the container runs in the background, while --name assigns a human-readable identifier. To verify the container is running:

podman ps

The accessibility of the service can be tested via a simple curl request:

curl http://localhost:8080

For tasks requiring direct interaction with the container's shell, an interactive session can be initiated:

podman run -it --rm docker.io/library/centos:stream9 bash

The -it flags allow for an interactive terminal, and --rm ensures the container is automatically deleted once the session ends.

Container Maintenance and Removal

When a container is no longer needed, it must be stopped and removed to free up system resources. To stop a specific container, such as the Nginx example:

podman stop nginx-container

Once stopped, the container can be permanently deleted:

podman rm nginx-container

Image Management and Customization

Podman provides a comprehensive set of tools for searching, inspecting, and building container images.

Searching and Inspecting Images

Users can search for available images directly from the CLI. To find Debian images:

podman search debian

This returns a table containing the index, name, description, and stars. For more specific searches, such as listing tags for Nginx:

podman search --list-tags docker.io/library/nginx

Before pulling an image, it is often useful to inspect its metadata. This is where skopeo is utilized. To inspect an Nginx image without pulling it:

skopeo inspect docker://docker.io/library/nginx:latest

Managing Local Images

To view all images currently stored on the local host:

podman images

When an image is no longer required, it can be removed:

podman rmi docker.io/library/nginx:latest

To perform a comprehensive cleanup of all unused images, the prune command is used:

podman image prune -a

Building Custom Images with Podman and Buildah

Podman allows users to build custom images using a Containerfile (which is functionally equivalent to a Dockerfile). A sample Containerfile for a Python application on CentOS Stream 9 is structured as follows:

dockerfile FROM quay.io/centos/centos:stream9 RUN dnf install -y python3 python3-pip && \ dnf clean all WORKDIR /app COPY requirements.txt . RUN pip3 install --no-cache-dir -r requirements.txt COPY app.py . EXPOSE 8000 CMD ["python3", "app.py"]

To build this image from the local directory:

podman build -t myapp:latest .

For more advanced build requirements, Buildah is employed. Buildah allows for the construction of images without needing a Dockerfile, providing a more programmatic approach to image creation:

container=$(buildah from quay.io/centos/centos:stream9)

buildah run

Troubleshooting and Advanced Configuration

Despite the streamlined installation process, certain environment-specific issues may arise, particularly regarding permissions and the command-line interface.

Resolving Common Errors

A common error encountered by new users is the podman: command not found message. This typically occurs when the installation was not completed or the binary path is not in the user's shell environment. The solution is to ensure the installation is executed via the correct package manager:

sudo dnf install -y podman

Another frequent issue involves SELinux (Security-Enhanced Linux) errors. When mounting host volumes into a container, SELinux may block access to the files. To resolve this, the :z flag should be appended to the volume mount, which tells Podman to relabel the files with the correct SELinux context:

podman run -v /host/path:/container/path:z nginx

Pods and Systemd Integration

Podman introduces the concept of "Pods," which are groups of one or more containers that share a network namespace and other resources. This allows for a more cohesive management of related services. To verify the status of containers within a pod:

podman ps -a --pod

The output displays the container ID, image, status, ports, and the associated Pod ID and Pod Name. For example, a webserver pod might include a pause container for infrastructure and an Nginx container for the actual service.

Regarding the execution of containers under systemd, it is important to note that certain legacy methods are now deprecated. It is strongly recommended to use Quadlets. Quadlets provide a streamlined way to run containers and pods under systemd, ensuring that containers are managed as system services with proper lifecycle hooks.

Technical Specifications Summary

The following table summarizes the installation and configuration details across the various CentOS versions.

Analysis of Podman as a Container Engine

The transition from daemon-based containerization to the daemonless architecture of Podman represents a fundamental shift in Linux systems administration. The elimination of the daemon is not merely a technical preference but a strategic security advantage. In traditional models, the daemon operates as a privileged process; any vulnerability in the daemon or any container that manages to break out could potentially lead to a full host compromise. Podman's architecture avoids this by launching containers as child processes of the user's shell or systemd, thereby inheriting the user's existing permissions.

The emphasis on rootless containers further strengthens this security posture. By utilizing subordinate UID and GID mappings, Podman allows for a "user-namespace" approach. This ensures that even if a process achieves root privileges inside a container, it remains a non-privileged user on the host. This is critical for multi-tenant environments where security isolation is paramount.

From a performance perspective, Podman's integration with cgroups v1 and v2 (via systemd) allows for precise resource allocation and monitoring. The use of conmon (container monitor) ensures that the container's lifecycle is tracked without the need for a persistent daemon. conmon acts as a small C program that stays with the container, handling logging and exit codes, which minimizes the memory footprint compared to a heavy daemon process.

Furthermore, the synergy between Podman, Buildah, and Skopeo creates a modular toolkit. While Podman handles the running and management of containers, Buildah focuses exclusively on the construction of the image, and Skopeo manages the transport and inspection of images. This separation of concerns allows administrators to optimize each stage of the container lifecycle independently.

Ultimately, Podman on CentOS provides a production-grade environment that balances the need for stability with the desire for modern, secure containerization. The progression from CentOS 8 to CentOS Stream 10 shows a clear trajectory toward deeper integration and ease of use, positioning Podman as the definitive standard for container management within the Red Hat ecosystem.

Sources

1. How to Install and Use Podman on CentOS 8
2. Use Podman on CentOS Stream 9
3. Install and Configure Podman on CentOS Stream 10