Slashdot Mirror
Docker Turns 1: What's the Future For Open Source Container Tech?
darthcamaro (735685) writes "Docker has become one of the most hyped open-source projects in recent years, making it hard to believe the project only started one year ago. In that one year, Docker has now gained the support of Red Hat and other major Linux vendors. What does the future hold for Docker? Will it overtake other forms of virtualization or will it just be a curiosity?"
It's a high-level interface to LXC (similar to Solaris Containers, or FreeBSD Jails). If you're not familiar with those, think of it as a combination of:
chroot (virtualized filesystem root)
git (version control where a hash-id guarantees an exact environment)
virtual machines (virtualized networking, process tables)
make (you make a config file describing an image to start from, then all the things to do to set up your application / build environment / whatever)
If you are building a complex product you can write a short Dockerfile which will:
Start with 8dbd9e392a96 - a bare-bones Ubuntu 12.04 image
apt-get install git gcc make libc6-dev
You now have a completely reproducible build machine - Docker builds it and gives you back a hashref. You run it with the right arguments (basically: a path to where your source code is, plus a command to run) and it builds your project reliably (you always have a clean container exactly the way it was when you built it) and quickly (unlike a snapshotted VM there's no need to boot it - in a split second the container comes up and it's running your makefile). More importantly, everyone else working on your project can clone that tag and get /exactly/ your environment, and two years from now people won't be scratching their heads trying to reproduce the build server.
Now let's say you're shipping your product - you're a web company, so you have to package it up for the operations guys to deploy. It used to be you would give a long list of dependencies (unreliable, and kind of a pain for the user); more recently you'd ship a VM image (big, resource-heavy, but at least it escapes dependency hell); with Docker you build an image, publish it on an internal server and give the hashref to the ops guys. They clone it (moderate-sized, resource-friendly) and they get your app with everything required to run it correctly exactly the way QA was running it.
As it's being run they can periodically checkpoint the filesystem state, much like snapshotting a VM. If something goes wrong it's easy to roll back and start up the previous version.
It's a young project and there are still some rough edges, but the benefits are significant. I think in a few years doing builds without a container will be looked at the same way as coding without source control.