---
I guess this a good a place as any to ask, pardon my ignorance. What part of the workflow does Vagrant solve exactly?
For example, I'm building a business-class Rails application - normally I have RVM create a gemset specifically for that application. I also have PostgreSQL and MySQL installed locally for any app that needs it.
How does Vagrant fit into this workflow, what am I missing? Also, since the 'dev box' is now a virtual machine does that mean I can only ssh into it and edit code with something like Vim? Thanks for the information.
Vagrant can share folders between the host and the VM using whatever shared folders option that Virtualization platform you're using has.
We have our DevOps maintain the box so the rest of the team doesn't have to worry about it. Changes to something, tell every one to pull from git, run vagrant provision and it works.
Saves us a lot of headache in "deploying" new development environments to our team.
You can SSH to it, but usually you map folders between the host machine and the VM so that you use your local suite of tools on a local drive that is mapped to a location on the VM.
[1] http://sysadmincasts.com/episodes/4-vagrant
[2] http://sysadmincasts.com/episodes/8-learning-puppet-with-vag...
If you're a developer, Vagrant will isolate dependencies and their configuration within a single disposable, consistent environment, without sacrificing any of the tools you're used to working with (editors, browsers, debuggers, etc.). Once you or someone else creates a single Vagrantfile, you just need to vagrant up and everything is installed and configured for you to work. Other members of your team create their development environments from the same configuration, so whether you're working on Linux, Mac OS X, or Windows, all your team members are running code in the same environment, against the same dependencies, all configured the same way. Say goodbye to "works on my machine" bugs.
---
It doesn't answer if I can only ssh into the box and write code there. I need more actual workflow data.
[1]: http://docs.vagrantup.com/v2/synced-folders/
Edit: Adding source.
At the very least, you can think of it as a nice CLI to the hypervisor on your machine. Something that's consistent across different host OSes - as long as you've got the right version of Vagrant :) That and synced folders is enough of a win in my books.
Edit: I noticed you are asking about workflow. That's another thing about Vagrant. I use it like a swiss army knife for various tasks as needed. It isn't really part of a workflow per say. I do a lot of exploratory programming, trying out new stacks/packages/tools, etc. It fits well with that kind of use case.
I personally hate have long running processes always on in the background of my host OS. It slows things down, and it's not the purpose of your OS. You end up suing a non-standard OS (wayyyy different than production, especially on your Macintosh where the file system isn't case sensitive, to give 1 example).
Some people "need" to install software directly on their host OS because VM's take up too much battery power and they often work too far from an outlet. That can make sense, but I still cringe at the idea.
I think Docker provides the best of both worlds here. We have real isolation from our host OS without having to virtualize an entire OS - It even removes a whole layer of battery-eating virtualization! (Hypervisor, I believe)
Docker (for local development) will let you get very close to your production OS while still being easy to use and (relatively) light-weight.
Vagrant also seems to have something in common with docker, though with VMs instead of containers, though I'm not totally clear on that either.
First, Vagrant supports much more than just VirtualBox (maybe not a big deal if you only want to use VirtualBox).
Second, Vagrant comes with a nice configuration layer allowing you to specify what OS and VM options you want to use (maybe not a big deal if everyone in your group is already comfortable with the VirtualBox command line).
Third, it handles provisioning new VM's using the provisioner of your choice, like Chef, Puppet, regular old shell scripts, etc. (Maybe not a big deal if everyone in your group is already an expert at using the chosen tool e.g. knife).
Fourth, it wraps up all of the previous steps (plus a bunch more), so that people can just clone the current box and type 'vagrant up', and have a working copy of the production/staging/test/dev network. (Maybe not a big deal if everyone in your group is already an expert at setting up that network).
Anyway, I know that all comes off a bit glib, but Vagrant really shines in automating a bunch of not-necessarily difficult manual steps. I'm pretty sure it doesn't do anything that can't also be done through a variety of other mechanisms (being well-versed in the VirtualBox command line, for example), but so far, I've found it to be more pleasant to use than dealing with all those other mechanisms.
It isn't as easy as "download pre-built Linux box" but for environments that are using Windows, this workflow has been amazing for them above what they used to do, and is quite fast.
It even allows you to replace the functionality of Vagrant - in place- to create, spin up, and provision the box all in one command.
It's super awesome.
Can I use Vagrant to build out my production server too? Or would I just use Chef/Puppet/Ansible with the same playbook/recipe on both my Vagrant powered VM and non-vagrant powered production machine?
When I'm good to go, I use Packer with the same Salt configuration to build an image and push it to AWS/DO/RackSpace as needed. Makes it super easy to develop and deploy on exactly the same machine, and the Vagrant/Packer configurations are typically fairly minimal so there's very little set-up time once you've written out your Salt/Puppet/etc configurations.
Look into packer for building out Production images, and Chef/Puppet/Ansible for additional configuration ontop those images.
> Boxes can now be compressed with LZMA - LZMA compression can result in much smaller boxes in a lot of cases, and Vagrant can now decompress LZMA-compressed boxes.
any word on how this is enabled, or does it just work? I didn't see anything in the package or box docs.
thanks.
