Replace Docker!? or “Choose The Right Tool For The Job”
Maybe due to historic frustrations and/or differences of opinion across the container runtime space, some have failed to see that picking the right tool for the job is just as valuable in this context as it is in any other. There have definitely been “party lines” drawn in some circles based on vendor-affiliation, or some basing decisions off the latest arguments on HackerNews. But, let’s ignore that (which, I’ll admit, is good advice generally!) and look at what we are talking about when we compare the Docker toolset to any of
containerd, or any other runtime alternative.
This graph shows a sampling of features you might expect or want from a container platform. You can see clearly that containerd contains only a fraction of the capabilities of either the Docker Desktop stack or the pure Docker engine itself. As a [potentially poor] analogy this is like saying I can take away the IDE that my development team uses and provide them with
/usr/bin/gcc as a drop-in replacement. You might ask: “well then why use containerd?” Because operationally, containerd makes perfect sense as an implementer of the CRI API from Kubernetes, and as a lower layer life-cycle manager under the feature-rich Docker offerings shown above.
Docker is More Than a Container Runtime
To take this same comparison, but look through the lens of open source, let’s take a look at the number of open source projects that are involved in a Docker Desktop installation on macOS:
- opencontainers/runc (OCI)
- containerd/containerd (CNCF)
- kubernetes/kubernetes (CNCF)
- containernetworking/cni (CNCF)
- theupdateframework/notary (CNCF)
- …and more (VPNKit, DataKit, etc.)
Docker, the company, has taken these components–many of them written and maintained over the years by Docker employees–and have created a self-contained developer environment in a freely available product with everything built-in and working out of the box! Yes, you can replace this with your own created stack, utilizing much of the same open source. This will be hard work, but is fully possible. You may also find other answers for some of your needs, and simply use a container runtime if you have other infrastructure to handle the rest of this cloud native stack. This is an amazing offering, supported and updated regularly for free by the same team that brought you the addictively simple and powerful
docker workflow over four years ago. I use it on a daily basis because it just works. And based on Docker’s statistical information, this free product is being used by millions of developers worldwide today.
Docker in the Enterprise
Beyond this desktop stack, Docker has continued to develop an enterprise product that, again, combines a significant number of open source projects, including their own, as a commercial offering. As is normal for any revenue-generating business that has grown up from an initial open source project, Docker, Inc. has had to step through the usual land mines of open source vs. product delineation, and in my opinion have done a good job of maintaining a strong commitment to open source. The Docker engine core is still publicly managed as an open source project on GitHub, and the output of that effort (the community edition) has remained free and without any entanglements to require being a customer of Docker, the company. Those of us who have been around open source for the last decade plus have seen much, much worse. In contrast, Docker has in my opinion dealt with the complex situation of product, revenue pressures, and open source in a reasoned way, introducing the Moby project and many “Kits” along the way to spin out innovation beyond their walls. Some of these–like LinuxKit and BuildKit–have caught the imagination of many well outside the usual Docker circles, and have proven useful to both Docker’s products as well as the open source community at large. In very recent news, Docker has some bragging rights around this enterprise platform as Forrester Research has named them the leader in the enterprise container platform space. While you can bet we at IBM are working to improve and compete with our platform offering here (and we can expect the same from Red Hat, Pivotal, and others) today is a day to recognize Docker has had early success building a competitive platform atop the open source underpinnings.
It’s Docker AND Containerd
So why take the time to write out these thoughts? For one, I want to clarify for my readers the “why” of my current operational focus on containerd. I want containerd to be the best possible core, secure, and stable container runtime for both Docker’s stack, the Kubernetes community, and many additional projects which are finding value in our containerd API and codebase. Secondly, for those trying to understand the choices they have in the container runtime space, I think it is important for people to think through sometimes emotionally-driven responses that ignore the reality of what it means to switch to an alternative.
Finally, I’m about to kick off a series here on my personal blog giving practical migration steps when switching from Docker to containerd as the CRI runtime underneath Kubernetes. As IBM Cloud, GKE, and potentially more public managed Kubernetes offerings switch the CRI-enabled runtime from Docker to containerd, there are a set of learnings I would like to share to help vendors and users through this transition. As I do that, it may appear to some that this is a “Docker versus containerd” discussion rather than a “Docker and containerd” discussion. Hopefully from this post you can see my perspective on these issues, and the fact that I find it totally reasonable to love containerd…and Docker!
This article originated from https://integratedcode.us/2018/10/17/why-i-love-containerd-and-docker/
Phil Estes is a Tigera guest blogger. He is a Distinguished Engineer & CTO for Container and Linux OS Architecture Strategy for the IBM Watson & Cloud Platform division. Phil is currently an OSS maintainer in the Docker (now Moby) engine project, the CNCF containerd project, and is a member of both the Open Container Initiative (OCI) Technical Oversight Board and the Moby Technical Steering Committee. Phil is also a member of the Docker Captains program.