

Vagrant for fast dev environment setups - gsluthra
http://techie-notebook.blogspot.in/2012/12/vagrant-interesting-approach-to-setup.html

======
ericclemmons
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
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
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.

------
siliconc0w
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
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.

------
antidoh
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 ...

~~~
Lazare
Standardised, platform independent, easy to install and configure tools. If
you've got a somewhat complicated dev environment, it's really really easy to
tell new developers "look, just install virtualbox, install Vagrant, clone the
repo, run vagrant up, and then vagrant ssh". A few minutes later they'll be
sitting at an ssh prompt at a fully installed and configured dev server, which
is pretty sweet.

Sure, you could do it all with slightly longer and more detailed instructions
and more hand rolled scripts, but it would be slower and more fragile. Vagrant
doesn't really solve any new unsolved problems, it's just a bit easier than
the alternatives.

(Also, I'm not sure I understand your argument against vagrant. Part of the
point of vagrant is, yes, to try and maintain the same deployment tools for
dev and producton. Why do you think using vagrant makes that harder?)

~~~
antidoh
Probably my lack of understanding of how vagrant fits and works. But you
wouldn't use vagrant to manage a production server, so there's an inevitable
difference there.

~~~
Lazare
Not at all!

See, you wouldn't use vagrant to _manage_ a dev server either. Rather, the
idea is that, in dev, you use vagrant to provision a VM (or multiple VMs; you
can replicate your whole stack with multiple web servers, database clusters,
load balancers, etc.) which is as close to your production environment as
possible. Then you manage this dev environment the exact same way you manage
your production environment - with chef or puppet.

Vagrant is taking the role of Amazon's EC2 control panel or the order form on
your dedicated server providers website. And none of those manage the server;
that's chef or puppets job. (Although it does have great integration with chef
and puppet.)

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

~~~
antidoh
If I recall from previous experiments, vagrant's ruby is in its own directory,
somewhat but not entirely compartmented off.

