This second installment in a series of blog posts on containers will detail some of the solutions that existed before Docker.
Jails were first introduced in FreeBSD 4.0 in 2000. By the time FreeBSD 5.0 was released in 2003, jails had picked up considerably in popularity. Jails are described as an enhancement to chroot. Where chroot only segregated the filesystem, jails segregate users, processes, and networks as well.
Solaris has had a rough few years. Oracle now controls and maintains it, but the OpenSolaris project was killed off. OpenIndiana and the Illumos projects continue where it left off.
Regardless of its history, Solaris's contribution to containers is Zones. Zones are similar in concept to Jails (enhanced chroot), but also take advantage of features included with ZFS ' namely snapshots and cloning. This gives the ability to quickly clone or duplicate a current zone into a new zone.
Now it's time to look at Linux container solutions'¦ this can get a little messy.
OpenVZ is a Linux container solution. It was first released in 2005 by SWSoft, now known as Parallels. Though connected to a private, proprietary company, OpenVZ is open source and available for free.
The previously mentioned container projects have been related to BSD. One fundamental difference between BSD and Linux is that Linux is technically just a kernel. All of the tools that make Linux functional are supplemental and from different projects. For example, the chroot command in Ubuntu Linux comes from the GNU coreutils project.
This distinction between BSD and Linux is quite important in the case of OpenVZ. Because containers require kernel level access, the container code needs to be integrated into the kernel. OpenVZ only released its code as a set of patches and custom-compiled Linux kernels ' they initially never bothered to get their code into the official Linux kernel.
As explained in a recent OpenVZ blog entry, this was a mistake recognized way back in 2005, and the OpenVZ team has been working to get their code integrated into the main Linux kernel since then. This can sometimes be a very slow and painful process'¦ The Xen project went through the same scenario.
OpenVZ has never really gained widespread acceptance in the Linux community. This is unfortunate since it's a very robust project with a large amount of features.
Finally, there's LXC. Well, before we get into LXC, let's talk about Linux Namespaces. A namespace is another term for segregation. Items in different namespaces are unable to collide or conflict with each other. Chroot can be thought of as a simple filesystem namespace.
As we've seen with all the other container projects, they implement features beyond filesystem segregation: users, processes, and the network are all also segregated.
Starting in 2001, the Linux kernel began supporting a series of namespaces. The first was mount namespaces, which can be thought of as an enhanced filesystem namespace. Since then, Linux has added support for UTS, IPC, PID, user, and network namespaces. This article goes into great detail about each of them.
Next, a quick mention about control groups ' otherwise known as cgroups. Cgroups limit the amount of resources a certain process can use. For example, a process could be limited to use just 50% of the total CPU on the server.
Between namespaces and cgroups, the Linux kernel has everything it needs to support a modern container system. And that's exactly what LXC is ' a collection of utilities that interact with namespaces and cgroups.
So, since LXC uses features native to the Linux kernel, this should make it a better choice over OpenVZ, right? I guess that depends on one's opinion of those features.
Security in general is a very subjective and relational topic: what one person is paranoid of can be of no matter to another person. Security has always been a hot topic with LXC. Here are several different articles on the subject.
This part of the series summarized various existing container solutions. You might have noticed the added detail for the Linux-based solutions ' especially LXC. This wasn't a coincidence nor was it the writer's bias. Then why? You'll just have to stay tuned for part three to find out!