What is containerd?

containerd | an industry-standard container runtime

Docker extract its component containerd to accelerate the innovation across the ecosystem and donated it to open foundation. This statement tell 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 high level abstraction of docker architecture. It is an integration of many different components together and that integration gives us a platform which includes everything we need to develop an application, building and deploying them, managing them, etc. So, ultimately it should give the advantages to both dev as well as ops teams who want to build something productive by resolving more problems. The platform will become modular and open always win principal achieved with it. This is the way, we achieved micro-services architecture. Docker is the best example of it.

Docker Engine = Container Platform for Complete Distributed App Lifecycle

Container as a Container Runtime ?

containerd project exist since docker 1.11 to provide execution services for its components with in docker 1.11 which executes containers. So, the container execution and supervision as well as image distribution, network interface management, local storage and a low-level plumbing API that’s a gRPC that higher level systems used to embed containerd with in them. Hence, other major projects like kubernetes and Mesos can do the same.

Why containerd ?

If you look at the trend and success of docker accepting into the IT and how companies redesigning their strategy with docker, you will see their are 10+ billions of pulls in docker hub. Along the way, docker always focus on creating a great experience to all users both developers and operations and continually trying to extract low-level plumbing components as it builds the platform with considering use to a mass innovation.

containerd: container deamon

The role of containerd in the whole container ecosystem here in above image, at the bottom you have all the operating system. Each of these operating systems have an isolation primitives with in them that the containerd will leverage in order to be able to create containers out of it. The OCI(Open Container Initiative) is the standard in that area specifies both the image format and runtime specification for containerd so containerd will adopt OCI through runC. And, then containerd is the common layer that core container runtime that you are using to pull images to run containers on any of these operating system. And, on top of that we can build differentiation and higher level system so on the docker side we have docker on the SwarmKit for orchestration. Amazon have 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 as we can choose between them while running and orchestrating our stack. Then we have kubernetes with different flavors as Openshift by RedHat and Google Container Engine who have their own hosted services. DC/OS on top of MesOS, then, we have cloud foundry ecosystem which currently running runC . Blumix container by IBM is based on cloud foundry.

Benefit to Infrastructure Operators and Providers

• Overcomes limited feature scope that stabilizes over time.
• A commitment to a stable API.
• A community-defined release process which 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 orchestrator.
• 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 reference implementation of OCI specification for the runtime and essentially runC is a command that takes a root file system and adjacent file(container.json) that defines isolation characteristics of a container and runC taking these two elements 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 can not directly communicate with CTR but more intensively it is designed for testing a system and playing with containerd that component you want to embed into a high level systems. But, CTR exposes all the api’s of gRPC in a command line. Then, containerd will let you pull the images from a registry by URL so it’s a low-level registry interface that couldn’t communicated with the high-level registry where you specify for e.g. name of an image container ID at the lower level where you just specify the URL to pull the image from and then it will create root file-system and container using JSON then call runC to run container.

Here, is the roadmap for the containerd project, kindly, visit and get the glimpse of the process and how they tackle the problems arises in the runtime and changing it for betterment, modular approach, future scope, etc. so we can fit it into other systems too.
Happy Containerisation!

Originally published at What is containerd? on educative.io.