Docker, Containerd and A LOT OF confusion!

With great innovation and advancement in technology, I think most of IT enginners are some or other way, directly or indirecly, working with technology like docker, but still there is lot of confusion going around it.

Before we talk about docker and its alternative, containerd, we must go back into time and understand how docker was implemented.

If we look back in 2013 when docker was released, we will find that docker was released as a monolithic system. This system provided many services around how to build image, share image and run containers. However, the services provided by docker was independent of each other. Later in time this monolithic system was decomposed and now we have different smaller tool and library. Each of them is providing different services for containers.

Confusion around container runtime engine.

When docker started to focus on smaller units of docker services and these smaller tools started getting mature, vendors like Google, Docker, and other created Open Container Initiative (OCI) and donated project called runc to OCI as a reference implementation for running a container.

We must understand here that runc only tells how to run a container. How you orchestration was never part of this reference. (Later in time reference for building an image was also emerged out of this project).

Low level and high-level container runtime engine.

Container runtimes that focus on just running containers are usually referred to as "low-level container runtimes" like runc. Low level runtimes generally allow you to configure the namespaces and cgroup. These two are important for you to limit the blast radius and resource utilization for containers. Generally, low level runtimes are used by developers who directly engage in building some other services on top of low-level runtime engine.

When we talk about high level container, these are basically doing more than just running the containers, like complete container lifecycle management. One example would be containerd.

containerd official website reads.

"containerd is available as a daemon for Linux and Windows. It manages the complete container lifecycle of its host system, from image transfer and storage to container execution and supervision to low-level storage to network attachments and beyond."

If you see docker architecture, you will find docker itself comprises of docker client, docker runtime engine / daemon and registry.

It is interesting to know that containerd and runc were created by Docker and Founding members of OCI (one is Docker) respectively. Containerd was donated to Cloud Native Compute Foundation (CNCF) and runc was donated to OCI .

Conclusion.

Docker and Containerd can be viewed as alternative to one other as a runtime engine for containers. Containerd is mature enough to manage the complete lifecycle of containers and while looking at docker architecture we would find that docker still needs a runtime engine to manage containers. One of the available options can be containerd for docker to use (docker is currently using containerd as its runtime engine). Also, we should know that the runtime engines (high level) are built upon projects like runc (low level) which supports general reference for running a container. OCI provides a standard way to create and run container images, which ensures compatibility and ease of use across different platforms and environments without any configuration modification.

Let me know your thoughts and feedback in comments, thanks!