Docker at the DevOps London Meetup

I spent last Wednesday (28th May 2014) at the DevOps Exchange London meetup, listening to 3 talks about Docker, a lightweight deployment container – kind of a halfway between a full Virtual Machine (VirtualBox, EC2, etc) and a virtualised JVM (eg Mesos, Heroku).

The most interesting chat was the first one from Simon Vans-Colina who works at Pearson (owner of the Financial Times amongst other things) who have inherited a huge technology stack because of mergers and acquisitions. They’ve started to look at Docker as their Unit Of Deployment (their current approach is RPM or WAR). This enables them to run multiple independent Docker containers on a single computing resource and have them separate, rather than using separate VMs as a unit of isolation. If you consider the number of servers you have across Dev/Int/Accept/PreProd and Prod which have low utilisation, you can see how you could make savings (there was a slide which showed 159 Amazon EC2 instances, with low utilization warnings on most of them).

However, he did warn that Docker isn’t production ready yet from their viewpoint. Long-running Docker containers eventually run out of resources without a garbage collection process within them (such as initd), so he said that Docker suits simple fire-up-then-destroy processes (with startup speed suitable to enable you to put vim into a docker container and use that to remotely edit files – thereby enabling you to keep your settings across servers), or perhaps wide deployments (eg 10k deployed containers, so you can cycle them at the first HTTP500 error). They attempted to Docker-ise Jenkins, but that leaks all sort of stuff and isn’t suitable, but they have moved to creating RPMs in Docker container, which ensures that a clean Docker environment is used each time an RPM is built to prevent cached artifacts making a mess of your RPM.

The other talks were more around supporting Docker – an alternative to Chef/Puppet/Ansible called ShutIt for building Docker containers , and a talk about Apache Brooklyn  for managing your deployments.