Don't use vagrant

[shykes]

Vagrant is great to manage VMs which 1) are custom, 2) have lots of moving parts and 3) change often.

In contrast, to run docker on OSX you only ever need the same exact image for everyone. So 1) it's not custom (everyone gets the same image), 2) there are no moving parts, and 3) it changes only once per release of docker.

My recommendation is to use simply use boot2docker, and make headless virtualbox calls yourself. It's really not that hard and the result will be much simpler and smaller.

[nicolasbernard]

I don't think it's true.

Yes we all need the same image but we need some project-specific customisations like port forwarding.

Vagrantfiles are a nice way to have it, reinventing a tool to do that without Vagrant will not add much value.

I think what we most need for the moment is more ressources, more documenation on "how to write a simple and good Vagrantfile".

With the last release of Vagrant, the minimal config is very simple :

Vagrant.configure("2") do |config|
  config.vm.box = "raring-server-cloudimg-amd64"
  config.vm.box_url = "http://cloud-images.ubuntu.com/vagrant/raring/current/raring-server-cloudimg-amd64-vagrant-disk1.box"

  config.vm.provision "docker",  images: ["ubuntu"]
end

Then it's very easy to add port forwarding ou options like ssh agent forwarding.

Maybe a good Vagrantfile generator could be a nice week end project? (maybe with yo https://github.com/yeoman/yo)

[zaim]

IMHO, there are 2 different approaches here, and docker-osx should only choose one path.

1. As an OS X "zero to docker" seamless solution. Make working with docker on OS X exactly like working in Linux. Install docker (e.g. via homebrew) and have the docker command working as normal. The VM is invisible to the end user. I think this is what @shykes is suggesting.
2. As a manager of Docker-ready VM(s). This is, for example, for full-stack developers working on OS X. Use Vagrant to create a perfectly tuned Ubuntu+Docker VM that matches with production server, and have the docker cli work natively on OS X without the need to ssh into the VM - and have this all work seamlessly, even for multiple different VMs. I think this is what @nikkau is suggesting.

[shykes]

Option 1 what is the only option you need.

Option 2 is the equivalent of just using vagrant and having a special vagrant box. You don't need a separate tool for that! Just use vagrant.

My opinion: option 1 covers all use cases, including production-readiness. You don't need a VM that is identical to production, and more importantly you can't, even if you try - at best you will get a vaguely similar vm. That's the whole point of docker: the host configuration doesn't matter to the developer, because the container remains the same.

The only real argument for option 2 is that it's familiar for vagrant users. In the context of docker-osx that's actually a bad thing. Why waste my time learning vagrantfiles? I have no need for them.

[zaim]

You're right should've said almost identical to production :) My use case for example, is to use supervisord to manage the lifecycle of my containers - I'd like to use the same setup on production as I do in my development. And yup, just using Vagrant covers this.

Thinking about it some more, I guess what I mean by option 2 is just a simple tool to somehow configure the docker command on the fly to use different daemon IPs depending on which project I'm currently working on. I guess with the addition of $DOCKER_HOST environment variable this is rather trivial to implement?