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
Docker Engine = Container Platform for Complete Distributed App Lifecycle
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
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
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.
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
View all Courses