Edit: Bit the bullet and bought myself this bundle pack from Leanpub: https://leanpub.com/b/vagrant-ansible/ - Vagrant looks like a great tool to have under my belt. Ansible also looks extremely simple compared to Chef and looks like Vagrant and Ansible compliment each other beautifully.
---
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 makes it so that you can easily make production and local dev exactly the same (using Puppet, Chef, Salt, etc.), even when your developers use many different platforms. This solves all sorts of problems, like, something working locally but not in production, or the half day spent by each developer trying to install and correctly setup some new dependency.
Vagrant can share folders between the host and the VM using whatever shared folders option that Virtualization platform you're using has.
For our team at least, our vagrant box is an exact version mirror (Redis, MySQL, PHP, nginx, git...) and paths of our production servers.
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.
Developing on an OS that isn't the same as your production box.
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.
I use Vagrant heavily for testing ops & puppet changes. I've actually created two screencasts on Vagrant [1] and Learning Puppet with Vagrant [2]. Basically, it allows you to quickly spin up canned VM images via CLI, and then repackage/share these for others.
Yep, I saw that but it doesn't really answer my question. :(
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.
As jeffasinger described, you can sync folders between your local environment and the Vagrant VM. You can edit files locally, save them, and have the changes propagated without SSH'ing into the box. [1]
I've tried explaining the benefits of vagrant to some of my fellow developers. I've failed every time. I've now resorted to calling it "magical" and "just try it and you'll get it".
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.
There is an argument about installing development "cruft" directly on your host OS versus the use of virtualization.
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.
It's different and better because it moves the abstraction layer up a few notches.
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.
I don't really know about VirtualBox Command Line, but from a simple URL Vagrant creates a VirtualBox instance, then after simple configurations (e.g., copying a private key), can transfer the control to a provisioning script (e.g, Ansible). You have all your server configuration in an version controlled text file, runnable with a simple command, allowing you to freely tweak your server.
Primarily from it's integration with provisioners (Puppet, Chef, etc, even inline shell commands), it's folder share support and the conventions you get that make it easy to build a sane lifecycle around (vagrant up, vagrant suspend, vagrant destroy).
Comments
Edit: Bit the bullet and bought myself this bundle pack from Leanpub: https://leanpub.com/b/vagrant-ansible/ - Vagrant looks like a great tool to have under my belt. Ansible also looks extremely simple compared to Chef and looks like Vagrant and Ansible compliment each other beautifully.
---
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 makes it so that you can easily make production and local dev exactly the same (using Puppet, Chef, Salt, etc.), even when your developers use many different platforms. This solves all sorts of problems, like, something working locally but not in production, or the half day spent by each developer trying to install and correctly setup some new dependency.
Vagrant can share folders between the host and the VM using whatever shared folders option that Virtualization platform you're using has.
Half day? I've worked in places where this was more like 3 days.
For our team at least, our vagrant box is an exact version mirror (Redis, MySQL, PHP, nginx, git...) and paths of our production servers.
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.
Developing on an OS that isn't the same as your production box.
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.
I use Vagrant heavily for testing ops & puppet changes. I've actually created two screencasts on Vagrant [1] and Learning Puppet with Vagrant [2]. Basically, it allows you to quickly spin up canned VM images via CLI, and then repackage/share these for others.
[1] http://sysadmincasts.com/episodes/4-vagrant
[2] http://sysadmincasts.com/episodes/8-learning-puppet-with-vag...
http://docs.vagrantup.com/v2/why-vagrant/index.html has your information.
Yep, I saw that but it doesn't really answer my question. :(
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.
As jeffasinger described, you can sync folders between your local environment and the Vagrant VM. You can edit files locally, save them, and have the changes propagated without SSH'ing into the box. [1]
[1]: http://docs.vagrantup.com/v2/synced-folders/
Edit: Adding source.
I've tried explaining the benefits of vagrant to some of my fellow developers. I've failed every time. I've now resorted to calling it "magical" and "just try it and you'll get it".
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.
There is an argument about installing development "cruft" directly on your host OS versus the use of virtualization.
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.
Unless you develop natively on Linux, Docker must still run inside of a VM, so there is no real battery savings.
And how is it different or better than the VirtualBox command line, which is quite extensive?
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.
It's different and better because it moves the abstraction layer up a few notches.
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.
I don't really know about VirtualBox Command Line, but from a simple URL Vagrant creates a VirtualBox instance, then after simple configurations (e.g., copying a private key), can transfer the control to a provisioning script (e.g, Ansible). You have all your server configuration in an version controlled text file, runnable with a simple command, allowing you to freely tweak your server.
Primarily from it's integration with provisioners (Puppet, Chef, etc, even inline shell commands), it's folder share support and the conventions you get that make it easy to build a sane lifecycle around (vagrant up, vagrant suspend, vagrant destroy).