Evolution of Linux Containers

Understanding the containerization landscape

Containerization is not a new concept in computer science. Due to Docker zeitgeist, they might seem like a new technology. But, the inception of Linux containers can be traced back to earlier 1980’s when for the first time chroot system call was introduced in UNIX. It brought with it the ability to change the root filesystem for a process and it’s children. This was the first glimpse of operating-system-level virtualization. However, the movement didn’t pace up because the need for virtualization and scalability was not realised then.

The major difference between operating-system-level virtualization and traditional hypervisor-based virtualization is that running another OS on top of the host and emulating hardware is not required by the former while the latter has to do both. More on containers vs hypervisors here.

For someone like me who is trying to understand the entire landscape of Docker or similar containerization technologies. It is essential to know why things are the way they are. By, tracing the entire timeline of Linux containers and Docker landscape we will be able to discover how the features that are available today in containers evolved over the time. However, the timeline stretches to many years and we will only discuss those who had the most impact on the container’s present and future.

1979 — chroot
UNIX introduced chroot in 1979, chroot is an operating system call with the ability to change the filesystem root for a process and it’s children. This was the first building block for Linux containers whose existence without chroot is just not possible. This was built with the purpose of providing isolated disk space for each process.

2000 — FreeBSD Jails
FreeBSD Jails is one of the earliest complete containerization frameworks. It provided more than just disk space isolation. It is one of the earliest to provide user and networking isolation and other process sandboxing features.

2006 — Process Containers
Process Containers was implemented at Google for resource management on a group of processes. The main focus of these process containers was to provide isolation and resource usage control. In 2007, Google renamed it to Control Groups and merged it to the Linux kernel. Cgroups since then is available in all Linux kernels and is widely used for resource management on a collection of processes.

2008 — LXC
LXC aka Linux Containers was a major milestone in containerization history. It was released with a complete implementation of OS-level virtualization. Back then, people were already using VMs for providing scalability and isolation but they were troubled about the overhead of running another OS. Built on top of cgroups and Linux namespaces and language bindings available for many popular high-level programming languages it seemed like a new direction in containerization movement. A brief tutorial on LXC containers can be found here.

LXD

It isn’t a complete rewrite of LXC. It uses LXC underneath. It is a container “hypervisor”. It is composed by a daemon, the command-line interface(LXC) and an OpenStack plugin. It was developed to provide more flexibility and features on top of LXC. The project is backed by Canonical and more info about it can be found here.

2013 — LMCTFY
lmctfy stands for “Let Me Contain That For You”. It was started by Google to provide a container stack for applications running on Linux which has guaranteed performance, near zero overhead. Now, Google has decided to contribute core lmctfy concepts and abstractions to libcontainer. As a result, now no active development is done in LMCTFY.
The libcontainer project was initially started by Docker and now it has been moved to Open Container Foundation.

2013 — Docker
Docker is currently the most popular and widely used container management system. Docker used LXC at the initial stages and later replaced LXC with its own library called libcontainer. However, libcontainer was also moved to runC which was docker’s implementation of containers on top of OCI specification. Docker was first to introduce a complete ecosystem for containers which includes an efficient, layered container image model, a global and local container registries, a CLI, etc. It also took an initiative to implement a container cluster management solution called Docker Swarm. The Docker ecosystem has grown into a collection of open source projects used for plumbing the infrastructure. The entire list of such projects is available here.

2014 — rkt(pronounced “rock-it”)
Rkt is started by CoreOS for fixing some of the major security drawbacks they found in Docker. This project has always been a strong proponent of security for containers. Docker still has some security vulnerabilities but they are fixing them by each version. For example, earlier all Docker processes ran as root user but it was fixed in version 1.10. An excellent post comparing rkt and other container technologies can be found here.

2016 — Windows Containers
Before, Microsoft’s initiative to add container support running Docker containers on windows was not possible. It was made possible by running a virtual machine on Windows which ran the containers. However, due to Windows containers now it is entirely possible to run Docker containers natively on Windows.

So, far we have seen how Linux containers have evolved over the years. However, the Linux container landscape is growing at a tremendous pace under the flagship of Docker.

The Docker project has always tried to break their monolithic codebases into small components. They have always abstracted components out of the Docker project into smaller open source projects. Major projects that came out of the Docker project is discussed below.

1. Docker Engine is used to create and run Docker containers.
2. Docker Compose is used to define multi-container applications using a simple YML based configuration file.
3. Docker Machine is used for easier docker provisioning.
4. Docker Swarm is a native Docker clustering system.
5. Docker Registry is an Open Source docker image distribution hub.
6. Docker initially was built on top of LXC containers. Docker started building libcontainer. Developers from LMCTFY also started contributing to this project and LMCTFY was discontinued.
7. Open Container Initiative was started under the flagship of Docker. It provided runtime-spec and image-spec which provides specifications for the way the application containers are built. Docker donated the OCI specification to the Linux Foundation in 2015.
8. Libcontainer was moved to runC. RunC is Docker’s effort to build containers complying with OCI specification. RunC is a CLI tool for spawning and running containers according to the OCI specification.
9. Containerd is used as an executor for containers that comply with OCI specifications. In Docker, it acts as a daemon to control runC containers. The relationship of containerd with other projects is summarized succinctly here.
10. Recently, added Moby project is another example which reflects the amount of emphasis put on abstracting out components by Docker community. Moby project provides a framework to assemble specialized container systems without reinventing the wheel. It provides various standard components and a framework for assembling them into custom platforms.

So, far we have discussed and traversed the containerization landscape. There are so many projects to cover but I tried to keep it simple and important. We saw how Linux containers evolved and how Docker is driving the containerization space by breaking its projects into different components. This provides an easier contribution to the containerization space and encourages people to build their own custom components.