The approach I've been taking so far is SSH-ing into some machine (local or remote), and executing `docker` (client) on that machine. But this requires SSH access. There have been a lot of container-only hosts popping up and Vagrant couldn't access those. Now it can.
Why would you want Vagrant to access those? Because if Vagrant can access the Docker containers, you get a lot of nice things that Vagrant gives you for free. Besides the workflow, the main benefit is synced folders.
With the synced folder abstraction in 1.4, and an upcoming ability for Vagrant to sync folders using rsync or scp with or without inotify, Vagrant will be able to sync your container files locally down onto your machine.
Again, why does this matter?
Because, say you compile your web app into a Docker container for deployments (and now dev). You can edit files on your own machine just like Vagrant has always let you, these files get automatically synced over to the Docker host, and Docker runs the web app like normal. BAM!
Anyways, the next version of Vagrant will be able to do this with or without the Docker client installed. But if the Docker client is not installed, then it will use SSH, which requires SSH access on the Docker host. But with the Docker client, you just get it for free, which is super cool.
* Yes, we will start gpg-signing our binaries. We are going to sign our git tags while we're at it. If you really can't download a binary from a trusted domain to execute as non-root on your laptop, here are the build instructions: http://docs.docker.io/en/latest/contributing/devenvironment/
* Since this has been submitted, 0.7.3 has been promoted to a stable release.
* This does not allow docker to natively run containers on a mac (although we're also working on that :). This allows using docker in client mode from the mac, to interact with a remote docker daemon, either on a local VM or another machine. You can control which daemon to connect to with the -H flag, or by setting the $DOCKER_HOST environment variable.
* The perfect companion for this is boot2docker: http://github.com/steeve/boot2docker. It's a 25MB VM which boots to a functional docker daemon in less than 5 seconds.
* This is only the beginning of our support for OSX as a target platform. the boot2docker and docker-osx folks are collaborating to bundle all of the above together in a single, ready-to-use mac installer. As soon as they do, we will merge it upstream as the official mac installer.
* Respectfully to the author of Vagrant who commented below: with docker + boot2docker, I basically don't need Vagrant anymore. I'm glad existing Vagrant users can benefit from a subset of docker's features without losing their existing Vagrant setup. But if you're starting fresh, use one or the other - not both.
It's faster to download it (it's 25 MB) and start it with qemu, than to go through the clicky-pointy interfaces of VirtualBox etc., or go through the download of a full Vagrant box. This is game changing.
This is exactly what I was talking about in this blog post:
With a single installer on Mac which will bring both, boot2docker and native Docker client, we have a fully functional Headless Hypervisor!
Next step is Windows?
Unfortunately, the documentation refers to the local docket install as a cache though the containers are persistent as any docket container is.
But I agree.
Until desktop Linux stops regressing, that number is going to keep growing.
Desktop Linux is a shit storm right now, but that shit storm I think blinds people from the distros who just do things right and make a stable and easy to use system, don't have the crazy stupid arguments of something like Debian with their Upstart vs systemd debate, and who make a system for professionals who just want to get shit done.
I can see the obvious benefit for localized testing but Vagrant isn't that bad. Or just using SSH to a test box. That way your laptop hardware isn't a limiting factor.
That says more about Linux than it does about its sysadmins and developers.