Michael Gorsuch | ![]() |
RJ : Nowling | Vagrant isnt helpful when your using docker. Why not just use docker run? |
And finally, the Roman and Cos, our bigtop buddies, have weighed in on the "docker vs vagrant" email thread we've been having.
The puppet folks believe that configuration should be declarative, and in fact that there is intrinsic value in declarative configuration. The puppet master is just a accidental detail of the way they implement it in some cases.
I think the same argument can be made for why we still use vagrant in a docker driven world.
Docker has alot of options. If you want a reproducible system, you want a minimal amount of options. For example, Here is a docker command from a recent stackoverflow post:
docker run -v /host/directory:/container/directory -other -options image_name command_to_run
In the above command , we define a command to run, as well as an image to start. However, we don't have to do the "run", alternatively, we can modify our Dockerfile to have a command at the end. Then , the run is optional. And what about ports? Oh, there is another option for that...
-p 127.0.0.1:$HOSTPORT:$CONTAINERPORT
In the above command, we went ahead and added a port forwarding option. Now, after we are done spinning the container up, we may run a task and kill it. We can find our containers using
docker ps
At some point, you start coupling shell scripts which run a whole task for you, or which wrap certain docker workflows for you. Well, at that point - you might be better off using vagrant, don't you think? After all, vagrant gives a declarative way to describe the docker workflow, without actually being coupled to docker commands in its syntax. This means you can change your hypervisors under the hood, and gaurantee that the whole system can be spun up in a 100% reproducible manner.
Also, vagrant forces you to decouple the installation tasks from the creation of the machine in the Dockerfile. This generally leads to a much more maintainable system.
No comments:
Post a Comment