The landscape of enterprise Linux underwent a seismic shift in early 2022, fundamentally altering how developers and system administrators approach base images for containerization. For years, CentOS 8 served as the gold standard for those requiring a binary-compatible, free version of RedHat Enterprise Linux (RHEL), providing a stable foundation for Docker containers that mirrored the production environment of the world's most prevalent enterprise operating system. However, the announcement that CentOS 8 had reached its end-of-life (EOL) as of January 2022 created a critical inflection point for the industry. The move away from the traditional stable release model toward CentOS Stream necessitated a rigorous re-evaluation of Docker base images, as the unpredictability of a rolling-release stream is antithetical to the primary goal of a Docker image: immutable, reproducible, and stable environments.
Understanding the current state of CentOS 8 within the Docker ecosystem requires an analysis of both the legacy infrastructure and the emerging alternatives. While RHEL 8 continues to be supported—with full support extending to May 2024 and critical security updates continuing until May 2029—it remains a commercial product, which introduces licensing complexities and costs that are undesirable for many development workflows. The void left by the death of CentOS 8 has been filled by a new generation of RHEL-compatible clones designed specifically to maintain the stability and binary compatibility that the original CentOS project promised.
The Obsolescence of CentOS 8 and the Shift to RHEL Compatibility
The transition of CentOS 8 from a stable downstream rebuild of RHEL to an upstream development branch known as CentOS Stream fundamentally changed its utility as a Docker base image. The primary motivation for selecting a base image is the requirement for long-term support (LTS) and a guarantee of backwards compatibility. A distribution that ensures security updates over a decade and maintains a consistent set of packages allows developers to build software that does not break upon a simple image pull.
The failure of CentOS 8 to maintain this path means that using centos:8 as a base image now poses significant security and stability risks. Because it no longer receives official updates, any new vulnerability discovered in the kernel or user-space libraries remains unpatched in the legacy images. Furthermore, the introduction of CentOS Stream, while useful for those contributing to the RHEL ecosystem, lacks the static nature required for production Docker images.
For those seeking a free, binary-compatible replacement for RHEL 8 that mirrors the original CentOS philosophy, three primary options have emerged:
- Oracle Linux: This is a pre-existing clone of RHEL maintained by Oracle. It is available as the
oraclelinuximage on Docker Hub. While Oracle provides commercial support for this distribution, the image can be used entirely for free, making it a direct technical substitute for those who need an established corporate-backed clone. - AlmaLinux: Developed by CloudLinux, a commercial vendor with deep experience in the CentOS ecosystem, AlmaLinux was created specifically to fill the void left by CentOS 8. The
almalinuximage on Docker Hub provides a community-driven, binary-compatible version of RHEL. - RockyLinux: This project was initiated by one of the original creators of CentOS. Its goal is to provide a 1:1 binary-compatible repackaging of RHEL, available via the
rockylinuximage on Docker Hub.
These three alternatives provide the technical equivalent of the old CentOS 8, ensuring that software compiled for RHEL 8 will run without modification, while providing the necessary security patches and package availability, such as Python 3.9, which RedHat has added to the RHEL 8 ecosystem.
Technical Implementation of Docker Engine on CentOS Systems
Installing the Docker Engine on CentOS requires adherence to specific versioning requirements and repository configurations to ensure system stability. Currently, official support for the Docker Engine is focused on maintained versions of the CentOS Stream family, specifically:
- CentOS Stream 10
- CentOS Stream 9
The installation process is predicated on the availability of the centos-extras repository. This repository is essential because it contains the necessary dependencies for the Docker Engine to interface with the host operating system. If this repository has been disabled, it must be re-enabled before proceeding with the installation.
A critical step in the installation lifecycle is the removal of conflicting packages. Linux distributions often provide unofficial or community-maintained versions of Docker that can conflict with the official binaries provided by Docker Inc. To ensure a clean installation, the following command must be executed to purge all legacy Docker components:
sudo dnf remove docker docker-client docker-client-latest docker-common docker-latest docker-logrotate docker-engine
It is important to note that the execution of this command does not remove persistent data. All images, containers, volumes, and networks stored in /var/lib/docker/ are preserved, allowing for a migration to the official Docker Engine without the loss of critical application data.
Advanced Configuration and Version Management in CentOS
Once the environment is cleaned of conflicting packages, the installation of Docker Engine can be achieved through two primary methods: using the official Docker repositories for automated updates or manual RPM installation for strict version control. The recommended approach is the repository method, as it simplifies the upgrade path.
For users who require a specific version of Docker for compatibility reasons, the dnf package manager allows for precise version targeting. To identify available versions, the following command is used:
dnf list docker-ce --showduplicates | sort -r docker-ce.x86_64
The output of this command reveals version strings with the .el9 suffix, indicating compatibility with CentOS Stream 9. To install a specific version, the user must provide the fully qualified package name, combining the package name (docker-ce) and the version string. For example, to install version 3:29.4.1-1.el9, the following command is executed:
sudo dnf install docker-ce-3:29.4.1-1.el9 docker-ce-cli-3:29.4.1-1.el9 containerd.io docker-buildx-plugin docker-compose-plugin
Following the installation, the Docker Engine does not start automatically. The systemd service must be managed to ensure the daemon is active. To enable Docker to start automatically upon system boot, the following command is used:
sudo systemctl enable --now docker
If automatic startup is not desired, the service can be started manually using:
sudo systemctl start docker
To verify that the installation was successful and the daemon is communicating correctly with the Docker Hub registry, the hello-world image should be deployed:
sudo docker run hello-world
This process triggers the download of a minimal test image, confirming that the container runtime is fully operational.
Specialized Dockerfile Construction for Systemd in CentOS
A common challenge when using CentOS-based images is the requirement to run systemd inside a container. By default, Docker containers do not run an init system; however, certain enterprise applications require systemd to manage services. This requires a specific architectural approach to image building and container execution.
To build a base image with systemd capabilities, the docker build command is used to create a local image, such as local/c7-systemd:
docker build --rm -t local/c7-systemd .
Once the base image is prepared, a Dockerfile must be constructed to install the necessary services and enable them via systemctl. A typical configuration for a web server environment would look like this:
dockerfile
FROM local/c7-systemd
RUN yum -y install httpd; yum clean all; systemctl enable httpd.service
EXPOSE 80
CMD ["/usr/sbin/init"]
This Dockerfile performs three critical actions: it installs the Apache HTTP server (httpd), cleans the yum cache to reduce image size, and enables the httpd service within the systemd manager. The command CMD ["/usr/sbin/init"] ensures that the container starts the init process rather than a simple bash shell.
To build this specific image:
docker build --rm -t local/c7-systemd-httpd .
Running a container that utilizes systemd is more complex than a standard docker run command. Because systemd requires access to the host's control groups (cgroups) to manage processes, the cgroups volume must be mounted from the host to the container. The execution command is as follows:
docker run -ti -v /sys/fs/cgroup:/sys/fs/cgroup:ro -p 80:80 local/c7-systemd-httpd
In this command, -v /sys/fs/cgroup:/sys/fs/cgroup:ro mounts the cgroups filesystem as read-only, which is a requirement for systemd to function in a limited context. For users operating on an Ubuntu host, an additional mount is required to avoid runtime errors:
-v /tmp/$(mktemp -d):/run
Furthermore, architects should be aware that legacy CentOS 6 binaries or libraries may expect specific system calls to be accessed via vsyscall mappings, which may require additional kernel-level configurations on the host to ensure compatibility.
Comparison of RHEL-Compatible Base Images
The following table provides a technical comparison of the current viable alternatives to the defunct centos:8 image.
| Feature | Oracle Linux | AlmaLinux | Rocky Linux | CentOS Stream |
|---|---|---|---|---|
| Binary Compatibility | Full RHEL Compatibility | Full RHEL Compatibility | Full RHEL Compatibility | Upstream of RHEL |
| Primary Goal | Enterprise Clone | Community Replacement | Community Replacement | Development Branch |
| Stability Profile | High (LTS) | High (LTS) | High (LTS) | Rolling/Medium |
| Docker Image Name | oraclelinux |
almalinux |
rockylinux |
centos |
| Commercial Support | Available (Oracle) | Available (CloudLinux) | Community Driven | N/A |
| Recommended Use | Production/Enterprise | Production/General | Production/General | Development/Testing |
Conclusion: Strategic Analysis of the CentOS Transition
The transition away from CentOS 8 is not merely a change in image tags but a fundamental shift in the philosophy of enterprise Linux distribution. The death of CentOS 8 signifies the end of the "stable downstream" era and the beginning of a fragmented but diverse ecosystem of RHEL clones. For the technical user, the choice between AlmaLinux, Rocky Linux, and Oracle Linux depends largely on the desired level of corporate backing versus community autonomy.
From a DevOps perspective, the migration to these alternatives is straightforward because they maintain the same binary compatibility. This means that the yum or dnf package managers continue to function identically, and the shared libraries remain consistent with the RHEL 8 specifications. However, the move to CentOS Stream 9 or 10 for host-level Docker installations represents a move toward a more agile, albeit less static, environment.
The ability to run systemd within these containers, as detailed in the technical implementation section, remains a critical requirement for legacy application migration. By correctly mounting cgroups and utilizing the /usr/sbin/init command, administrators can bridge the gap between modern container orchestration and legacy service management. Ultimately, the "death" of CentOS 8 has resulted in a more resilient ecosystem where multiple providers ensure that the stability and security of the RHEL-compatible environment remain accessible without the constraints of a single point of failure.