Please contain yourself: Exploring containers for virtualization is good
Over the last few months I've noticed a lot of people talking about Linux Containers (LXC) and how amazing they are. I have read that if I don't start using LXC for my deployments then I'm missing out on the new revolution or somehow I'm just not as cool as those other guys. I've seen some flashy marketing during my years in the software engineering field, but I believe this new technology might be worth investigating. I'm going to do my best to sum up the LXC revolution in this post. I'm still learning and exploring the possibilities with the technology but I believe it has a lot of promise and deserves further consideration.
So what is LXC?
Here's what Wikipedia has to say: “LXC (LinuX Containers) is an operating system-level virtualization method for running multiple isolated Linux systems (containers) on a single control host.”
In layman's terms this means LXC is a way to run virtual machines on the same host, sharing the same kernel and memory space. The isolation between LXC instances occurs at the file system and network stack layers. By sharing the same running kernel and memory space there is virtually no difference between the performance of the “host” operating system and the LXC. This is very different from more traditional virtualization technology where the hardware is emulated using a software layer, which causes slow startup times and decreases the performance of the underlying hardware. This is due to the software emulation layer that sits between the physical hardware of the host and the operating system being run on top of the emulated hardware.
How can LXC help with my deployments?
Well remember that I said the isolation in LXC occurs at the file system and network stack layers? One of the most intriguing parts of LXC is this file system isolation. In order to explain how it works I have to ask, have you ever run a “live” Linux operating system (OS) from a CD? Did you ever wonder how, when you run the OS from a read-only CD, you can somehow still make changes to OS? The miracle that makes that possible is called Another Union File System (aufs).
What is aufs?
Let's check Wikipedia again for a definition: “aufs (AnotherUnionFS in version 1, but advanced multi layered unification filesystem since version 2) implements a union mount for Linux file systems.”
aufs is a Linux file system that allows you to mount a new file system that is a union of two other file systems. In the case of my “live” CD example one of the file systems is the read-only CD drive (which contains all of the files necessary to run the OS) and a small temporary read/write file system mapped to memory. So when you make changes to core OS files, like say the network settings of the OS, the file is written to the aufs mounted file system that overlays the modified networking file on top of the read-only file that came from the CD. So aufs gives us the ability to limit what we put into the file system to just what is different (think configuration) from the base OS files on the “live” CD.
How will this be useful in deployments?
So at this point maybe the lights are coming on for you—or they may not, and that's okay. This stuff is kind of hard to wrap your head around. Let me explain why I think this will be important and useful for deployments.
One of the biggest advantages of using traditional virtualization technologies is the ability to package up a single virtual machine (VM) image and pass it around to anyone who wants it. It is completely self contained and requires zero configuration to run. However it does have some disadvantages, like size. Some of these VM images could be huge. They tend to be slow and usually require a lot of memory to support the software-based hardware emulation layer. Now imagine I could keep all of the advantages of the traditional VM image technologies and not have to worry about the disadvantages. That would be LXC.
Well that's not completely true. In order to get the “packagability” of traditional VM images with LXC you need to use an open source framework called Docker (Docker.io). Docker gives us the ability to “contain” our file system configurations and describe the network requirements for an LXC. It gives us the ability to “package” our applications as LXC and easily pass them around just like we would do with traditional VM images.
What's the future of this technology?
I believe that tools like Docker and Google's Let Me Contain That For You (lmctfy) will become very popular in the “deployment” phase of most application release lifecycles. The latest version of OpenStack Havana has built-in support for Docker containers, and I'm going on the record now and predicting that within six months Amazon Web Services will provide a similar capability.
Leave a comment and tell me how you think tools like Docker will be used. Let me know if you think I'm wrong. I like constructive arguments and I am always trying to learn more, so let's have a conversation.