Vagrant, developer’s best friend!
I’ve started using Vagrant 9 months ago. At the beginning my goal was to stop spending time setup dev environment (I like to break it) and manage to get a consistent one between my developers.
I worked on that matter earlier with a tool called Boxen (made by Github team) which purpose is to automate software install on OS X with a lot of HomeBrew behind the scenes. I’ve struck with many problems within this approach:
- Boxen always broke on OS X updates
- It didn’t allow me to setup multiple environment per machine (which is not its goal anyway)
- It only works on OS X
Then came Vagrant!
My first reaction was:
Yeah I’ll finally won’t fear to test and crash my box
And right after that one:
Oh my god I hate those Virtual Machines!
Let’s see what makes Vagrant so useful for any developer (and devops!).
Back to basis
If you don’t know much about Vagrant I suggest you check their website and if you are too lazy let me resume it:
A command line utility to let you build and run virtual machine using VirtualBox (or VMware) in the background.
This means that you, as a developer, won’t have to use VirtualBox GUI at any time. You will run everything from your shell and the whole process will feel so natural that you will forget that you are running your code inside a VM (hopefully).
Building aka Provisioning
Your computer (the host) won’t run anymore your code, the Vagrant machine you are going to build will. In order to do so the first step is to actually build this machine, this is the provisioning.
Vagrant is able to use multiple providers: Chef, Chef-Solo, Puppet, Ansible and even Docker (full list here). It’s up to you to choose the one you like. The important thing is that this process force you to create a repeatable environment and this is a very good thing. You just need to pick the base box of your choice (full list) and start the provisioning!
The whole Vagrant setup is described in a file called Vagrantfile that you should add at the root of your application repository and version it. Now your developer won’t only share code, but also the whole configuration needed to run it.
Once your Vagrant is setup it only takes one command to build your machine:
$ vagrant up
Running it
Once your machine is setup, you are ready to use it. Think of this machine as a distant server, so how do we use it? SSH my dear friend:
$ vagrant ssh
$ cd /vagrant #where vagrant mirror your host repository
Vagrant takes care of everything for you:
- Mirror your code to the VM through NFS, so you can still use your host machine to code!
- Forward your host SSH keys to the VM so you can still connect to your servers inside the VM (useful for deployments!)
- Setup everything network related, public and private network, port forwarding etc.
- Manage the RAM and CPU dedicated to the VM
- etc..
Gotchas
At the beginning we experienced two kinds of problems, NFS share was slowing down our code and Network was pretty unstable. We solved those by switching to VMWare Fusion (which is a paid option) instead of VirtualBox.
Finally 3 months ago we switched back to VirtualBox, all those problems are now fixed and performance are at least as good as on VMWare.
Nowadays Vagrant seems to get more and more traction from the community and they add new features on a regular basis.
Key benefits
After 9 months of use with my team, here are the benefits I mesure:
- We now have a fast and easy initial setup for new developer
- Our environment is always in sync (homogeneous)
- We try more new things because we don’t fear to break our setup
- Our development is closer to production which reduce last minute bug
- Developers acquire DevOps knowledge
I hope this post gave you the desire to try it by yourself if it’s not already the case. If you have anything to add or to say feel free to use the comment section below.
