The landscape of containerization within Red Hat Enterprise Linux (RHEL) has undergone a seismic shift, moving from the early adoption and popularization of the Docker project to a specialized, modular toolset centered around Podman, Buildah, and Skopeo. To understand the current state of Docker on Red Hat systems, one must analyze the transition from RHEL 7 and RHEL Atomic Host to the modern architectures found in RHEL 8, 9, and 10. This evolution is not merely a change in software packages but a fundamental architectural pivot regarding how container runtimes are managed, how security is handled via the removal of monolithic daemons, and how image management is decoupled from the execution engine.
In the initial phases of container adoption, Red Hat integrated the Docker command and service as the primary mechanism for container development. This integration provided a standardized format for container structures and a command-line interface that became the industry benchmark. However, as the ecosystem matured, Red Hat identified systemic issues with the Docker architecture—specifically the reliance on a central, root-privileged daemon—which led to the strategic decision to deprecate Docker in favor of a daemonless architecture. This transition represents a move toward a more granular, secure, and flexible container strategy that aligns with the broader goals of the Linux foundation and the Open Container Initiative (OCI).
The Architectural Legacy of Docker in RHEL 7 and Atomic Host
In Red Hat Enterprise Linux 7 and RHEL Atomic Host, the Docker project served as the foundational layer for containerized workloads. The system provided a unified docker command and a corresponding docker service that managed the lifecycle of containers.
The technical implementation of Docker in these versions required a specific set of privileges and configurations to operate. Specifically, to execute any docker command in RHEL 7 or RHEL Atomic Host, the user must possess root privileges. This requirement stems from the nature of the Docker daemon, which runs as a persistent background process with root access to the host system to manage network interfaces, storage mounts, and process isolation.
For users seeking deeper technical documentation on the operation of these tools, Red Hat provided integration with the standard Linux manual system. By executing the following command:
man docker
Users could access the primary manual. Furthermore, Red Hat provided granular documentation for specific options through dedicated man pages, such as:
man docker-image
This level of documentation was critical for administrators managing the transition from virtual machines to containerized environments, ensuring that the specificities of image management and container orchestration were well-understood.
The Divergence of Docker Packages in Early RHEL Releases
During the lifecycle of RHEL 7, Red Hat offered two distinct paths for installing the Docker engine, catering to different stability and feature requirements. This bifurcation allowed administrators to choose between a validated, stable environment and a feature-rich, albeit less tested, environment.
The following table details the differences between these two installation paths:
| Package Name | Target Use Case | Stability Profile | Compatibility |
|---|---|---|---|
docker |
Production environments | High / Stable | Optimized for Kubernetes and OpenShift |
docker-latest |
Development / Testing | Lower / Bleeding Edge | Access to newest Docker features |
The docker package was the default for the current release, designed for those who required a version of Docker that was strictly compatible with the versions of OpenShift and Kubernetes supported by Red Hat. Conversely, the docker-latest package allowed users to experiment with the latest features from the Docker project. However, it is critical to note that as of RHEL 7.5, the docker-latest package was officially deprecated. It ceased to provide a newer version of Docker than the standard package, and Red Hat advised users to move away from its use.
The Strategic Shift to Podman, Buildah, and Skopeo in RHEL 8 and 9
Starting with Red Hat Enterprise Linux 8, Red Hat fundamentally changed its container strategy. The docker package is no longer shipped or supported in RHEL 8 or RHEL 9, and it is absent from the official Red Hat repositories. This was not a simple removal of a tool but a replacement of a monolithic architecture with a modular one.
The replacement strategy involved the introduction of three primary utilities: Podman, Buildah, and Skopeo. This transition solved the "big fat daemon" problem, as Podman operates without a central daemon, reducing the attack surface of the host system and allowing for rootless container execution.
The specific roles of these tools are as follows:
- Podman: Replaced the
dockerengine as the preferred, maintained, and supported container runtime. It provides a command-line experience that is highly compatible with Docker, meaning users can find, run, build, and share containers using a syntax very similar to the original Docker CLI. - Buildah: Replaced the
docker buildfunctionality. Buildah is a specialized tool for building container images, allowing users to create images without requiring a running container engine. - Skopeo: Replaced the
docker pushanddocker pulllogic for moving images. Skopeo is a utility designed specifically for inspecting, modifying, and moving container images between different registries and container engines.
This modularity means that the tasks previously handled by a single docker daemon are now split into specialized tools. Podman utilizes Buildah and Skopeo as libraries to handle the building and pushing of images, ensuring that the system remains lean and secure.
Technical Configuration and Security Risks of the Docker Daemon
While Red Hat moved toward Podman, legacy systems or specific use cases in RHEL 7 still allow for the configuration of the Docker daemon to accept external connections. This involves modifying the daemon to listen on a TCP port, which opens a significant security vulnerability.
Red Hat explicitly recommends against configuring the Docker daemon to listen on an external TCP port. The technical reason for this warning is that the Docker daemon does not perform authentication by default. Consequently, any external process or actor that gains access to the TCP port effectively gains root access to the daemon, and by extension, the host system.
If an administrator chooses to accept these risks, the configuration is managed via the /etc/sysconfig/docker file. To enable this, the OPTIONS line must be modified. For example:
OPTIONS='--selinux-enabled --log-driver=journald --signature-verification=false -H tcp://0.0.0.0:2375'
In this configuration, the daemon is set to listen on all interfaces. The specific ports associated with this communication are:
- Port 2375: Used for unencrypted communication with the daemon.
- Port 2376: Used for encrypted communication with the daemon.
Furthermore, the Docker service in these environments is configured to utilize two primary registries for searching and pulling images: the Docker registry (docker.io) and the Red Hat registry (registry.access.redhat.com).
Deep Dive into Red Hat Container Image Structure
Red Hat provides layered images that are designed for transparency and reproducibility. Every layered image provided by Red Hat includes the original Dockerfile used for the build process, located at /root/buildinfo within the container. This removes the need for users to mount external volumes from the host to inspect the build process.
To demonstrate the transparency of these images, a user can run a command to identify the Dockerfile name. For example, using the rsyslog image:
docker run --rm registry.access.redhat.com/rhel7/rsyslog ls /root/buildinfo
This command would return a result such as Dockerfile-rhel7-rsyslog-7.2-21. Once the filename is identified, the user can output the actual contents of the Dockerfile to understand the image layers:
docker run --rm registry.access.redhat.com/rhel7/rsyslog cat /root/buildinfo/Dockerfile-rhel7-rsyslog-7.2-21
The resulting output reveals the technical composition of the image, including the base image (FROM), the maintainer (Red Hat, Inc.), environment variables (ENV), and the specific shell commands used to install software (RUN yum -y update; yum -y install rsyslog; yum clean all), as well as labels for versioning and architecture.
Additionally, for those needing to interact with the container's internals, the use of interactive shells is supported. By using the -i (interactive) and -t (terminal) flags, a user can launch a bash shell inside a container:
docker run -it [image_name] /bin/bash
Without the -i flag, the shell would open and immediately exit, making it impossible to perform manual inspections or changes within the container.
Installation of Docker Desktop on Modern RHEL (8, 9, 10)
Despite the shift to Podman for server-side operations, Docker Desktop is available for users who require the Docker Desktop environment on RHEL distributions. However, this is a distinct product from the RHEL-native container tools and comes with specific commercial requirements.
Commercial use of Docker Desktop in enterprises with more than 250 employees or more than $10 million USD in annual revenue requires a paid subscription. For those meeting the requirements, the installation process varies slightly by RHEL version, requiring the enablement of the codeready-builder repositories and the installation of the EPEL (Extra Packages for Enterprise Linux) release and the pass utility.
The installation commands for different RHEL versions are as follows:
For RHEL 10:
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:
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:
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
Furthermore, for users operating within a GNOME desktop environment, additional software is required for full functionality. Specifically, the AppIndicator and KStatusNotifierItem GNOME extensions must be installed to ensure the Docker Desktop GUI integrates correctly with the system tray.
The Controversy and Logic Behind the Transition
The move from Docker to Podman was not without controversy within the technical community. Some critics argued that Red Hat jettisoned a mature, known commodity (Docker) for a less-mature, relatively unknown piece of software (Podman) without providing sufficient public justification.
From a technical perspective, the primary driver was the elimination of the "big fat daemon." Docker relies on a central daemon that must run as root, creating a potential security vulnerability if the daemon is compromised. Podman's daemonless architecture allows containers to be launched as child processes of the user's shell, enabling "rootless" containers where the user does not need administrative privileges to run a container.
There has been conjecture regarding the business motivations behind this move, specifically following the acquisition of Red Hat by IBM. Some analysts suggested that by developing their own container runtime, Red Hat and IBM could achieve a higher degree of vendor lock-in, as they would no longer be dependent on the Docker project's roadmap. However, the official stance remains focused on the technical and security advantages of the Podman/Buildah/Skopeo ecosystem, which adheres to OCI standards, thereby theoretically avoiding lock-in by ensuring image compatibility across different runtimes.
Conclusion
The trajectory of Docker on Red Hat Enterprise Linux is a case study in the evolution of cloud-native infrastructure. In RHEL 7, Docker was the primary vehicle for containerization, provided in both stable and "latest" versions, though it required root privileges and relied on a monolithic daemon. The transition to RHEL 8 and beyond marked a decisive break from this model. By replacing the docker engine with Podman, Buildah, and Skopeo, Red Hat shifted the responsibility of image building and transport to specialized tools while moving the execution runtime to a daemonless model.
This shift solved critical security concerns related to root access and daemon vulnerabilities, although it introduced a learning curve for users accustomed to the single-binary experience of Docker. While Docker Desktop remains an option for developers on RHEL 8, 9, and 10, the enterprise-grade standard has moved toward the Podman ecosystem. The integration of OCI-compliant images and the transparency provided by including Dockerfiles in /root/buildinfo ensure that while the tools have changed, the ability to inspect, build, and deploy containers remains a core strength of the Red Hat ecosystem.