The landscape of containerization on Red Hat Enterprise Linux has undergone a profound architectural and philosophical transformation in recent years, moving away from the traditional Docker package that defined the early days of container adoption. For system administrators, DevOps engineers, and developers operating within the RHEL ecosystem, understanding this shift is not merely an academic exercise but a critical operational necessity. The divergence between the community-supported Docker Engine and the Red Hat-supported Podman ecosystem creates a complex environment where users must carefully choose their tools based on compliance, feature requirements, and enterprise support structures. This comprehensive analysis explores the intricacies of installing, configuring, and managing both Docker Engine and Docker Desktop on RHEL 8, RHEL 9, and RHEL 10, while simultaneously elucidating the broader context of Red Hat’s native container tools. The narrative begins with the fundamental reality that the docker package, once a staple of RHEL installations, is no longer shipped or supported by Red Hat from version 8 onward. This decision was driven by a strategic pivot toward a daemonless architecture provided by Podman, which offers a drop-in replacement for the Docker CLI experience while utilizing buildah for image construction and skopeo for image transport. However, the demand for the specific features, UI, and ecosystem of the official Docker products remains robust, necessitating a detailed understanding of the manual installation procedures required to bring Docker Engine and Docker Desktop into an RHEL environment. This guide exhaustively details the prerequisites, repository configurations, package installation sequences, and post-installation verification steps required for both the server-side Docker Engine and the developer-focused Docker Desktop, ensuring that practitioners can deploy these technologies with precision and confidence.
The Red Hat Container Ecosystem and the Deprecation of the Native Docker Package
To fully appreciate the installation procedures for Docker on RHEL, one must first understand the foundational shift in Red Hat’s strategy regarding container runtimes. From Red Hat Enterprise Linux 8 onwards, the docker package is not available in the standard Red Hat repositories. This is not an oversight but a deliberate architectural decision. The docker container engine has been replaced by podman as the preferred, maintained, and supported container runtime of choice. This transition represents a significant departure from the client-server model employed by traditional Docker, which relies on a persistent background daemon (dockerd) to manage containers. In contrast, podman operates without a daemon, providing a docker compatible command-line experience that allows users to find, run, build, and share containers in a more secure and flexible manner. This compatibility is crucial for organizations that have existing Dockerfiles and scripts, as podman often accepts the same commands as Docker, reducing the friction of migration.
The replacement of the Docker engine also extends to the tooling used for building and transporting container images. The buildah utility has replaced docker build as the preferred, maintained, and supported container image build tool in RHEL 8 and RHEL 9 systems. buildah offers a flexible approach to building OCI container images without requiring a daemon, allowing for the construction of images in unprivileged environments. Similarly, the skopeo utility has replaced docker push as the preferred and supported utility for moving container images between registries and container engines. skopeo provides a robust mechanism for copying images between storage locations, offering features such as signature verification and content-addressable storage that enhance security and reliability. These tools—podman, buildah, and skopeo—form the core of Red Hat’s native container stack, which is deeply integrated into the operating system and receives full support from Red Hat engineers.
For users who are accustomed to the Docker ecosystem or require specific features only available in the official Docker Engine, such as Swarm orchestration or certain Docker-specific configurations, the path forward involves installing Docker from third-party repositories. This requires a clear understanding of the implications, including the lack of direct support from Red Hat for the Docker package itself. The responsibility for maintaining and troubleshooting Docker on RHEL falls on the user or the Docker community, rather than Red Hat. This distinction is critical for enterprise environments where support contracts and liability are paramount. Therefore, the decision to install Docker Engine or Docker Desktop on RHEL is often driven by specific workflow requirements, legacy compatibility needs, or the desire to use the Docker Desktop user interface for development purposes. Regardless of the motivation, the installation process requires careful attention to detail, particularly in managing dependencies and resolving potential conflicts with the native Red Hat container tools.
| Tool | RHEL Native Support | Docker Equivalent | Primary Function |
|---|---|---|---|
| Podman | Yes (RHEL 8+) | docker (CLI) | Container runtime, daemonless |
| Buildah | Yes (RHEL 8+) | docker build | Image building |
| Skopeo | Yes (RHEL 8+) | docker push | Image transport and copying |
| Docker CE | No (Must be installed manually) | N/A | Full Docker Engine and CLI |
| Docker Desktop | No (Must be installed manually) | N/A | GUI and development environment |
Prerequisites and System Requirements for Docker Installation
Before initiating the installation of Docker Engine or Docker Desktop on RHEL, it is imperative to ensure that the system meets the necessary prerequisites. The primary requirement is a maintained version of Red Hat Enterprise Linux, specifically RHEL 8, RHEL 9, or RHEL 10. These versions provide the underlying kernel features and package management infrastructure required for modern containerization. It is crucial to verify that the system is properly registered with the Red Hat subscription manager, as this enables access to the necessary repositories for system updates and dependencies. For Docker Desktop, additional requirements exist, particularly regarding the system architecture and desktop environment. Docker Desktop for RHEL requires a 64-bit version of the operating system, supporting architectures such as x86_64, aarch64, and s390x, depending on the specific Docker package being installed.
A critical step before installing Docker is the removal of any conflicting packages that may have been installed from unofficial sources or previous configurations. Linux distributions, including RHEL, may provide unofficial Docker packages that can conflict with the official packages provided by Docker Inc. These conflicts can lead to installation failures, runtime errors, or unexpected behavior. To mitigate these risks, it is mandatory to uninstall any existing Docker-related packages before proceeding with the official installation. This process involves using the dnf package manager to remove a comprehensive list of potential conflicts. The packages to be removed include docker, docker-client, docker-client-latest, docker-common, docker-latest, docker-latest-logrotate, docker-logrotate, and docker-engine. Additionally, podman and runc should be removed if they are not required for other purposes, as they can also interfere with the Docker installation. It is important to note that dnf may report that none of these packages are installed, which is a normal outcome if the system has not previously had Docker or Podman installed.
Another critical consideration during the uninstallation phase is the preservation of existing data. Images, containers, volumes, and networks stored in /var/lib/docker/ are not automatically removed when Docker is uninstalled. This behavior ensures that user data is not inadvertently lost during the upgrade or reinstallation process. However, it also means that administrators must manually manage this data if they wish to clean up the system or migrate to a new installation. The presence of this data can also affect the behavior of the new Docker installation, as Docker will attempt to use the existing data directory. Therefore, it is advisable to review the contents of /var/lib/docker/ before proceeding with the new installation to ensure that no stale or conflicting data remains. This step is particularly important in environments where multiple container runtimes may have been used over time, as residual data from previous installations can cause issues.
bash
sudo dnf remove docker \
docker-client \
docker-client-latest \
docker-common \
docker-latest \
docker-latest-logrotate \
docker-logrotate \
docker-engine \
podman \
runc
Installing Docker Engine via Repositories on RHEL
The recommended method for installing Docker Engine on RHEL is to set up Docker’s official repositories and install the packages from them. This approach provides the greatest ease of installation and upgrade tasks, allowing the system’s package manager to handle updates and dependencies automatically. By configuring the Docker repository, users ensure that they have access to the latest stable releases of Docker Engine, CLI, and related plugins. This method is particularly suitable for production environments where consistency and reliability are paramount. The process begins by adding the Docker repository to the system’s package manager configuration. This is achieved using the dnf config-manager command, which adds a new repository file to the /etc/yum.repos.d/ directory. The repository file specifies the URL for the Docker packages and defines the priority and enabled status of the repository.
Once the repository is configured, users can list the available versions of Docker Engine to determine the appropriate version for their needs. This is done using the dnf list command with the --showduplicates option, which displays all available versions of the docker-ce package. The output is sorted in reverse order to highlight the most recent versions. The list returned depends on which repositories are enabled and is specific to the version of RHEL being used, as indicated by the suffix in the package name (e.g., .el9 for RHEL 9). Users can then select a specific version by its fully qualified package name, which consists of the package name (docker-ce) plus the version string, separated by a hyphen. For example, to install version 29.4.1 on RHEL 9, the package name would be docker-ce-3:29.4.1-1.el9.
The installation command includes not only the main Docker Engine package but also several essential plugins and components. These include docker-ce-cli for the command-line interface, containerd.io for the container runtime, docker-buildx-plugin for advanced build capabilities, and docker-compose-plugin for multi-container orchestration. Installing these components together ensures a complete and functional Docker environment. It is important to note that this command installs the software but does not start the Docker service. Additionally, the installation creates a docker group, but it does not add any users to this group by default. This security feature prevents unauthorized users from running Docker commands without explicit permission. Administrators must manually add users to the docker group if they require rootless Docker access.
bash
sudo dnf install docker-ce-<VERSION_STRING> docker-ce-cli-<VERSION_STRING> containerd.io docker-buildx-plugin docker-compose-plugin
After the installation is complete, the next step is to start the Docker Engine. This is done using the systemctl command, which configures the Docker systemd service to start automatically when the system boots. The enable --now option ensures that the service is both enabled for future boots and started immediately. If an administrator prefers not to have Docker start automatically, they can use the systemctl start docker command instead, which starts the service for the current session only. This flexibility allows users to tailor the Docker service behavior to their specific operational requirements. Once the service is started, the installation can be verified by running the hello-world image. This test image is a standard Docker artifact that prints a confirmation message when run, indicating that the Docker Engine is functioning correctly.
bash
sudo systemctl enable --now docker
sudo docker run hello-world
Manual Installation of Docker Engine via RPM Packages
In certain scenarios, such as air-gapped systems with no access to the internet or environments with strict security policies, installing Docker from a repository is not feasible. In these cases, users can download the RPM packages directly from the Docker website and install them manually. This method provides greater control over the installation process and ensures that the exact versions of the Docker components are installed. However, it also requires more manual effort, as users must download a new file each time they want to upgrade Docker Engine. The process begins by selecting the appropriate RHEL version and architecture from the Docker download page. The supported architectures include x86_64, aarch64, and s390x, each with its own set of RPM packages.
Users must download five specific RPM files for the Docker Engine, CLI, containerd, and Docker Compose plugins. These files are named according to the version and architecture, such as containerd.io-<version>.<arch>.rpm, docker-ce-<version>.<arch>.rpm, docker-ce-cli-<version>.<arch>.rpm, docker-buildx-plugin-<version>.<arch>.rpm, and docker-compose-plugin-<version>.<arch>.rpm. Once the files are downloaded, they can be installed using the dnf install command, specifying the path to each file. This command installs all the necessary components in a single step, ensuring that dependencies are resolved correctly. As with the repository-based installation, this method creates the docker group but does not add any users to it. The Docker service is not started automatically, so users must manually enable and start the service using systemctl.
bash
sudo dnf install ./containerd.io-<version>.<arch>.rpm \
./docker-ce-<version>.<arch>.rpm \
./docker-ce-cli-<version>.<arch>.rpm \
./docker-buildx-plugin-<version>.<arch>.rpm \
./docker-compose-plugin-<version>.<arch>.rpm
The verification step for the manual installation is identical to that of the repository-based installation. Users run the hello-world image to confirm that the Docker Engine is operational. This step is crucial for ensuring that all components have been installed correctly and that the service is running as expected. In air-gapped environments, it may be necessary to download the hello-world image in advance and import it into the Docker system, as the default behavior is to pull the image from the internet. This additional step highlights the importance of planning and preparation when working in restricted network environments. The manual installation method, while more labor-intensive, offers a robust solution for environments where internet access is limited or prohibited.
Installing Docker Desktop on RHEL: Prerequisites and Repository Setup
Docker Desktop provides a comprehensive graphical user interface for managing Docker containers, images, and Kubernetes clusters, making it an attractive option for developers and system administrators. However, installing Docker Desktop on RHEL requires meeting specific system requirements and prerequisites. First, the system must be running a 64-bit version of RHEL 8, RHEL 9, or RHEL 10. Second, additional repositories and packages must be installed to support the Docker Desktop application. These include the CodeReady Builder repository, which provides essential build tools and libraries, and the EPEL (Extra Packages for Enterprise Linux) repository, which offers additional software packages not included in the standard RHEL distribution.
The CodeReady Builder repository must be enabled using the subscription-manager command. This command varies depending on the RHEL version. For RHEL 10, the command is sudo subscription-manager repos --enable codeready-builder-for-rhel-10-$(arch)-rpms. For RHEL 9, it is sudo subscription-manager repos --enable codeready-builder-for-rhel-9-$(arch)-rpms. For RHEL 8, it is sudo subscription-manager repos --enable codeready-builder-for-rhel-8-$(arch)-rpms. After enabling the CodeReady Builder repository, users must install the EPEL release package using the dnf install command. The EPEL package URL varies by RHEL version, but it typically follows the pattern https://dl.fedoraproject.org/pub/epel/epel-release-latest-<version>.noarch.rpm. Additionally, the pass package must be installed, which is required for managing secrets and credentials in Docker Desktop.
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 users operating within a GNOME desktop environment, additional steps are required to ensure that Docker Desktop integrates properly with the desktop interface. Specifically, the AppIndicator and KStatusNotifierItem GNOME extensions must be installed and enabled. These extensions allow Docker Desktop to display status icons and notifications in the system tray. The installation of these extensions is done using the dnf install command, followed by the gnome-extensions enable command to activate them. For RHEL 8 and 9, the process is similar, with the appropriate EPEL and CodeReady Builder commands for those versions.
bash
sudo dnf install gnome-shell-extension-appindicator
sudo gnome-extensions enable [email protected]
If the user is not using the GNOME desktop environment, they must install gnome-terminal to enable terminal access from Docker Desktop. This requirement ensures that users can interact with the Docker command line even if their primary desktop environment does not natively support the necessary integration features. The installation of gnome-terminal is straightforward and is done using the dnf install command.
bash
sudo dnf install gnome-terminal
Finalizing Docker Desktop Installation and Post-Install Configuration
Once the prerequisites are met, the installation of Docker Desktop on RHEL proceeds by setting up Docker’s package repository and downloading the latest RPM package. The repository is added using the dnf config-manager command, which configures the system to download packages from the official Docker repository. The URL for this repository is https://download.docker.com/linux/rhel/docker-ce.repo. After the repository is configured, users download the latest Docker Desktop RPM package, which is named docker-desktop-x86_64-rhel.rpm for x86_64 systems. The package is then installed using the dnf install command, specifying the path to the downloaded file.
bash
sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo
sudo dnf install ./docker-desktop-x86_64-rhel.rpm
The Docker Desktop RPM package includes a post-install script that performs several critical configuration steps automatically. These steps are essential for the proper functioning of Docker Desktop and include setting the capability on the Docker Desktop binary to map privileged ports and set resource limits. This capability allows Docker Desktop to bind to ports below 1024, which is necessary for many web applications and services. The script also adds a DNS name for Kubernetes to the /etc/hosts file, ensuring that Kubernetes services can be accessed locally. Additionally, the script creates a symlink from /usr/local/bin/com.docker.cli to /usr/bin/docker. This symlink is necessary because the classic Docker CLI is installed at /usr/bin/docker, and the symlink ensures that the Docker Desktop CLI commands are accessible from the standard Docker command path.
These post-installation steps highlight the complexity of integrating Docker Desktop into the RHEL environment. The automatic configuration reduces the burden on the user, but it also underscores the importance of understanding what the installation process entails. For advanced users, it may be necessary to review the post-install script to ensure that it does not conflict with existing configurations or security policies. The integration of Kubernetes support and the mapping of privileged ports are particularly relevant for enterprise users who rely on these features for their development workflows.
Conclusion
The installation of Docker Engine and Docker Desktop on Red Hat Enterprise Linux 8, 9, and 10 represents a nuanced intersection of community-driven innovation and enterprise-grade stability. While Red Hat has strategically moved away from the native docker package in favor of the daemonless podman, buildah, and skopeo stack, the demand for the official Docker ecosystem remains strong. This demand is met through manual installation processes that require careful attention to prerequisites, repository configuration, and package management. The detailed procedures outlined in this analysis provide a comprehensive roadmap for administrators and developers seeking to deploy Docker on RHEL. Whether installing via repositories for ease of maintenance or via manual RPM packages for air-gapped environments, the key to success lies in understanding the underlying dependencies and the implications of each step. The integration of Docker Desktop further expands the capabilities of the RHEL platform, offering a rich graphical interface and Kubernetes support for development workflows. By mastering these installation techniques, users can leverage the full power of containerization on RHEL, bridging the gap between Red Hat’s native tools and the broader Docker ecosystem. The future of containerization on RHEL will likely continue to evolve, with Red Hat refining its native tools while the Docker community maintains its robust suite of features. Understanding both sides of this dynamic is essential for any practitioner operating in the modern cloud-native landscape.