Docker continues to evolve into a suite of container management services. It manages creation, distribution, orchestration, infrastructure, and security. Docker’s goal was to standardize the various components used to manage containers for better oversight of Docker containers. While this is necessary from Docker’s point of view, for the larger community, it stirs up fear of lock-in. Realizing this, Docker intends to take steps to make its platform more composable so that individual components can be spun off and used by other vendors developing alternate solutions. As one step, Docker has recently open-sourced their core container runtime called containerd.
Containerd?
Containerd has been part of Docker Engine since April 2016. Here is the architecture of Docker Engine that shows how containerd fits in:
Source: Docker.com
Containerd is a core container runtime that is responsible for creation of containers. It’s not meant to be used by developers directly—rather, it is part of Docker Engine. All Docker Engine users have been using containerd since April last year.
This is how containerd fits into a normal workflow:
Source: Docker.com
Containerd is built on top of runC, a container runtime that was also created by Docker, and open-sourced as part of the Open Container Initiative (OCI). The OCI was formed by all major cloud vendors coming together to standardize container technology across the industry. It contains two specifications—a runtime spec, and an image spec. runC is the standard runtime for containers, and is the one used by Docker Engine.
What is containerd used for?
Its main purpose is to help launch containers quickly. For example, it can be used to create 140 containers per second on a laptop. You may never need to spin up so many containers at once, but one place where this can be used well is in cloud IaaS providers like AWS and Azure, and container orchestration tools like DC/OS. To better understand this, let’s look at how containerd fits into the overall Docker ecosystem.
Source: Docker.com
As you can see, containerd interfaces between the OS and the container management layer. Docker’s goal in making containerd open source is that these cloud providers and container orchestrators will embed it as their default runtime.
Containerd and the container orchestrators
Currently, there isn’t consensus on which container runtime to use, and some vendors like DC/OS want a more open approach from Docker. They use their own universal container runtime, stating that “recent moves to embed more and more functionality into the Docker daemon have come at the expense of simplicity, composability and stability.” Specifically, they mention that when the Docker daemon needs a restart, it results in all containers getting stopped.
Cloud Foundry, on the other hand, previously used their own runtime in their container service Garden, but they’ve recently switched to runC. The goal of this move was to embrace the OCI standard, and be more in line with Docker’s direction.
Soon, we can expect to see even more cloud providers following suit and adopting containerd as their runtime. This will improve compatibility between Docker and the ecosystem of container vendors. It also builds credibility for Docker because it gives vendors the freedom to decide which parts of the entire Docker platform they’d like to integrate with their solutions. For many, leveraging the entire Docker Engine would result in bottlenecks as they develop their own platform and need to keep in step with Docker Engine. But by taking just the core functionality of Docker Engine, and leaving the higher-level tasks for their own platform, they have a more realistic solution.
“Boring” infrastructure is now interesting
Knowing this, Docker has intentionally kept containerd really simple. Creating it as a “boring” infrastructure component, they want to keep the feature set as small as possible, and ensure it’s highly stable. This screenshot from the containerd Github repository shows which features are included in containerd, and others that are out of scope:
Source: Github.com
As you can tell, features that are not essential are kept for a higher-level tool like Docker Engine.
Containerd is currently at v0.2.x, and is scheduled for a v1.0 release sometime in Q2 2017. While it doesn’t directly impact you if you create and manage Docker containers, it is an important milestone for the industry. It opens the door for further collaboration between Docker and container platforms, and this can only benefit users across the board. As container components become standardized, it will be interesting to see if they come from within Docker, or from the ecosystem trying to avoid Docker lock-in. In the case of containerd, Docker is having a good run so far.
