What is containerd?

Docker extracted its component containerd to accelerate the innovation across the ecosystem and donated it to an open foundation.

This statement tells us everything we want to know about containerd; they open-source Docker’s core container runtime component into a community project. That said, Docker is spinning out a component of a platform called “container runtime” as a high-level abstraction of Docker architecture. The component integrates various components that provide a platform that includes everything needed to develop, build, deploy and manage an application. So, ultimately, it should give advantages to both dev and ops teams who want to build something productive by resolving more problems.

This platform will become modular and achieve the Always win Principlehow micro-services architecture was achieved – Docker is the best example of this.

Docker Engine = Container Platform for Complete Distributed App Lifecycle

Containerd as a Container Runtime

The Containerd project has existed since Docker 1.11 to provide execution services for its components within Docker 1.11, which executes containers. Hence, it provides supervision image distribution, network interface management and local storage, and a low-level plumbing APIApplication Program Interface that’s a gRPCRemote Procedure Call that higher-level systems use to embed containerd within them. Due to this, other major projects like Kubernetes and Mesos can do the same.

Why containerd?

Docker has successfully been accepted into IT. Companies are redesigning their strategy with Docker, which has led to more than 10 billion pulls in the Docker hub. This is because Docker has always focused on being user-friendly when it comes to both development and operations. It also consistently tries to extract low-level plumbing components as it builds the platform, which allows Docker to be conducive to mass innovation.

The role of containerd in the whole container ecosystem is depicted in the image above. At the bottom, you have all the operating systems. Each of these operating systems has isolation primitives within them that containerd will leverage in order to be able to create containers out of it. The OCIOpen Container Initiative is the standard in that area – it specifies both the image format and runtime specification for containerd. Containerd adopts OCI through runC. After this, containerd is the common layer in the core container runtime that is used to pull images to run containers on any of these operating systems. In addition to that, we can build differentiation and a higher-level system so that, on the Docker side, we have Docker on the SwarmKit for orchestration.

Since Amazon has ECS with it, they have a whole proprietary stack that will be able to leverage containerd. Microsoft ACS (Azure Container Service) is using Kubernetes, DC/OS, or Swarm so we can choose between them while running and orchestrating our stack.

Then, we have Kubernetes with different flavors like Openshift by RedHat and Google Container Engine who have their own hosted services. There is DC/OS on top of Mesos, and then we have the cloud foundry ecosystem, which currently runs runC. The Bluemix container by IBM is based on the cloud foundry.

Benefit to infrastructure operators and providers

Containerd:

• Overcomes the limited feature scope that stabilizes over time.
• A commitment to a stable API.
• A community-defined release process that emphasizes quality over new features.
• A reasonable LTS policy comparable to infrastructure projects of similar maturity.
• Collaborative community driven projects run in the open.
• Designed for extensibility to work with all leading container orchestrators.
• Branded separately from Docker so as not to cause undue benefit to a single commercial entity.

Containerd leverages on runC to run containers. runC is the reference implementation of OCI specification for the runtime. Essentially, runC is a command that takes a root file system and adjacent file(container.json) that defines the isolation characteristics of a container. runC takes these two elements and creates what we called a container. Containerd is a daemon that exposes a gRPC API that you can call through a call to CTR. We cannot directly communicate with CTR. However, it is designed for system testing. It does this by playing that specific component with containerd that you want to embed into a high-level system. However, CTR exposes all the API’s of gRPC in a command line. Then, containerd will let you pull the images from a registry by a URL, so it’s a low-level registry interface. This interface will not be able to communicate with the high-level registry where you specify, for example, the name of an image container ID. At the lower level, you just specify t e URL to pull the image from and it creates a root file-system and container using JSON. It will then call runC to run the container.

Here is the roadmap for the containerd project. Kindly, visit and get a glimpse of the process and how they tackle the problems that arise in the runtime. It also shows their drive to effect change, their modular approach, and their future scopeso they can fit it into other systems too.

Happy Containerisation!