With Fedora no longer supporting Docker out-of-the-box (kernel changes are needed https://fedoraproject.org/wiki/Common_F31_bugs#Other_software_issues) and RHEL8 no longer supporting Docker (https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/building_running_and_managing_containers/index) one may wonder if Docker itself has a future.
The reason RedHat give (in the link above) is that they wish to push all users onto their OpenShift solution, obviously useless for personal home labs; I mean who wants to pay for a license just to run a container. Also OpenShift does not permit single node clusters for development.
Both Fedora and RedHat recomend podman (mentioned in both links above) for individual/single-user development and testing of containers. Use of podman on any commercial/business system (or any system with more than one user) is not acceptable from a system management point of view. Using Docker all containers are centrally managed and system admins have a central view of what containers are running so can monitor and manage system resources, with podman however…
- containers built for testing by users reside in their home directories, mutiple users can have their own personal copies of a container; disk space blowout plus no co-ordination needed between users
- containers run by users via podman are spawned by users with their own container engine for each instance as opposed to docker managing all containers, so there is no ‘global’ view of running containers for system admins to use to track container host resource usage or identify what container is causing issues (and multiple users could be running copies of a container causing issues), and no way to even display running containers as they are spawned directly by users without any orchestration engine
- users who should not be playing with containers may play with containers. With Docker only users in the ‘docker’ group can play with containers but any user can run podman (while the podman command could be secured so only users in a docker group could run it any user could obtain their own copy of the podman command)
- any system administrator with a remaining brain cell would refuse to install podman on servers they manage
So effectively development of containers has in RHEL8+ moved to a commercial footing and Fedora can be considerd to have dropped support for it also. However if companies are happy to allow developers to use podman on their own personal/company devices (whether linux devices or using linux VMs) to be deployed to an orchestration engine at a later time that approach is possible and has no more impact on the loss of co-ordinatiin between developers than if all developers were running their own podman tests on a shared host.
However it is also worth noting that the Docker community no longer support/update docker packages in Fedora/CentOS repositories anyway, packages in OS distribution repositories are out of date as docker itself has begun the split between free/commercial, As with many opensource projects there is now a community edition of docker available at the repositories provided by Docker itself (the below was taken from a user forum response at https://forums.mobyproject.org/t/yum-centos-repo-is-broken-https-yum-dockerproject-org-repo-main-centos-7/543 providing the correct documentation for each OS to install Docker, the Fedora entry does mention kernel parameters need to change for F31 so the documentation at those links is being kept up to date).
centos/rhel: https://docs.docker.com/install/linux/docker-ce/centos/ debian: https://docs.docker.com/install/linux/docker-ce/debian/ fedora: https://docs.docker.com/install/linux/docker-ce/fedora/ ubuntu: https://docs.docker.com/install/linux/docker-ce/ubuntu/
As Docker has chosen the community/commercial path it will be interesting to see if a fork occurs such as when Oracle took that path on MySQL resulting in pretty much everybody moving to the fork MariaDB and ditching MySQL altogether (or StarOffice/OpenOffice being replaced by the forked LibreOffice; trying to make parts of a project commercial just makes people switch products). However as Docker is a collection of parts and Docker has with its “Moby” project started seperating parts of the stack into individual components pherhaps only the components needed for a new solution will be forked.
Docker itself at the current point in time has an issue in that it does not have the cgroups2 support needed to run under Fedora31+ and RHEL8+ meaning those sites that use Kubernetes to manage clusters on top of the docker-engine have to either delay upgrading infrastructure OS’s or switch to a new container runtime to be used by Kubernetes and ditch Docker alltogether.
As most clustering environments are cloud based infrastructure whether deployed as bare-metal or VM hosts, with the orchestration engine layer on top of that it simply takes a site to get one template working with a new container runtime engine for their entire environment to be redeployed with the new solution so Docker has a short time-frame to implement cgroups2 support or be replaced. For kubernetes to switch container engines from docker to rkt for example is as simple as setting “–container-runtime=rkt” on the kubelet service startup on eack worker node (if rkt is installed of course).
Obviously if data centers are using docker swarms, migration to an alternative product is going to be a major exercise (personally, all my container hosts have been changed from Fedora30 to CentOS7 to give me time to investigate options as C7 still has another four years before EOL).
However the documentation pages on “coreos.com” where I was looking at the rkt command have a banner at the top of every page stating “These docs are deprecated while they are being migrated to Red Hat. For the most up to date docs, please see the corresponding GitHub repository.”. As the Fedora “Atomic Host” projects have been scrapped since RedHat purchased CoreOS (reference:https://www.projectatomic.io/ and replaced by non-functional fedora CoreOS ‘preview’ images (which I am sure will one day be useful, or not as the Atomic Host images simply did not work in cluster deployment anyway so why would the replacements work) while not affecting a switch to rkt does raise another red-flag that RedHat is forcing users to move toward its products as CoreOS was one day to be the do-all-end-all for cloud deployments but may end up as another commercial (or community/commercial) product.
Personally I hope the Docker team get it together as a Docker ‘swarm’ is a lot easier to setup and keep running than a Kubernetes cluster (if anyone using Kubernetes denies that they have spent days trying to sort out a node ‘not ready’ problem they are telling a lie). While most tutorials on the internet are examples of getting Kubernetes to run using the docker container engine there are many different runtime container engines available other than Docker as discussed in this article containers and their engines on the techgenix site.
RedHats decision to push orchestration of containers to their commercial OpenShift kubernetes product will hurt RedHat more than Docker. While the bulk of non-commercial Linux enthusiasts will just walk away from commercial products entities such as training organisations are not going to switch from a free infrastructure to a paid one so will put emphasis on training for competing products they can run in-house.
What will hurt Docker is that if it cannot support cgroups2 within a few months commercial users that must upgrade their OS’s will have no choice but to stop using docker and switch to an alternative.
Update Jun 27 2020
The docker provided docker-ce package (for el7) now runs correctly on CentOS8 so it looks like that release supports cgroups2 now.
# documentation resource was https://www.liquidweb.com/kb/how-to-install-docker-on-centos-8/ # although the cli now works so downgrade may not be needed dnf config-manager --add-repo=https://download.docker.com/linux/centos/docker-ce.repo dnf list docker-ce dnf install docker-ce --nobest usermod -aG docker root usermod -aG docker mark systemctl enable docker id root id mark systemctl start docker
