There is much to be said in favor of this approach and I can see why, in the early days of Docker, it made a lot of sense. This article does not get into the detailed pros and cons of the Docker daemon process. The Docker command-line interface (CLI) asks the daemon to do this on your behalf. Ask the kernel to run a container with the right namespace and cgroup, etc.Įssentially the Docker daemon does all the work with registries, images, containers, and the kernel.Commit containers and remove local container images from the host repository.

Make copies of images in a local container storage and to add layers to those containers.

Pull and push images from an image registry.

I can’t claim to understand the motivation behind this but I imagine it seemed like a great idea, at the time, to do all the cool things that Docker does in one place and also provide a useful API to that process for future evolution. In the diagram below, we can see that the Docker daemon provides all the functionality needed to: If you are a Docker user, you understand that there is a daemon process that must be run to service all of your Docker commands. How does Docker work?įirst, let’s be clear about how Docker works that will help us to understand the motivation for Podman and also for Buildah. This article answers those questions and shows how to migrate to Podman.

Also what role does Buildah play? Is Podman deficient in some way that we need both Podman and Buildah to replace Docker? Though there are many blogs and tutorials out there, which I will list later, we in the community have not centralized an explanation of how Docker users move from Docker to Podman and Buildah. I was asked recently on Twitter to better explain Podman and Buildah for someone familiar with Docker.

Install docker rhel