A Brief History of Containers: From 1970s chroot to Docker 2016
Docker had a big birthday in March, turning 3 and prompting reminiscences about how fast it’s grown before our eyes.
Although the birthday celebration has ended, the occasion had me start yet another trip down memory lane: the history of virtualized containers before Docker seized imaginations and opened the doors to larger container use. For this trip, step into my DeLorean time machine, and with the help of Wikipedia and other sources, let’s journey to 1979, when the concept of containers first emerged.
1979: Unix V7
Note to reader, yes, I was less than 10 years old at the time. During the development of Unix V7 in 1979, the chroot system call was introduced, changing the root directory of a process and its children to a new location in the filesystem. This advance was the beginning process isolation: segregating file access for each process. Chroot was added to BSD in 1982.
2000: FreeBSD Jails
Flash-forward nearly two decades later to 2000, when a
small shared-environment hosting provider came up with FreeBSD jails to achieve clear-cut separation between its services and those of its customers for security and ease of administration. FreeBSD Jails allows administrators to partition a FreeBSD computer system into several independent, smaller systems – called “jails” – with the ability to assign an IP address for each system and configuration.
2001: Linux VServer
Like FreeBSD Jails, Linux VServer is a jail mechanism that can partition resources (file systems, network addresses, memory) on a computer system. Introduced in 2001, this operating system virtualization that is implemented by patching the Linux kernel. Experimental patches are still available, but the last stable patch was released in 2006
2004: Oracle Solaris Containers
2004 Oracle released a Solaris Container that combines system resource controls and boundary separation provided by zones, which were able to leverage features like snapshots and cloning from ZFS.
2005: Open VZ (Open Virtuzzo)
This is an operating system-level virtualization technology for Linu
x which uses a patched Linux kernel for virtualization, isolation, resource management and checkpointing. The code was not released as part of the official Linux kernel.
2006: Process Containers
Process Containers (launched by Google in 2006) was designed for limiting, accounting and isolating resource usage (CPU, memory, disk I/O, network) of a collection of processes. It was renamed “Control Groups (cgroups)” a year later and eventually merged to Linux kernel 2.6.24.
LXC (LinuX Containers) was the first, most complete implementation of Linux container manager. It was implemented in 2008 using cgroups and Linux namespaces, and it works on a single Linux kernel without requiring any patches.
CloudFoundry started Warden in 2011, using LXC in the
early stages and later replacing it with its own implementation. Warden can isolate environments on any operating system, running as a daemon and providing an API for container management. It developed a client-server model to manage a collection of containers across multiple hosts, and Warden includes a service to manage cgroups, namespaces and the process life cycle.
Let Me Contain That For You (LMCTFY) kicked off in 2013 as an open-source version of Google's container stack, providing Linux application containers. Applications can be made “container aware,” creating and managing their own subcontainers. Active deployment in LMCTFY stopped in 2015 after Google started contributing core LMCTFY concepts to libcontainer, which is now part of the Open Container Foundation.
2013: Docker and the Future
That’s my (not so brief) summation of the pre-Docker container landscape. All those iterations had their adopters and devotees, but when Docker emerged in 2013, containers exploded in popularity. It’s no coincidence the growth of Docker and container use goes hand-in-hand.
Just as Warden did, Docker also used LXC in its initial stages and later replaced that container manager with its own library, libcontainer. But I’ve no doubt that Docker separated itself from the pack by offering an entire ecosystem for container management.
With Docker, developers can create and run application containers quickly. And with the release of Docker Hub, developers can download and run application containers even faster.
Within only 3 years, I, like countless others find it difficult to imagine a devops life without the Docker eco-system. I’m loving being a part of of its growth journey and find developing a security product integral to its ecosystem an eye opener on many levels.
Of course, Docker is not alone in this future of containers. In February, CoreOS launched rkt (that’s “rocket” if you want to spell it out) with the intent of becoming a credible alternative to Docker. As InfoWorld succinctly put it: rkt intends to do the same tasks as Docker but do them better when they can.
My team and I have our predictions on where the container space is going but that’s for a different post…. Stay tuned.