Vagrant dude here. I've been waiting for this! I'm really excited about what this unlocks. Some folks have been asking for the ability to use Docker as a dev environment container for awhile. I have that in the pipeline, but this unlocks the ability to communicate with Docker on a remote host with only the Docker API. This is exciting because suddenly Vagrant can manage dev environments in Docker hosts.
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.
Couldn't you always access it over the remote API? you'd just have to throw dockers http server behind some kind of nginx/whatever authentication wrapper.
* 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.
FWIW, boot2docker became my favorite all-purpose, ready-to-run, ridiculously-small-and-therefore-insanely-fast-to-download VM image.
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.
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?
If you're looking for a dev-oriented Solution, consider Docket. Configure your c build scripts, containers and docket configs and commit them to a Git repository.
https://github.com/polydawn/docket
Unfortunately, the documentation refers to the local docket install as a cache though the containers are persistent as any docket container is.
So how do I get the client going? You linked to the release but there is no documentation on building or running the osx client. Am I missing something? Maybe I am too late to the party.
I was freaking out a little then I remembered that this is just the Docker client, not the daemon. I guess this is a good thing for increasing the ease of use of Docker in Vagrant/external Linux systems. It still sometimes pains me though to see the number of Linux developers/sysadmins who use OSX systems.
I agree with both of you that desktop Linux is kinda an obnoxious scene right now, but that is mostly because of the horrid things Ubuntu does to the desktop and the fact that other distros either 1. focus so much on stability that packages are left way out of date for a developer/sysadmin or 2. are so far on the edge like Arch that things break all the time. Or like Ubuntu things break all the time just because it's Ubuntu. I use openSUSE, and I find it strikes a nice balance between stability and being up to date, as well as having the openSUSE build service allows me to easily get up to date packages for whatever software or library I may be using at the moment.
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.
Since a lot of work done by sys admins is done through SSH it isn't all that unreasonable. Makes for a comforting system while still being pretty developer friendly.
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.
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.