Docker Misconceptions
I was ready to come in swinging in defending Docker, but I found myself agreeing with most of the points after spending a lot of time with Docker over the last month (ported my Rails application's provisioning from Ansible to it).<p>I would add to the list that it is currently hard to even find decent images of popular services that you would trust deploying to production (e.g. Postgres).  I see with the launch of Docker Hub that they have some flagged as "official" now, but for example the Postgres one is a black box (no Dockerfile source available - not a "trusted build") so I can't trust it.[1]  I've had to spend time porting my Ansible playbooks over to Dockerfiles due to this.<p>I think part of the problem is that composition of images is strict "subclass"-type inheritance, so they don't compose easily.  So it's hard to maintain a "vanilla" image rather than a monolithic one that has everything you need to run your particular service - so people just keep their images to themselves.  For example, if I want a Ruby image that has the latest nginx and git installed, I can't just blend three images together.  I have to pick a base image, and then manually add the rest myself via Dockerfile.<p>Also, although Vagrant 1.6 added Docker syntax, you really have to understand how Docker works in order to use it.  If you're learning Docker I'd stick with the vanilla `docker` syntax first in building your images, maybe using something like fig[2] to start with.<p>At the end of the day it's another abstraction to manage.  It does bring great benefits in my opinion, but the learning curve and time investment aren't cheap, so if you already have a suite of provisioning scripts it may not be worth it to make the leap yet.<p>[1]: <a href="https://registry.hub.docker.com/_/postgres/" rel="nofollow">https://registry.hub.docker.com/_/postgres/</a><p>[2]: <a href="http://orchardup.github.io/fig/" rel="nofollow">http://orchardup.github.io/fig/</a>