The transition from traditional virtualization to containerization represents a fundamental shift in how system administrators manage disk images and virtual machines. Traditionally, the objective of the system administrator was to reduce operational overhead, increase automation, improve reliability, and enhance security within an organization. Containers have radically improved these metrics by optimizing the deployment, development, and maintenance of applications. By providing isolation and simplicity, containers streamline the management of complex IT ecosystems.
In the Red Hat Enterprise Linux (RHEL) 8 environment, Podman serves as the primary engine for this transformation. Podman is an open-source container engine designed to manage Open Container Initiative (OCI) and container images on Linux machines. One of the most significant architectural departures from legacy systems is that Podman allows non-root users to run containers without the requirement of a daemon. This daemonless architecture is a core security feature, as it removes the single point of failure and the elevated privilege requirements typically associated with container runtimes. Podman is compatible with Docker image formats, ensuring that organizations can migrate existing workflows without rewriting their image libraries.
The concept of the "pod" in Podman is derived from Kubernetes, where a pod acts as a wrapper for one or more containers that share resources. To facilitate this, Podman utilizes the libpod library, which allows for code sharing across different container tools, creating a cohesive ecosystem. This ecosystem is further bolstered by specialized tools like Buildah, used for building container images from Dockerfiles, and Skopeo, which manages the inspection, signing, and manipulation of images across different registries.
For users operating within the Red Hat ecosystem, the Universal Base Image (UBI) is a critical component. UBI provides a certified, lightweight, and self-contained software foundation for application deployment. These images are designed to save storage and network utilization; when multiple applications utilize the same base image, the system avoids redundant data overhead. UBI is essentially a subset of Red Hat Enterprise Linux, and when run on RHEL, the RHEL repositories are automatically enabled for UBI, ensuring seamless integration and update paths.
Podman Deployment and Installation Methodologies
Installing Podman on Red Hat Enterprise Linux 8 can be achieved through several paths depending on the requirements for versioning, security, and custom functionality.
Standard Package Installation
For the majority of users on RHEL 8, the most efficient method of installation is via the container-tools module. This approach ensures that the environment is configured with the necessary dependencies and versions approved by Red Hat.
To install Podman using the module system, the following command is executed as the root user:
dnf module install container-tools -y
Once the installation is complete, the administrator must verify the installation and view the system information to ensure the engine is responsive. This is done using the following commands:
podman --version
podman info
For users specifically operating on CentOS 8, the process is simplified to a direct package installation:
dnf install podman
Specialized Enterprise Installation
In specific enterprise environments, such as those requiring precise versioning for compliance or application compatibility, a more granular installation process is required. This approach is often seen in on-premises installations where the environment must be strictly controlled.
The recommended process for these instances involves two high-level steps:
- Creating a RHEL 8 instance. This instance must be version 8.5 or higher, but strictly lower than version 9. This version window ensures compatibility with the required toolsets.
- Configuring and preparing the host.
Before installing Podman, the host must be prepared with essential OS packages. These include:
- lvm2
- iptables
- sysstat
- net-tools
These packages are installed via the dnf manager. To ensure a clean environment, any previous installations of Docker or Podman must be purged:
sudo dnf remove docker docker-ce podman podman-remote containerd.io
Security configurations must then be addressed. In these specific enterprise guidelines, SELinux is disabled by modifying the /etc/selinux/config file and setting the following parameter:
SELINUX=disabled
With the environment prepared, a specific version of Podman (version 4.2.*) is installed:
sudo dnf install podman-4.2.* podman-remote-4.2.*
If the infrastructure requires a proxy for network traffic, the administrator must modify the /usr/share/containers/containers.conf file. Specifically, the HTTP_PROXY and HTTPS_PROXY environment variables must be added under the [engine] section of the configuration file.
Manual Compilation and Source Build
For advanced users or developers who require the latest features or specific build tags not available in the official repositories, Podman can be compiled from the source. This process requires the installation of a compatible version of Go.
The compilation process begins with cloning the official repository:
git clone https://github.com/containers/podman/
cd podman
The build process utilizes the make command. A standard build including SELinux and seccomp support is executed as follows:
make BUILDTAGS="selinux seccomp" PREFIX=/usr
sudo env PATH=$PATH make install PREFIX=/usr
Build tags allow the user to toggle specific features on or off during compilation. If a user does not want seccomp or SELinux support, they can pass an empty string to the build tags:
make BUILDTAGS=""
sudo make install
For RHEL 8 specifically, Btrfs support must be excluded during the build process because it has been removed. The following build tags are mandatory for RHEL 8 builds:
make BUILDTAGS="btrfs_noversion exclude_graphdriver_btrfs"
The following table details the build tags and their corresponding dependencies:
| Build Tag | Feature | Dependency |
|---|---|---|
| apparmor | apparmor support | libapparmor |
| cni | CNI networking | None |
| excludegraphdriverbtrfs | exclude btrfs | libbtrfs |
| excludegraphdriverdevicemapper | exclude device-mapper | libdm |
| libdmnodeferred_remove | exclude deferred removal in libdm | libdm |
| seccomp | syscall filtering | libseccomp |
| selinux | selinux process and mount labeling | None |
| systemd | journald logging | libsystemd |
It is critical to note that Podman does not officially support device-mapper; therefore, the exclude_graphdriver_devicemapper tag is mandatory. For dependency management, the project utilizes go modules.
The Red Hat Container Toolset Ecosystem
Podman does not operate in isolation. Red Hat provides a suite of tools that work in tandem to manage the entire lifecycle of a container, from creation to security hardening.
Core Management Tools
- Podman: This is the fundamental engine. It manages OCI and container images and allows non-root users to operate containers. It is the primary tool for running containers and supports the Pod concept, which allows multiple containers to share a network and resource namespace.
- Buildah: While Podman can build images, Buildah is the dedicated tool for this purpose. It can utilize existing Dockerfiles to create container images, providing a specialized layer for image construction.
- Skopeo: This tool is dedicated to the management of container images and registries. It allows administrators to inspect, sign, and manipulate containers. Crucially, Skopeo can transform container image formats between OCI and Docker.
Security and State Management
- Udica: Security is a primary concern in RHEL 8. Udica is used to generate tailored SELinux policies for containers. This process, known as hardening, allows Udica to create policies that strictly control how a container accesses system resources, including storage, devices, and networks.
- CRIU: The Checkpoint/Restore In Userspace (CRIU) tool allows for the checkpointing and restoring of containers. This means the state of a running container can be saved and later resumed, which is essential for advanced migration and recovery workflows.
Image Management and UBI Integration
Managing images is a central task in Podman. This involves pulling images from registries, verifying them, and removing them when they are no longer needed.
Working with Images
To remove images from the local machine, the rmi command is used. The -f flag is employed to force the removal of images, which can be specified by name or UUID:
podman rmi [-f] <<image>:<tag>
Example of removing an image by UUID:
podman rmi [-f] a354659655
To view all currently available images on the system, the following command is used:
podman images
Utilizing Universal Base Images (UBI)
Red Hat's UBI is designed for developers who want to focus on the application layer rather than the underlying OS configuration. UBI images are lightweight and self-contained, making them ideal for deployment.
To pull specific UBI images from the registry.access.redhat.com repository, the following commands are used:
For Apache 2.4 with PHP 8.0 (UBI 9):
podman pull ubi9/php-80
For Ruby 2.5 (UBI 8):
podman pull ubi8/ruby-25
Using a Dockerfile to build a PHP container image based on these UBI images provides an efficient way to deploy applications and frameworks based on PHP 8.
Comparative Analysis: Podman vs. Docker
While Podman is designed to be a drop-in replacement for Docker, there are fundamental architectural differences that impact security and operation.
Architectural Differences
The primary distinction lies in the daemon. Docker operates as a daemon—a persistent background process that must be started, enabled, stopped, and restarted. Podman is daemonless. This means there is no central process that can crash and take down all running containers.
Security and Auditing
Podman is considered more secure than Docker due to its native audit logging capabilities. In a containerized environment, auditing is crucial for monitoring the processes running within a container. Because Podman does not rely on a root-privileged daemon, it reduces the attack surface of the host system.
Operational Summary
The following table summarizes the differences between the two runtimes:
| Feature | Docker | Podman |
|---|---|---|
| Architecture | Daemon-based | Daemonless |
| Privileges | Typically requires root | Supports non-root users |
| Security | Centralized daemon risk | Enhanced audit logging |
| Image Support | Docker images | OCI and Docker images |
| Concept | Container-centric | Pod-centric (K8s style) |
Conclusion
The integration of Podman into Red Hat Enterprise Linux 8 marks a significant evolution in container orchestration. By moving away from the daemon-centric model of Docker, Red Hat has provided a more secure, flexible, and scalable environment for both developers and system administrators. The ability for non-root users to execute containers is not merely a convenience but a critical security enhancement that aligns with the principle of least privilege.
The synergy between Podman, Buildah, and Skopeo creates a comprehensive pipeline for container management. From the creation of images using Buildah to the registry manipulation via Skopeo and the final execution via Podman, the workflow is optimized for the modern DevOps lifecycle. Furthermore, the introduction of the Universal Base Image (UBI) reduces the friction of application deployment by providing a certified, lightweight foundation that is deeply integrated with the RHEL ecosystem.
For the administrator, the choice of installation—whether through the container-tools module, a specific versioned enterprise path, or a manual source build—allows for precise control over the environment. The mandatory exclusion of Btrfs in RHEL 8 builds and the requirement for specific build tags highlight the technical precision required to maintain a stable container host. As organizations continue to shift toward microservices architecture, the use of Pods and the integration of SELinux hardening via Udica ensure that these applications are not only portable but also resilient against systemic threats.