In a recent post I provided my initial impressions of Docker, which were glowing to put it mildly. After spending more time working with it, I've found that it does still have some additional drawbacks in certain situations just about every situation covered thanks to Vagrant.
// Share.on([hacker news,
linkedin,
twitter,
facebook,
reddit])
So we've established that Docker is awesome and incredibly disruptive. There is one major problem at the moment though: Docker achieves all of its amazingness because it is tied closely to the Linux kernel. If you and your development team are all running Linux machines, just stop reading here. Everything I mentioned before still applies and Docker is still something worthy of full scale embracing.
The problem is that if you're on a Mac or Windows machine, you will need to run Docker in a VM. Docker has actually accounted for this to give you a more pleasant user experience through a tool called boot2docker, which will allow you to use Docker as if it was native through virtual machines running in the background.
This is the gotcha. If you are using Docker with a bunch of single server sites where you only ever need to fire up one or maybe two at a time, this is a completely acceptable solution. It's the equivalent of running two VM's and your team can still use Docker in place of the likes of Puppet / Chef / CFEngine, etc. It doesn't get all of the performance perks that you'd get if you were using it on a linux machine, but it's tolerable for the workflow.
If you are working on a system with service oriented architecture that has multiple moving parts that will need to be up and running at the same time...this is more problematic. It's exactly the same as needing to use multiple Vagrant VM's at the same time so there is virtually no benefit to using Docker. You can try to get around this by setting up a single Vagrant VM to run multiple Docker containers and that will largely solve your problem from a standpoint of local resources, but it's more complicated to get running and does not give you the same perks from a workflow standpoint.
Yes, workflow. The steps that you repeat over and over in the development process which speed up or slow down you and your team the longer they get. The promise of Vagrant is including a Vagrantfile in your git repo, typing 'vagrant up' and magically provisioning an entire VM that's automatically mapped shared directories to your code base.
In order to do this with multiple projects in the same VM, you've got to map all of the shared directories locally (which will vary by team member) to the VM directories. This also means hopping into the VM to go start/stop each service as changes are made. If you're okay with jumping through those hoops and managing that configuration then Docker may still work fine for you.
YES! The negatives I mentioned above are largely related to mapping local code shares to a single VM and forcing the developer to keep hopping into the VM as added steps in their development workflow. However, all of your peripheral tools that don't require ANY intervention other than connecting to a port will work fine with this setup. Vagrant is even setup to allow you to use Docker to provision multiple images, so you can easily setup a Vagrant VM to install MySQL, PostgreSQL, PostGIS, Redis, Memecached, Riak, RabbitMQ, ZeroMQ all within their own Docker containers in the same VM...then just start the VM to load up all of your dependencies.
Those pieces are where a lot of the complexity comes in with setting up local development environments. There are already so many great tools for running your actual code locally with separate dependencies, web servers, and processes (like RVM and Foreman if you live in the land of Ruby) that those tools will prevent you from having to add Docker headaches to your programming workflow.
You're darn right you should. If you use Linux for local development, Docker is still a virtual no-brainer. At the Meetup that I attended last month, they indicated that a version which runs on BSD is in the work and when that happens Docker should be able to run on OSX or FreeBSD derivatives the same way that it runs on Linux. When that happens it will free people from the VM dependency completely.
That won't do any good for users developing on Windows, but if you're deploying to Linux and developing on Windows at the moment you're unfortunately already having to deal with those type of problems. If you have a full development Linux VM running within Virtual Box or VM Ware, Docker is still a great option for Windows users.
According to some documentation for Vagrant and Docker that I just somehow missed, "Vagrant then shares this virtual machine for all Docker-based development environments with Vagrant. That means with just a single virtual machine, Vagrant can manage many Docker environments."
Everything I mentioned above was largely derived from having to manually rig up what Vagrant is now intelligiently doing behind the scenes. What this means in terms of workflow is that, instead of using Docker natively you should ALWAYS use Vagrant for consistency and management of your Docker containers...even if you're running Linux since according to their documentation, "If Vagrant is being used with Docker on Linux, Vagrant won't automatically spin up a virtual machine and instead will run Docker natively."
So even if/when a native FreeBSD/OSX version is released you'll still be better off using Docker via Vagrant.
Well played Vagrant...well played.
// Share.on([hacker news,
linkedin,
twitter,
facebook,
reddit])