First look: Docker is a better way to deploy your apps
An open source Linux container engine taking the world by storm is the newest, leanest, and cleanest way to get your app from development to productionFollow @peterwayner
Docker containers are built out of text written in the Dockerfile, the equivalent of the
make file. There's not much to the syntax. Most of the lines in a Dockerfile will begin with
RUN, which passes the rest of the line to the instance inside the container. These are usually lines that say things like
RUN sudo apt-get install.... Much of the code in the Dockerfile is a shell script for building your machine and installing the software you need.
The real action occurs when you start playing with the other commands that poke holes in the container's flexible layer. The command
ADD . /src maps your current directory and makes it appear inside the container as the directory
src. I used it to put some Web pages for the version of Node.js I fired up inside a container. My Web page appeared to be both outside and inside the virtual world at the same time, but it seems like this is an illusion. Docker is really zipping up your files and passing a copy. You will also poke holes in the container for the TCP/IP ports, mapping the ports of the existing machine to the ports inside the container.
Two clever tricks start the moment when you ask Docker to
build the machine. First, you can start accessing previously built containers from Docker's repositories. Most of the standard distros are there, as well as a number of common configurations with tools like MongoDB. You can
ADD these slices to your Dockerfile and they'll be downloaded to your new machine. The basic repository is public, but the company behind the Docker project is looking into building private repositories for enterprise work.
The second is the way the new machine is built up with slices, much like a coldcut sandwich. Docker is clever enough to keep the changes in layers, potentially saving space and complexity. The changes you make are stored separately as diffs between the containers. These diffs are also mobile, and it's possible to juggle them to deploy your software. Your developers create the container with all the right libraries, then hand it over to the ops staff, which treats it like a little box that just needs to run.
For all of the cleverness, though, it's important to recognize that the software is very new and some parts are being redesigned as I type this. The Docker website says, "Please note Docker is currently under heavy development. It should not be used in production (yet)." The project plans to have an official release of a new version each month. It also notes that the current master branch of the open repository is the current release candidate. You can get it and build it yourself.
From what I saw, Docker is far enough along to be used in lightweight projects that don't overstress the machine or risk damage if something fails. Many report issues with stuck containers and "ghosts" that clog up machines. These can be swept away by restarting everything, a bit of a pain that undermines one of the selling points of the lightning-quick layer of virtualization. The bigger danger for you is that the Docker team will revise the API or add a new feature that trashes your hard work. This is bound to happen because I already stumbled upon several deprecated commands.