With Docker What’s Old Is New Again

A Brief Container History

The earliest incarnation of what we now call containerization technology was the concept of chroot (often called chroot jails) that was added to the Unix toolbox in 1982. Chroot (or Change Root) is a mechanism to provide a dedicated file system tree for processes, with the concept that if a file is not in the provided chroot environment then it is inaccessible from inside the environment.

This was useful for several purposes - particularly for running a process that might need a specific set of libraries that conflicted with the overall operating system. But there were problems too, primarily around security and the ability of privileged root users and processes to break out of the jail and get access to the underlying operating system space.

In 2000, the FreeBSD project introduced the jail capability to their operating system that built upon the concept of chroot but increased its effectiveness by not only separating the file system view, but also segregating users, processes, and network configuration as well.

By 2004 Sun Microsystems had taken the jail concept and combined it with their powerful ZFS file system to create Solaris zones that allowed the cloning and duplication of containers and the creation of dedicated file systems for the containers on disk. A few years later Solaris zones gained the ability to run branded zones that allowed the user to run previous versions of the Solaris operating system or even Linux inside of a special zone. 

Containers in Linux

In 2005 the first Linux based container technology beyond chroot appeared – OpenVZ. While very full featured, it was tied to a commercial company and made the mistake of not integrating into the Linux kernel but rather trying to ship patches and custom kernels.

In the meantime, two important things happened in the Linux world from two different directions:

First, Linux namespaces appeared. Namespaces are a way to segregate processes by giving operating system functions different namespaces in which to operate. This helps avoid conflicts with functions operating in different namespaces. A process running in namespace “A” won’t conflict with a process in namespace “B”.

Secondly, Linux cgroups appeared. Cgroups are a way to limit the amount of resources a process can use. Using cgroups, if I make a policy that says my Apache web server process can only use 10% of the CPU, then cgroups ensure it does not use more than 10% of CPU resources.

The combination of these two technologies gave rise to the LXC project (Linux containers). LXC is a way to use cgroups and namespaces together to provide true containerized environments on Linux. LXC allows you to set resource utilization controls for containers while also segregating things like file systems, users, processes, and network configuration. The net result is you can spin up potentially hundreds of containers on a single host environment (aka server).

Fast-forward to 2013 and that's exactly what the Platform as a Service company dotCloud was doing when they developed an easier way to create portable, single-purpose lightweight LXC containers. Docker was born.

The Docker Difference

So why is Docker taking off so quickly when LXC containers have not? This is partly luck, partly positioning and partly designing a better mousetrap. Docker takes the LXC model and builds in several intelligent additions that make it easier to use.

First, Docker simplifies the building and configuration of containers. With the concept of a text-based Dockerfile that lives with your application, you can build a Docker container custom to your needs by referencing a base image and adding a few lines of code. Very slick.

Secondly, and perhaps more importantly for its initial success, Docker provides a free registry and repository where anyone can share containers others have created. In the early days, this helped quickly build a community around the project while also lowering the bar of entry for new developers who wanted to get started.

So is Docker the endpoint of the container story? Not yet.

The Competitive Landscape

Docker faces competition from a few directions.

Perhaps the most direct is from CoreOS, a Linux distribution purpose-built for running container workloads. They have started their own competitive container specification called RKT (pronounced “rock it”). CoreOS feels Docker the company has changed their focus from creating an open standard to creating a platform that is controlled by Docker.

Chipmaker Intel has recently thrown their hat into the ring by releasing Clear Containers, another purpose-built Linux distribution that attempts to leverage the KVM (Kernel Virtual Machine) features of the Linux kernel to provide a super-lightweight environment that can run containers in true virtual machines.

Docker faces not just newer competitors, but existing ones too. FreeBSD jails are still in wide usage across the internet and have proven to be a long-term viable option. And Solaris Zones still exist in both Oracle Solaris and the various offshoots of OpenSolaris such as Illumos, SmartOS, and OmniOS.

The LXC community is not exactly overjoyed at the success of a technology they feel stands on their shoulders. LXC containers are still a great solution for some workloads or more complex implementations. Whereas Docker is designed to run a single process in the container, some problems may need a more robust solution. This is an area LXC may continue to differentiate.