Container ≠ Docker

"The times are a changin' ..." - was relevant then, is relevant now!

Technology is evolving at bullet's pace, and the science of containers is turning on its head! Earlier "Containers" meant just one monolithic Docker daemon and basically everything in the container lifecycle was Docker. Right now it's pretty much the opposite.

This post is meant to catch-up on the new projects appearing on the container namespace like containerd, runc, kata containers, cri-o, rkt, how are they different to Docker? and where does Docker stand today?

To make things interesting, here's a timeline of the container space that I have come up with. Lets go through the milestones to see the history of the container evolution till the time Docker appeared in the scene. After going through this we will fallback to the original discussion about container runtimes apart from Docker. Here we go-

-> 1979 AD: 'chroot' system call was introduced in the Unix V7. That marks the beginning of process isolation and segregating file access for each process.

-> 2000 AD: FreeBSD-Jails created, these were used by small shared-environment hosting providers to achieve isolation and also had the option to assign an IP address for each system and configuration.

-> 2001 AD: Linux VServer, with capabilities similar to Jails but now embedded into the Linux kernel.

-> 2004 AD: The first public beta of Solaris Containers was released that combines system resource controls and boundary separation provided by zones

-> 2005 AD: OpenVZ an operating system-level virtualization technology for LinuopenVZ history of containersx which uses a patched Linux kernel for virtualization, isolation, resource management and checkpointing.

-> 2006-2007 AD: Google launched 'Process Containers' for limiting, accounting and isolating resource usage (CPU, memory, disk I/O, network) of a collection of processes. It was renamed "Control Groups (cgroups)" later and merged to Linux kernel 2.6.24.

-> 2008 AD: LXC the first and most complete implementation of Linux container manager was deployed using cgroups and Linux namespaces, and it works on a single Linux kernel without requiring any patches.

-> 2011 AD: Cloud Foundry created 'Warden', which could isolate environments on any operating system, running as a daemon and providing an API for container management.

-> 2013 AD: Let Me Contain That For You (LMCTFY)! Started as an open-source version of Google's container stack, providing Linux application containers. This later merged back to Google's libcontainer and is now a part of the Open Container Foundation.

-> 2014 AD: Enter "Docker". With Docker, containers exploded in popularity. It's no coincidence the growth of docker history of containersDocker and container use goes hand-in-hand.
Similar to Warden, Docker also used LXC in its initial stages and later replaced that container manager with its own library, libcontainer. But there's no doubt that Docker separated itself from the pack by offering an entire ecosystem for container management.  

So our story for today begins post 2014. Where container meant just Docker and its adoption grew in leaps and bounds. The advent of container orchestrators/Frameworks like Apache Mesos, Marathon & Kubernetes made deployments robust. By 2016, the container space was sky-rocketing and docker decided to split the monolith into separate parts, some of which other projects can even build on — that's how containerd happened. That was Docker v1.11.

Containerd is a daemon that acts as API facade for various container runtimes and OS. When using containerd, you no longer work with syscalls, instead you work with higher-level entities like snapshot and container — the rest is abstracted away. If you want to understand containerd even more in depth, there's a design documentation in their GitHub repo - https://github.com/containerd/containerd

Under the hood, containerd uses runc to do all the linux work.

What's not seem to be discussed that much is that with Docker 1.11 another separate component is containerd-shim. This is the parent process of every container started and it also allows daemon-less containers (so e.g. upgrading docker daemon without restarting all your containers, which was a big pain, yay!).

So what is actually Docker nowadays? Docker still provides nice end-to-end experience when it comes to containers especially for developers. Docker consists of several components — the one we are most familiar with is the proprietary and user facing is dockerd. 

Dockerd is the thing that helps you work with volumes, networking or even orchestration. And of course it can launch containers or manage images as well, but containerd is listening on linux socket and this is just translated to calls to its GRPC API. This is a very good post that sums up various moving parts of Docker today.

Unfortunately that's not the end of the story. There's still many projects that we haven't even touched. Let's explore some more container runtimes-

CRI-O is getting a lot of publicity which is an interface to decouple Kubernetes from various runtimes — CRI-O is an implementation of that which is OCI compliant. To this you can plug for example containerd (through cri-containerd) or rkt — where cri-o stands is nicely described in this blogpost. But by default it uses only runc.

RKT is a project originally created by CoreOS, which now belongs to RedHat CoreOS, it is probably the closest to an actual Docker competitor, rkt implements a modern, open, standard container format, the App Container (appc) spec, but can also execute other container images, like those created with Docker.

Singularity is the standard de-facto container runtime in the academic world for running HPC workloads. In the HPC (High Performance Computing) context, scheduling resources is an essential feature that can considerably determine the performance of the system. This type of applications run a wide range of computationally intensive tasks in various fields, some examples including quantum mechanics, weather forecasting, climate research, oil and gas exploration, molecular modeling, biological macromolecules and physical simulations. Centers and companies that use this type of applications cannot run the risk to run Docker on their environment because it simply does not fit their use case. They cannot afford to use a Root owned daemon process and security flaws arising due to that.

Kata containers is another interesting project that provides a secure container runtime with lightweight virtual machines that feel and perform like containers, but provide stronger workload isolation using hardware virtualization technology as a second layer of defense. Kata Containers community is stewarded by the OpenStack Foundation (OSF), which supports the development and adoption of open infrastructure globally.

Podman is an open-source project that is available on most Linux platforms. Podman is a daemonless container engine for developing, managing, and running Open Container Initiative (OCI) containers and container images on your Linux System. Podman provides a Docker-compatible command line front end that can simply alias the Docker cli, `alias docker=podman`.
Containers under the control of Podman can either be run by root or by a non-privileged user. Podman manages the entire container ecosystem which includes pods, containers, container images, and container volumes using the libpod library. Podman specializes in all of the commands and functions that help you to maintain and modify OCI container images, such as pulling and tagging. It allows you to create, run, and maintain those containers created from those images in a production environment.

So thats the container scene now. Comment here with updates as you see it evolving and I will keep updating the post. Agree thats its difficult to catch up, but evolution is good and lets see how far this goes!