7 ms·

Vagrant for fast dev environment setups

13 points by gsluthra 14y ago

ericclemmons 14y ago
The most important part of using vagrant, the provisioning, isn't even covered in the article. A paragraph or link to vagrant's homepage is enough to explain the value. The hardest part is automating the dev environment via chef or puppet, which is where the article should've been dedicated to.
- dljsjr 14y ago
  There is a link to the Vagrant docs on running chef solo at the bottom of the article. Not sure if it was always there or if it was a response to this comment because the author made no indication of edit or update.
  - ericclemmons 14y ago
    That comment was there in the original. My point was that the provisioning (or packaging of a VM) is the most crucial and discussion-worthy aspect of setting up Vagrant. At least in my experience, that's the hurdle for people to overcome when seeing the value of Vagrant, as they usually already have VMWare or VirtualBox VMs running.
- wootticus 14y ago
  There's a few ways to get by without Chef or Puppet. Once your dev environment is set up you can run "vagrant package" and redistribute the vm with your modifications. You could also use shell provisioner instead.
pekk 14y ago
Nothing wrong with Ruby, but are there alternatives which do not require it?
- antidoh 14y ago
  If I recall from previous experiments, vagrant's ruby is in its own directory, somewhat but not entirely compartmented off.
- Argorak 14y ago
  The vagrant installer vendors Ruby to avoid collisions, etc. I don't know any replacements.
- mitchty 14y ago
  Alternatives that require what exactly? Is Python out of the question? Perl? Clojure? It is what it is.
antidoh 14y ago
What is the problem that vagrant solves, that can't be done without virtualbox on its own, or virtualbox and chef/puppet on their own? Or lacking that, what does vagrant do so much better than the base tools on their own that you would never want to do without it? As far as I can see you can do all that vagrant does with vboxmanage, vboxheadless and cloning. I generally ssh into my virtualboxes already. You could even make an argument against vagrant - if you want to maintain the same deployment tools for vboxes and production boxes, so that you can rehearse/test initial deployment, deployment and recovery on a vbox configured as much as possible as a production box. I'm more than open to correction or persuasion ...
- moe 14y ago
  The main differences would be the overall integration and the "Vagrantfile". I.e. you can slap a Vagrantfile into your project (akin to a Rakefile) that defines what a dev-environment should look like. Some other developer can then just check out the repo, run "vagrant up" and vagrant will take care of downloading the required OS disk-images (*.box-files), launching any number of VMs and triggering your provisioning procedure (puppet, chef, shell-script - whatever) on each. It's still a lot of work to properly integrate into a project/CI without frequent hickups (e.g. keeping up with ever-changing server-configurations). But it's definitely a solid baseline to start from and saves a lot of work that you'd otherwise spend scripting all this yourself.
- 3amOpsGuy 14y ago
  It offers a reduction in the time to get started; vagrant provides the wrapper script around vboxmanage that you would otherwise write & debug. By effectively standardising that tool which many people would otherwise continually reinvent, the group as a whole benefits from sharing and moving things forward, e.g. The many pre-packaged system images, puppet config examples and the like. If you're not using it, I don't think you'd be missing anything worth losing sleep over. I looked into it a while back - I saw it as a potential way to save my time documenting our setup for others, but in the end I opted to make my own as we have other tools to be integrated with, and by doing it myself I didn't cost myself any extra time really. I would have had to adapt either vagrant or our machine provisioning setup which would have taken more time than writing a very thin wrapper over vboxmanage.
siliconc0w 14y ago
Vagrant just allows you to automate setting up virtualbox and running chef inside a vm. You can do the same pretty trivially yourself but why bother when vagrant works. Where vagrant kinda sucks is when you're using libraries + 'smart' IDEs. I.e you develop locally in eclipse with a maven repo on the VM, or you develop in a python IDE like pycharm with the virtual environment running on the vm. You either have to share 'em from one to the other (which is slow and pretty problematic) or try to keep them in sync (which is also slow and defeats some of the benefit of the automagic dev environment). IMO, developers benefit from setting up and understanding how their environments work. Make it quick and easy but don't hide it behind an abstraction layer.
- Lazare 14y ago
  Although I agree in general, PyCharm has recently been adding explicit support for Vagrant and virtualenv in their latest betas, and it works pretty well. Basically does what you'd hope. I've got Django installed inside a virtualenv inside a linux Vagrant VM, and PyCharm running on the host OS is able to start a Django server, do interactive debugging, autocomplete function names, install new packages to the virtualenv, etc, etc. It's really just like you'd hope, and in my view just as good as PyCharm pointed at a "native" python/django install running on the host OS directly.

