You can build a docker image in a vagrant VM on OSX and deploy that exact docker image to production.

If your vagrant image resembles production, it's probably fine, but there's a level of confidence to be reached from deploying the exact entire self-contained binary, shipping it through QA and staging, and eventually promoting it to production.

This should be made into an answer to the OP's question, because this is the use case that I think most people will wind up moving to docker for, if they do.

This is also a use case for not developing on OS X, which doesn't have anything to do with production anyway.

Can you clarify? Do you mean that one should only develop upon the platform that will be used in production?

Yes, the previous commenter is a purist with no battery life on their laptop.

Further, if you're in the middle of upgrading your production OS, does this mean that you need two developer machines?

C'mon!

An alternative to Docker is Packer (https://packer.io/). It will create and register an AMI for EC2 so you don't have to run any configuration scripts once it is deployed. It's made by the same company that makes Vagrant and uses a similar setup. If you run Ansible to provision the Vagrant VM, I believe you can use the same script to provision the Packer image.

I would not call this an alternative. I think an alternative development workflow involves using packer as well as a number of other top level tools (vagrant for example) and using a number of other languages and DSLs. What you end up with is a VM image, not a container image, so you miss out on some of the container-vm abstractions that make docker and other container technologies so appealing.

Agreed, but a docker image is lighter in weight and takes less time to deploy and consumes less resources on the target server

My current workflow is similarly VM oriented and I've just started playing with docker, so an experienced user can feel free to chime in.

Docker is more about process isolation using LXC than having a whole VM for a particular app. You still need some operating system underneath your docker deploys, so it feels redundant in a world where I already have a VM for each project. However I could see it shining at hosting a half dozen to few dozen services from the same machine.

One thing I don't like aesthetically is the tendency to expose local folders to the container. I prefer complete encapsulation.

Docker doesn't expose local folders to the container unless you specifically and verbosely instruct it to do so. Unless you're thinking of the ADD and COPY instructions, which are entirely optional (or you can, IIRC, use ADD with a URL).

If you are referring to docker-machine (née boot2docker) sharing your home directory into the VirtualBox, that's a necessity brought on by the fact that you are not developing on Linux and Docker is (currently) Linux only, so something has to give in that relationship. It is, IIRC, also more-or-less optional, with the tremendous downside that you must scp/rsync your workspace into VirtualBox by hand, before ssh-ing in to execute `docker build`.