Linux Containers With Docker

This weeks containers flavor is Docker, the Linux container engine. Docker takes a more advanced approach to containers, similar to how Chef treats applications and operating systems. This is containers not just being managed, but being programmed. Docker takes the concept of containers and abstracts it up to a higher level.

The explanation of Docker is fairly straightforward:

Docker is an open-source engine which automates the deployment of applications as highly portable, self-sufficient containers which are independent of hardware, language, framework, packaging system and hosting provider.

I first learned of Docker a few months ago when doing research into VMware alternatives. At the time, the project seemed interesting, but still too young. I was recently reminded of the project while listening to an episode of The Changelog that featured an interview with Solomon Hykes, the creator of Docker. Solomon is also the founder and CEO of DotCloud, a PAAS provider that uses Docker to automate hosting of virtually any web application. The interview piqued my interest and prompted me to give the project another look.

Docker is the most interesting container project I’ve looked at, but unfortunately it also seems to be the least stable. In the few hours I was testing it, I managed to generate three kernel panics. One which was easily reproducible by running a docker command as root, and two which popped up at seemingly random times when interacting with the docker command line tools. I do not know if it is due to Docker, or the underlying lxc tools, but something has gone seriously wrong. To be fair, it could have something to do with running in VMware too, but that seems less likely.

 UPDATE: The maintainers are aware of this bug, and have it documented on GitHub.

However young and unstable the project is today, I believe that Docker looks like the future of systems administration. Like Chef, Docker is raising the bar of what is possible in the data center. The concept of Docker is to treat your entire application environment as a single package, and to be able to move and replicate the package as needed between systems and environments.

The concept has merit, especially when considering the trouble of keeping Linux servers patched and up to date. In a containers environment, each code deployment could come with an entirely new container, one that is patched on the fly as part of the container creation process. If the same container is moved up from test, to QA, to production, each environment is given the exact same system to test against, and the production containers are kept patched and up to date on a much more regular basis than trying to patch them as a separate process. The concept takes a bit of getting used to.

Docker is interesting from a practical standpoint as well, as the entire project is coded in Go, and distributed through the datacenter as a statically linked binary. I’m hoping that there are a lot of Go programmers with a devops lean to them that are interested in advancing the state of the art in the datacenter. Because if there are, Docker is the place to be. I’m not ready to commit my datacenter to the project just yet, but I’ll be keeping a very close eye on it.