Disclaimer: Vagrant creator/maintainer guy.<p>It is unfortunate that so many people compare Vagrant and Docker. While there is overlap, Docker is mostly not viable as a dev environment tool alone, so it isn't a fair comparison. The main reason is because you have to be using Linux (and a recent Linux) as your main dev system, and in practice this is very rare. Move beyond indie developers and for all intents and purposes Linux desktops are non-existent (Vagrant is in use by companies like BBC, Expedia, Intuit, etc. and I can tell you most devs don't know how to use Linux let alone run it as their primary dev platform).<p>BUT, I agree that putting your dev environment in a Docker container is absolutely _amazing_, and there is a KILLER Vagrant/Docker combo.<p>The killer combo is actually running Vagrant to spin up Docker-ready VMs, then using Docker inside that to develop. This lets people use Docker on Windows, Mac, and Linux. You get the fast iteration time because all your state is actually in a container, so you just docker kill and run as usual.<p>In fact, an upcoming version of Vagrant is adding Docker as a provisioner, so you can `docker pull` containers down as part of `vagrant up`.<p>And I published Packer[1] templates to build Docker-ready VirtualBox/VMware/AWS images that are Vagrant-ready: <a href="https://github.com/mitchellh/packer-ubuntu-12.04-docker" rel="nofollow">https://github.com/mitchellh/packer-ubuntu-12.04-docker</a><p>[1]: www.packer.io
I don't see the parallels to Git at all. If you just looked at the command line options without understanding what's going on at all it might look similar.<p>> a tool like Puppet or Chef is needed when you have long-running VMs that could become inconsistent over time.<p>Uh, no, Puppet and Chef are designed for configuration management. To manage your configs. They are not designed to replace customization and they don't address package management or service maintenance. (They have options to munge these things, but you still need a human to make them useful and coordinate changes with your environment) Neither does Docker. Docker also doesn't do configuration management. All different things.<p>> You'll be 100% sure what runs locally will run on production.<p>Incorrect; you're using unions to fill in the missing dependency gaps, so there's no guarantee what was on your testing container's host is on your production container's host. Your devs also might be running with container A and B, but in production you're using containers A and C. Not to mention the kernels may be different, providing different functionality. All this assuming A, B and C don't need instances of different configuration. There are no guarantees.<p>You know what else is crazy fast and easy to manage? Packages. There's this new idea where you can have an operating system, run the command 'apt-get install foobar', and BAM all of a sudden foobar is installed. If you need a dependency, it just installs it. And it only downloads what it needs. Also does rollback, transactions, auditing, is multi-platform, extensible, does pre-and-post configuration, etc. Sound a lot like docker? That's because it's a simpler and more effective version of docker [without running everything as a virtualized service].<p>Deploy using your package manager. Except for slotted services which (AFAIK) no open-source package manager supports, it will do everything you need. And what it doesn't do, you can hack in.
I'm very excited about Docker[1] as both a development environment and deployment solution. However, from my early experiments, it seems there's an important difference between LXC (which is what Docker manages for you) and a full VM, namely that the model revolves around running one process at a time: you can install mySQL on your docker image, but once it's up, it's running mySQL -- you can't then ssh into it as you would a VM to poke around, modify config files, etc..<p>There are trivial ways to solve this, obviously. You can stop the image, restart it running bash, use <i>that</i> to modify config files, and then restart it again. But it requires a change of mindset: these things are much more than background processes, but they are less than a full VM. As the piece mentions, configuration management for newly-started images seems to be a missing piece of the puzzle right now, and debugging running Docker images can be... strange. [2] Not necessarily difficult, but different from what you're used to, and learning curves are barriers to adoption.<p>As this tech matures I think these things will be quickly solved, and I'm looking forward to the results.<p>[1] Plus Virtualbox, started by Vagrant. See mitchellh's comment.<p>[2] Unless, of course, I'm missing something. Docker-people: how do <i>you</i> configure vanilla server images to work in your environment?
I spent the entire article wondering how deployment via git was at all relevant, until I read the very last heading.<p>(The title is supposed to be read as "Docker is as powerful for deployment as git is powerful for SCM!". There is no mention of git-based deployment strategies like Heroku's.)
If you're around Paris, we're doing a Docker meetup in October <a href="http://www.meetup.com/Docker-Paris/events/136924002/" rel="nofollow">http://www.meetup.com/Docker-Paris/events/136924002/</a>
Hello,<p>Is there any way to run this on a recommendable way with other platforms than ubuntu?<p>I could love to see it running smoothly with debian and centos to turn immediately into a converted user.<p>Nice work, looks impressive.
I am still not sure how useful Docker is but we have created a simple example how to run Docker on Vortex which is sort of Vagrant alternative. <a href="https://github.com/websecurify/node-vortex/tree/master/doc/examples/docker-helloworld" rel="nofollow">https://github.com/websecurify/node-vortex/tree/master/doc/e...</a>
Another one in progress:<p><a href="https://github.com/arnoo/git-deliver" rel="nofollow">https://github.com/arnoo/git-deliver</a><p><a href="http://i.reddit.com/r/programming/comments/1j9n8v/gitdeliver_better_software_deployment_with_git/" rel="nofollow">http://i.reddit.com/r/programming/comments/1j9n8v/gitdeliver...</a>
OS containers can be very cool. Want to see 1000 instances started on a small machine? <a href="http://ivoras.sharanet.org/blog/tree/2009-10-20.the-night-of-1000-jails.html" rel="nofollow">http://ivoras.sharanet.org/blog/tree/2009-10-20.the-night-of...</a>
<a href="https://news.ycombinator.com/item?id=6252182" rel="nofollow">https://news.ycombinator.com/item?id=6252182</a><p>(i would give credibility to the docker maintainer)
Get back in touch with me when Docker can help with Windows deployments. (Is there an issue I can 'star' or otherwise track?)<p>Edit: To say Docker is analogous to Git for deployment fails outside of the Linux server realm (lxc). I'm trying to think of an OS-specific source control system to fix the analogy but can't come up with anything only-Linux... 'TFS for deployment'? :)<p>I plan to check out <a href="http://ulteo.com/home/en/download/sourcecode" rel="nofollow">http://ulteo.com/home/en/download/sourcecode</a> as an alternative.
docker is pretty awesome, at my company we share auxilary server around with docker (message queue system) and it's pretty RAD. I can't wait until they made it rock-solid enough to run systems in production with it.