13 points by gsluthra 14y ago

The most important part of using vagrant, the provisioning, isn't even covered in the article. A paragraph or link to vagrant's homepage is enough to explain the value. The hardest part is automating the dev environment via chef or puppet, which is where the article should've been dedicated to.

dljsjr 14y ago
There is a link to the Vagrant docs on running chef solo at the bottom of the article. Not sure if it was always there or if it was a response to this comment because the author made no indication of edit or update.
- ericclemmons 14y ago
  That comment was there in the original. My point was that the provisioning (or packaging of a VM) is the most crucial and discussion-worthy aspect of setting up Vagrant. At least in my experience, that's the hurdle for people to overcome when seeing the value of Vagrant, as they usually already have VMWare or VirtualBox VMs running.
wootticus 14y ago
There's a few ways to get by without Chef or Puppet. Once your dev environment is set up you can run "vagrant package" and redistribute the vm with your modifications. You could also use shell provisioner instead.

pekk 14y ago

Nothing wrong with Ruby, but are there alternatives which do not require it?

antidoh 14y ago
If I recall from previous experiments, vagrant's ruby is in its own directory, somewhat but not entirely compartmented off.
Argorak 14y ago
The vagrant installer vendors Ruby to avoid collisions, etc. I don't know any replacements.
mitchty 14y ago
Alternatives that require what exactly? Is Python out of the question? Perl? Clojure? It is what it is.

antidoh 14y ago

What is the problem that vagrant solves, that can't be done without virtualbox on its own, or virtualbox and chef/puppet on their own? Or lacking that, what does vagrant do so much better than the base tools on their own that you would never want to do without it? As far as I can see you can do all that vagrant does with vboxmanage, vboxheadless and cloning. I generally ssh into my virtualboxes already. You could even make an argument against vagrant - if you want to maintain the same deployment tools for vboxes and production boxes, so that you can rehearse/test initial deployment, deployment and recovery on a vbox configured as much as possible as a production box. I'm more than open to correction or persuasion ...

moe 14y ago
The main differences would be the overall integration and the "Vagrantfile". I.e. you can slap a Vagrantfile into your project (akin to a Rakefile) that defines what a dev-environment should look like. Some other developer can then just check out the repo, run "vagrant up" and vagrant will take care of downloading the required OS disk-images (*.box-files), launching any number of VMs and triggering your provisioning procedure (puppet, chef, shell-script - whatever) on each. It's still a lot of work to properly integrate into a project/CI without frequent hickups (e.g. keeping up with ever-changing server-configurations). But it's definitely a solid baseline to start from and saves a lot of work that you'd otherwise spend scripting all this yourself.
3amOpsGuy 14y ago
It offers a reduction in the time to get started; vagrant provides the wrapper script around vboxmanage that you would otherwise write & debug. By effectively standardising that tool which many people would otherwise continually reinvent, the group as a whole benefits from sharing and moving things forward, e.g. The many pre-packaged system images, puppet config examples and the like. If you're not using it, I don't think you'd be missing anything worth losing sleep over. I looked into it a while back - I saw it as a potential way to save my time documenting our setup for others, but in the end I opted to make my own as we have other tools to be integrated with, and by doing it myself I didn't cost myself any extra time really. I would have had to adapt either vagrant or our machine provisioning setup which would have taken more time than writing a very thin wrapper over vboxmanage.

siliconc0w 14y ago

Vagrant just allows you to automate setting up virtualbox and running chef inside a vm. You can do the same pretty trivially yourself but why bother when vagrant works. Where vagrant kinda sucks is when you're using libraries + 'smart' IDEs. I.e you develop locally in eclipse with a maven repo on the VM, or you develop in a python IDE like pycharm with the virtual environment running on the vm. You either have to share 'em from one to the other (which is slow and pretty problematic) or try to keep them in sync (which is also slow and defeats some of the benefit of the automagic dev environment). IMO, developers benefit from setting up and understanding how their environments work. Make it quick and easy but don't hide it behind an abstraction layer.

Lazare 14y ago
Although I agree in general, PyCharm has recently been adding explicit support for Vagrant and virtualenv in their latest betas, and it works pretty well. Basically does what you'd hope. I've got Django installed inside a virtualenv inside a linux Vagrant VM, and PyCharm running on the host OS is able to start a Django server, do interactive debugging, autocomplete function names, install new packages to the virtualenv, etc, etc. It's really just like you'd hope, and in my view just as good as PyCharm pointed at a "native" python/django install running on the host OS directly.