Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

First look: Docker is a better way to deploy your apps

Peter Wayner | March 6, 2014
A long time ago, a computer program was a stack of punch cards, and moving the program from computer to computer was easy as long as you didn't drop the box. Every command, instruction, and subroutine was in one big, fat deck. Editors, compilers, and code repositories have liberated us from punch cards, but somehow deploying software has grown more complicated. Moving a program from the coding geniuses to the production team is fraught with errors, glitches, and hassles. There's always some misconfiguration, and it's never as simple as carrying that deck down the hall.

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.

The development team is also starting to tackle the growing pains that emerge when a project goes from a fun experiment for hackers to a serious part of infrastructure. Docker just announced a new "responsible security" program to help people report holes. While the Docker sandbox may stop some security leaks, it is quite new and relatively untested. Is there a way for one Docker container to reach inside another running next door? It's certainly not part of the official API, but these are untested waters. I wouldn't trust my bitcoin password at Mt. Gox to a Docker container.

Some of these qualms might be eased by the company's decision to open-source the code under the generous Apache 2.0 license. Developers can see the code and — if they have the time — look for the kind of holes that should be patched. The company wants to encourage non-employees to contribute, so it's working to broaden the team of developers to extend outside the company.

This is paying off in a burgeoning community of startups that want to add something to the Docker ecosystem. Companies like Tutum, Orchard, and StackDock, for instance, let you build up your Dockerfile interactively in a browser. When it's done, you push a button, and it's deployed to their cloud at prices that begin at $5 per month for 1GB of RAM. There are others like, which offers to host your Docker repositories, and Serf, a service discovery and orchestration tool that will help Docker containers learn about one another.

There are also plenty of other, more established corners of the devops world, including Chef and Puppet, that are taking notice and adapting to the new opportunity to let users build Dockerfiles. This list of names will probably change by the time you read this because it's one of the most exciting segments of a very dynamic world. There will be plenty of mergers, flameouts, and new startups in this area.

These startups show the promise of the technology. StackDock, for instance, lets you assemble your machine from a few standard cards. These will be kept cached locally, and all the machines will start with the same OS and kernel for now. This can dramatically reduce the memory devoted to keeping the same copy of the OS for all of the instances.


Previous Page  1  2  3  4  Next Page 

Sign up for Computerworld eNewsletters.