The transition of container orchestration and management within the Red Hat ecosystem has seen a pivotal shift toward Podman, particularly within Red Hat Enterprise Linux (RHEL) 8. As the industry moves away from monolithic daemon-based architectures, Podman emerges as a daemonless container engine that aligns with the Open Container Initiative (OCI) standards. In RHEL 8, Podman is not merely an alternative but the primary vehicle for containerization, effectively replacing Docker, which became unavailable in RHEL starting from version 7.5. This architecture allows for greater security, as it removes the need for a root-privileged daemon, and improves system reliability by leveraging the native capabilities of the Linux kernel. For technical professionals, the adoption of Podman on RHEL 8 involves a sophisticated understanding of OS-level dependencies, the Universal Base Image (UBI) ecosystem, and the specific nuances of the container-tools module.
OS Instance Requirements and Versioning
The foundation of a stable Podman deployment on RHEL 8 begins with strict versioning requirements. To ensure compatibility with current container tools and security patches, the environment must be meticulously prepared.
The version of Red Hat Enterprise Linux 8 must be greater than or equal to 8.5, but strictly less than 9. This specific version window ensures that the system possesses the necessary kernel features and package repositories to support Podman 4.2.* and related dependencies without encountering the architectural shifts present in RHEL 9.
The impact of these version constraints is significant for the systems administrator. Using a version older than 8.5 may result in missing dependencies or incompatible binary versions in the AppStream repositories, while attempting to use these specific instructions on RHEL 9 would lead to configuration failures due to the evolution of the OS.
This versioning requirement connects directly to the installation of the container-tools module, as the availability of specific Podman versions is tied to the RHEL 8 release cycle.
RHEL 8 Host Preparation and Package Installation
Before the Podman engine can be deployed, the host operating system must be stripped of legacy container runtimes and equipped with low-level system utilities.
The initial phase of host configuration requires the installation of several critical OS packages. These packages provide the underlying infrastructure for volume management and network monitoring.
- lvm2
- iptables
- sysstat
- net-tools
The presence of lvm2 allows for the management of logical volumes, which is essential when containers require persistent storage mapped to specific disk partitions. iptables is critical for managing the network traffic and firewall rules that govern how containers communicate with the host and external networks. sysstat and net-tools provide the diagnostic capabilities necessary to monitor system performance and network sockets during container execution.
To prevent conflicts and ensure a clean state, any existing Docker or Podman installations must be purged. This is achieved by executing the following command:
sudo dnf remove docker docker-ce podman podman-remote containerd.io
The removal of docker-ce and containerd.io is mandatory because these tools rely on a daemon architecture that can conflict with Podman's daemonless approach. Failure to remove these packages can result in port conflicts or corrupted container networking configurations.
Podman Engine Installation and Software Configuration
Once the host is prepared, the actual installation of the Podman engine can proceed. Depending on the deployment objective, this can be done via package managers or through manual compilation from source.
For standard enterprise deployments, Podman can be installed via the DNF package manager. The recommended version for this specific environment is 4.2.*.
sudo dnf install podman-4.2.* podman-remote-4.2.*
Alternatively, if the environment utilizes the container-tools module, the installation can be simplified using the following command:
yum module install -y container-tools
The use of the container-tools module is an abstraction provided by Red Hat to group related utilities like Podman, Buildah, and Skopeo. This simplifies the lifecycle management of container tools by treating them as a single unit of software.
In environments where a network proxy is required for external communication, the Podman configuration must be adjusted. This involves modifying the /usr/share/containers/containers.conf file. Specifically, the HTTP_PROXY and HTTPS_PROXY environment variables must be added within the [engine] section.
The impact of this configuration is that Podman will be able to pull images from remote registries, such as registry.access.redhat.com, through the corporate proxy. Without this, the podman pull command would fail due to network timeout errors.
Security and SELinux Configuration
Security is a primary driver for the use of Podman on RHEL 8. However, certain infrastructure requirements may necessitate the adjustment of Security-Enhanced Linux (SELinux) settings.
For specific configurations, SELinux may need to be disabled to allow container processes to access host resources without restriction. This is done by modifying the /etc/selinux/config file and setting the following parameter:
SELINUX=disabled
While disabling SELinux removes a layer of mandatory access control, it is sometimes necessary when the container's mount points or volume permissions are not correctly labeled, which would otherwise lead to "Permission Denied" errors despite the user having root privileges.
Podman Manual Compilation and Build Tags
For power users or developers who require a version of Podman not available in the official repositories, manual compilation from source is an option. This process requires the Go programming language and a specific set of build tags.
The compilation process begins with cloning the official repository:
git clone https://github.com/containers/podman/
cd podman
The build process uses a make command where BUILDTAGS are used to enable or disable specific features.
make BUILDTAGS="selinux seccomp" PREFIX=/usr
sudo env PATH=$PATH make install PREFIX=/usr
Build tags are essential for tailoring the Podman binary to the specific hardware and security requirements of the host.
- apparmor: Enables AppArmor support, requiring
libapparmor. - cni: Enables CNI (Container Network Interface) networking.
- seccomp: Enables syscall filtering, requiring
libseccomp. - selinux: Enables SELinux process and mount labeling.
- systemd: Enables journald logging, requiring
libsystemd.
On RHEL 8, a specific constraint exists regarding btrfs support. Because btrfs support has been removed, users must compile Podman without it using the following tags:
make BUILDTAGS="btrfs_noversion exclude_graphdriver_btrfs"
Additionally, the exclude_graphdriver_devicemapper tag is mandatory because Podman does not officially support device-mapper.
Universal Base Image (UBI) Integration
The Universal Base Image (UBI) is a cornerstone of the Red Hat container strategy. UBI provides a lightweight, secure, and portable base for building containerized applications.
UBI images are a subset of RHEL and are designed for high-security environments, such as government bodies, financial sectors, and banking. They allow for the deployment of applications without the need for a full RHEL subscription for every container, as they are available as free software projects.
UBI 8 is fully compatible with RHEL 8 and provides commercially reasonable support on RHEL 7. Conversely, UBI 7 is fully compatible with RHEL 7 and supports specific workloads on RHEL 8.
The UBI ecosystem ensures that the repository of RHEL is automatically enabled for the UBI when run on a RHEL host. This creates a seamless update path where Red Hat rebuilds UBI every six months if RPM updates are available.
Image Management and Operational Workflow
Operating Podman on RHEL 8 involves a set of commands that are intentionally similar to the Docker CLI, allowing for a low learning curve.
To pull a certified container image from the registry.access.redhat.com registry, the podman pull command is used. Examples include:
podman pull ubi9/php-80
podman pull ubi8/ruby-25
The impact of using UBI images is a reduction in image size and an increase in security, as these images contain only the necessary components for the specific language runtime (e.g., PHP 8.0 or Ruby 2.5).
To verify the images currently stored on the local machine, the following command is used:
podman images
For image cleanup, Podman allows the removal of images using the rmi command. The -f flag is used to force the removal of an image, which is particularly useful when the image is being used by a stopped container. Images can be targeted by name or by their unique UUID:
podman rmi [-f] <<image>:<tag>
podman rmi [-f] a354659655
Hyperscience Application Deployment on RHEL 8
Specific enterprise applications, such as Hyperscience v33.1.0 and later, utilize Podman on RHEL 8.4+ as a requirement for deployment.
When installing Hyperscience on a new RHEL 8.4+ instance, the process is straightforward. However, when upgrading from RHEL 7, a multi-step migration is required to ensure data integrity and system stability.
The upgrade path from RHEL 7 to RHEL 8.4+ involves the following sequence:
- Clear all Docker containers to reclaim disk space consumed by legacy images.
- Upgrade the Hyperscience application to version 33.1.0 or later.
- Verify the application's health status.
- Perform the OS upgrade from RHEL 7.x to RHEL 8.4 or later following Red Hat's official upgrade guidelines.
This sequence ensures that the application is software-compatible with the Podman runtime before the underlying OS is switched from the Docker-based RHEL 7 to the Podman-based RHEL 8.
Comparison of Container Tools and Runtimes
The relationship between Docker and Podman on RHEL 8 is one of replacement. While Docker provided the initial momentum for containerization, Podman addresses the architectural weaknesses of the Docker daemon.
| Feature | Docker (Legacy RHEL) | Podman (RHEL 8) |
|---|---|---|
| Architecture | Daemon-based | Daemonless |
| Root Requirement | Requires root daemon | Rootless capability |
| RHEL 8 Support | Not supported | Fully supported |
| CLI Compatibility | Original | High (compatible with Docker CLI) |
| Base Image | Various | Universal Base Image (UBI) |
For users who are accustomed to the Docker CLI, Red Hat provides the podman-docker tool, which allows the user to perform most Docker operations by using the same CLI commands but executing them via the Podman engine.
Detailed Technical Analysis of Podman on RHEL 8
The deployment of Podman on RHEL 8 represents a shift toward a more modular and secure container strategy. By eliminating the central daemon, Redman reduces the attack surface of the host system; a failure in one container does not risk the stability of a central management process.
The reliance on the Universal Base Image (UBI) creates a symbiotic relationship between the host OS and the container. Since UBI is a subset of RHEL, it ensures that the binary compatibility is maintained across different environments. This is critical for developers who build an application on a workstation and deploy it to a production RHEL 8 server.
Furthermore, the ability to customize the Podman binary via build tags allows organizations to strictly control the features available in their environment. For example, excluding btrfs and device-mapper while enabling seccomp provides a hardened environment that only utilizes supported and audited kernel features.
The transition for legacy users (such as those moving from RHEL 7 to 8) is facilitated by the CLI parity between Docker and Podman. However, the real value lies in the integration with systemd for logging and the use of CNI for complex networking, which transforms containers from simple isolated processes into robust, manageable infrastructure components.