What's the Point to Docker Provisioner?

[Joaquin Menchaca]

I was trying to keep open minded about this, but now that I am more experienced with Docker and Vagrant, I have to wonder, what was the reasoning for the Docker Provisioning.

For the concept, a provisioner I thought was a way to "configure" a system.  So having a provisioner for docker confuses the scope, as Dockerfiles are not applied on a system level, only for running containers.

For the implementation, using the docker provisioner meant it would take about 20+ minutes to bring up the system.  You can dramatically lower this to a few minutes just using a shell script, which is what I do in all of my tutorials, as the using vagrant for this is painful.  Also, I don't understand what value you get using ruby methods/variables to orchestrate when shell commands using docker or docker-compose are far more flexible and capable, e.g. front loading environment variables.  Ultimately, you just use args: with a big string.

Outside of the scope of the docker provisioner, using vagrant for docker, you lose the integration (cached images, etc) and performance.  Brining up a container with docker-machine is fast, but with vagrant it is complex and slow.  You could point docker-machine to a generic provider and backend it to vagrant, but then you don't have the integration (shared file system).  With the new docker toolbox in beta, you get greater performance with xhyve (or on windows with hyperv) than out of virtualbox.  

From that perspective, maybe another tool on top vagrant, or something similar docker-compose from Hashicorp, but as it stands, you lose more with vagrant for docker.  I still use it in limited niche circumstances, when I need to test scripts that orchestrate docker in a pure Linux VM (such as ansible's docker modules or docker-compose), and in these niche use cases, I wouldn't use the docker provisioner.  For day-to-day docker tooling, I would never use vagrant in general (I still use vagrant a lot for non-docker tooling).

[Alvaro Miranda Aguilera]

Hello

So, the tool vagrant did incorportate docker at a point where docker wasn't very available outside linux.

if you had a docker capable linux, you wouldnt run vagrant to run a VM to run docker inside, but remember, this came out when docker wasn't having docker machine for windows or OSX.

and even on those cases where you are on linux, some people wanted to have vagrant creating a vm anywats to be able work in the same setup as non-linu machines

So, in a scenario where you want to use what vagrant does "incorportate into a project the definition of a VM" fits the bill if the project want to use docker.

Is not mandatory that you should use it, its there as an option. I use it personally when I need to test something specific, but i also spin up a VM with virtualbox or sometimes with VMWare, there is not a fits-all rule, is just more options.

in some cases make sense start a vagrant vm, put packer on it, test a packer+docker build, etc

maybe i am missing the point in the question, but asi see it is good to have many options, at somepoint you may use them (or may not)

Thanks

Alvaro

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/mitchellh/vagrant/issues
IRC: #vagrant on Freenode
---
You received this message because you are subscribed to the Google Groups "Vagrant" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vagrant-up+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vagrant-up/46408a00-16ed-4852-b792-ebcca25130ae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Alvaro