The landscape of containerization within the Red Hat ecosystem has undergone a fundamental architectural shift starting with the release of Red Hat Enterprise Linux (RHEL) 8. For years, Docker served as the industry standard for container orchestration and management, providing a comprehensive suite of tools for building, running, and sharing containers. However, the strategic direction of Red Hat shifted, leading to the removal of the Docker package from the official RHEL repositories in version 8 and subsequent releases, including RHEL 9 and RHEL 10. This transition was not merely a change in software preference but a complete overhaul of how container lifecycles are managed, moving away from a monolithic daemon-based architecture toward a modular, daemonless approach.
The transition represents a move toward the Open Container Initiative (OCI) standards, where Red Hat introduced a suite of tools—Podman, Buildah, and Skopeo—to replace the multi-functional Docker engine. While Docker provided a "one-stop-shop" experience, Red Hat's new approach decouples the different stages of the container lifecycle. This modularity allows for greater security, as it eliminates the need for a root-privileged daemon, and provides more flexibility in how images are constructed and transported. Despite this official pivot, the demand for Docker remains significant, leading to the availability of Docker Desktop for RHEL users who require the specific feature set of the Docker ecosystem.
The Displacement of Docker by the Podman Ecosystem
Starting with Red Hat Enterprise Linux 8, the docker package is no longer shipped or supported by Red Hat. This is not a simple deprecation but a complete replacement of the runtime engine. The primary successor is Podman, which serves as the preferred, maintained, and supported container runtime of choice for RHEL 8, RHEL 9, and RHEL 10.
Podman is designed to provide a command-line experience that is compatible with Docker, meaning that the vast majority of commands used with Docker can be used interchangeably with Podman. This ensures that users can continue to find, run, build, and share containers without a steep learning curve. However, beneath the surface, Podman operates without a central daemon, which addresses specific security concerns and architectural preferences regarding "big fat daemons."
The Red Hat strategy involves a three-pronged toolset to replace the monolithic Docker functionality:
- Podman: Replaces the core Docker engine for running and managing containers.
- Buildah: Replaces the
docker buildcommand as the preferred tool for creating container images. - Skopeo: Replaces the
docker pushanddocker pullfunctionality, serving as the specialized utility for moving container images between different registries and container engines.
The technical reason for this shift is rooted in the desire to have the container runtime lifecycle "baked-in" to the OS or delivered in tandem with OpenShift. By utilizing a daemonless architecture, Red Hat improves system stability and security, as the failure of a single daemon does not jeopardize the entire container stack.
Technical Analysis of the Red Hat Container Toolset
The transition from Docker to a modular stack involves a redistribution of tasks. In the Docker model, the Docker Daemon (dockerd) handles everything from image building to container execution. In the RHEL 8/9/10 model, these tasks are split among specialized binaries.
Podman: The Runtime Engine
Podman (Pod Manager) is the direct replacement for the Docker runtime. It allows users to create, run, and manage containers. Because it is daemonless, it does not require a background process to be running as root, which significantly reduces the attack surface of the host system.
Buildah: The Image Builder
Buildah is the specialized tool for building OCI-compliant images. While Docker uses a Dockerfile and a daemon to build images, Buildah allows for more flexible image creation, including the ability to build images from a scratch container or modify existing images without needing a full container engine running.
Skopeo: The Image Inspector and Transporter
Skopeo is designed for the movement and inspection of container images. It allows a user to examine the contents of a remote registry without needing to pull the image to the local disk first. It effectively replaces the image transport functions of the Docker CLI, facilitating the migration of images between different registries and engines.
Installing and Configuring Docker Desktop on RHEL
Despite the shift toward Podman, Red Hat Enterprise Linux still supports the installation of Docker Desktop for users who prefer the Docker environment or require its specific cloud-integration capabilities. Installing Docker Desktop on RHEL requires meeting specific system requirements and executing a series of administrative steps to enable the necessary repositories.
The installation process varies slightly depending on the version of RHEL being used (8, 9, or 10). The general process involves enabling the CodeReady Builder repository and installing the EPEL (Extra Packages for Enterprise Linux) release package.
Installation Procedures by RHEL Version
For RHEL 10:
bash
sudo subscription-manager repos --enable codeready-builder-for-rhel-10-$(arch)-rpms
sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-10.noarch.rpm
sudo dnf install pass
For RHEL 9:
bash
sudo subscription-manager repos --enable codeready-builder-for-rhel-9-$(arch)-rpms
sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
sudo dnf install pass
For RHEL 8:
bash
sudo subscription-manager repos --enable codeready-builder-for-rhel-8-$(arch)-rpms
sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
sudo dnf install pass
Additionally, users utilizing a GNOME desktop environment must install the AppIndicator and KStatusNotifierItem GNOME extensions to ensure the Docker Desktop UI functions correctly.
Docker Desktop Componentry and Management
Docker Desktop installs Docker Compose V2 and provides an option in the Settings panel to link it as docker-compose. The installation process places the new Docker CLI binary, which includes cloud-integration features, in /usr/local/bin/com.docker.cli and creates a symbolic link to the classic Docker CLI at /usr/local/bin.
Users can manage the Docker Desktop service using systemctl for user-level sessions:
To enable Docker Desktop to start automatically upon sign-in:
bash systemctl --user enable docker-desktopTo stop the Docker Desktop service:
bash systemctl --user stop docker-desktop
Verification of the installation can be performed using the following commands:
bash
docker compose version
docker --version
docker version
Commercial Terms and Licensing for Docker Desktop
Users must be aware that Docker Desktop is not free for all environments. While it may be used freely by individuals or small organizations, commercial use in larger enterprises is subject to paid subscriptions.
| Criteria | Requirement |
|---|---|
| Enterprise Size | More than 250 employees |
| Annual Revenue | More than $10 million USD |
| Requirement | Paid Subscription Required |
Red Hat Universal Base Image (UBI) 9
To support the container ecosystem, Red Hat provides the Universal Base Image (UBI). UBI 9 is designed to be the foundation for containerized applications, middleware, and utilities. It is a freely redistributable image, meaning it can be used and shared without a paid subscription, although Red Hat only provides official support for Red Hat technologies through active product subscriptions.
The image is maintained and updated regularly by Red Hat to ensure security and stability. Users can pull the UBI 9 image using the following command:
bash
docker pull redhat/ubi9:latest-source
Integrating Red Hat Subscription Data with Containers
For users who need to attach Red Hat subscription data to their containers (for example, to access official repositories within the container), specific volume mounts are required. This allows the container to inherit the host's entitlement and repository configuration.
Example command for running a UBI 9 container with subscription data:
bash
docker run --rm -it -v "/etc/pki/entitlement:/etc/pki/entitlement" -v "/etc/rhsm:/etc/rhsm-host" -v "/etc/yum.repos.d/redhat.repo:/etc/yum.repos.d/redhat.repo" registry.access.redhat.com/ubi9
Comparative Analysis: Docker vs. Podman in the RHEL Context
The transition from Docker to Podman reflects a broader shift in the Linux community toward standardization and security.
| Feature | Docker (Traditional) | Podman (RHEL Preferred) |
|---|---|---|
| Architecture | Client-Server (Daemon-based) | Daemonless |
| Privileges | Requires root for daemon | Rootless by default |
| Build Tool | Integrated (docker build) |
Externalized (buildah) |
| Image Transport | Integrated (docker push/pull) |
Externalized (skopeo) |
| RHEL Support | Not supported in RHEL 8+ repos | Fully supported/Maintained |
| CLI Experience | Standard Docker CLI | Docker-compatible CLI |
The "no big fat daemons" philosophy adopted by Red Hat is a primary driver here. By removing the central daemon, Red Hat removes a single point of failure and a potential security vulnerability. If the Docker daemon crashes, all containers on the host can be affected; with Podman, each container is managed as a separate process, increasing the overall resilience of the system.
Critical Perspective on the Transition
The removal of Docker support in RHEL was met with some skepticism within the tech community. Critics, such as Jack Wallen, have noted that the move seemed to occur "out of the blue" and that the justification for replacing a mature, known commodity like Docker with a then-less-mature tool like Podman was not immediately clear to all users.
Some conjectures suggest that the move was driven by a desire for deeper integration with OpenShift or, more cynically, a move by IBM (following its acquisition of Red Hat) to create a level of vendor lock-in by relying on a proprietary or closely controlled runtime environment. However, the official stance from Red Hat emphasizes the technical benefits of a daemonless architecture and the alignment with OCI standards.
Conclusion
The shift from Docker to Podman in Red Hat Enterprise Linux represents a strategic architectural pivot. By replacing the monolithic Docker engine with a modular suite consisting of Podman, Buildah, and Skopeo, Red Hat has aligned its operating system with modern security practices and the Open Container Initiative. While the docker package is absent from the official repositories of RHEL 8, 9, and 10, the compatibility layer provided by Podman ensures that the transition is seamless for most users. For those who absolutely require the Docker Desktop experience, Red Hat provides the necessary infrastructure to install it, provided the user adheres to the commercial licensing terms. The introduction of the Universal Base Image (UBI) 9 further cements Red Hat's commitment to a portable, secure, and redistributable container foundation. Ultimately, the "Deep Drilling" into the RHEL container strategy reveals a preference for modularity, security, and the elimination of centralized daemons, ensuring that the OS remains robust and scalable for enterprise cloud environments.