Understanding the container-hood
“docker” term is used very loosely, and any time there is an announcement, it causes a bit of confusion.
This happened last year when Kubernetes announced dockershim deprecation as part of v1.20, and there is some confusion now due to the recent licensing changes announcement. Here is my attempt to explain some of the terminology, a little bit of what lives under the hood.
Docker Desktop
Docker Desktop = docker (CLI+UI) + dockerd (daemon) + lot more of stuff
Docker Desktop is something you would install on a workstation. On macOS, it takes care of running a Linux Virtual Machine, managing it, creating all sorts of fine-grained connections between the VM and macOS, and makes it look like docker is running natively on your laptop even though it is running a Linux VM behind the scenes. It also has UI and offers some fancy features, such as image management, and starting a single-node Kubernetes cluster, etc.
One of the alternatives (NOT replacement) for running containers on macOS without Docker Desktop is by using lima. Lima runs Linux Virtual Machines on macOS (and Linux) + containerd, and when used along with nerdctl, you should be able to do a lot of what you can do with Docker Desktop (NOT all of it).
I haven’t used Windows in a really long time so, I will stay away from it — my understanding is that you don’t need Docker Desktop on Windows because Windows has some deep integration to run Linux VM with WSL2.
Main Standards
Open Container Initiative (OCI): This is the specification for container images and running containers. It also provides a reference implementation called ‘runc’.
Container Runtime Interface (CRI): This is the API that Kubernetes uses to control different runtimes that create and manage containers. It just makes it easy to add support for other container runtimes in Kubernetes as long as the runtime follow CRI.
Container Runtime
Containers are implemented using Linux namespaces and cgroups. Container Runtime is broadly used to refer to something that sets up these namespaces and cgroups, runs commands inside these namespaces and cgroups.
High-Level Container Runtime
If you are running applications in a container, you need more than something that just sets up these namespaces and cgroups and runs commands in them. You would need image management (build, pull, list, remove etc.) and container management (create, start, stop, exec, attach, remove, logs etc.). Container Runtimes that provide these additional features to make developer’s life easy can be called high-level container runtimes.
Some of the high-level container runtimes: containerd, cri-o, libpod
Low-Level Container Runtime
The meat of spawning and running containers, creates and sets up namespaces and cgroups, does a bunch of plumbing for networking, file system, and then starts and runs containers.
Some of the low-level container runtimes: runc, crun, lxc (one of the first ones),lmctfy, kata-runtime, gVisor. Most of these are OCI compatible.
gVisor and kata-runtimes run containers in a lightweight VM-like tight sandbox, which is another option if you are looking for a more secure runtime.
Container Ecosystem
I tried to put the ecosystem and tools together in a single picture to understand what happens when you run your applications in a container. Containers 101 is a free, good refresher course to understand the basics. And if you want to dig deeper into some of these components, there are a lot more in-depth articles
Docker (the company) played a crucial role in influencing us to use containers, built many open-source tools around them, and continues to back many of them.
