I discovered Vagrant over 3 years ago, in 2012. I was introduced after asking at a local Usergroup about how people manage different environments (Linux, Mac, Windows) for developers, different setups and configuration files. After I moved the first project in our company to Vagrant, I was sold. Since then, I put everything into Vagrant: Company projects, private projects, prototypes, tutorials and even Project Euler.

A virtual development environment

Vagrant helps managing virtual development environments by combining virtualization software like Virtualbox and provisioning tools like Ansible or Chef with a registry for virtual machine images. When you work with Vagrant, you don’t install libraries you need on your host system but inside a virtual machine. Your webserver (in case of a web project) runs inside this vm and your code is executed there as well. The source code is stored on your host machine and synced into the machine so you can still use your favourite editor/IDE.

To set up the virtual machine, a base box is downloaded and copied. You can either use a predefined image from a global registry or build your own. When booting this machine, additional steps to install software and change configuration files, the so called provisioning, is executed by Vagrant. This can be done using one or more shell scripts or a specific provisioning software like Ansible.

One configuration to rule them all

The configuration is saved in the so-called Vagrantfile. This configuration file can be shared together with your project and enables co-workers to boot the same virtual machine with the same software installed and the same configuration present. Even better, if somebody changes the setup (because the project needs a new library or the dependencies have been updated), everybody working on the project only needs the new Vagrantfile, runs a command to provision his box again and is done.

If you start working with Vagrant, it needs a little bit of finetuning, but after a little while you won’t notice it anymore. The vm is just there, running when you need it. Working also doesn’t change that much. The only thing to remember is to not execute tasks on your host machine but to ssh into the vm before running them.

Sharing as it should be

Vagrant takes care of the networking part, assigning private IPs and hostnames and forwarding ports from the localhost to the guest vm if necessary. It can also be used to deploy software with a specific vagrant push command. If you want co-workers to have a look at your version of the software, vagrant share is there to help you. It opens a tunnel from a unique, random URL to your vm. As long as your machine runs and you keep that tunnel open, other people can connect to that URL and, using the correct port, can access a running webserver to look at the project on your localhost.

Your co-worker will also be able to connect to your vm using ssh without exchanging ssh keys or something like this. This will only work if you run vagrant share and your co-worker runs vagrant connect with the correct random name given by vagrant share. Of course it’s advised to only run vagrant share in case you need somebody else to look at your project or help you out and not have it running unattended.

Starting is easy, too

Maybe you are eager to start away. That’s great, and the best thing is: It’s easy and there is almost no risk attached to it! You can start using Vagrant on your machine for one project and build the virtual machine with all dependencies in steps, all while still using your local environment in your day-to-day work. If you have everything you need, switch to running inside the vm but keep your libraries and software needed locally as well. Start sharing the Vagrantfile with your collegues and urge them to use it as well. You’ll need some time to fix the small things which were forgotten or which come up when more than one person uses the virtual environment. After everything is running smoothly for some time, go ahead and remove the locally installed webserver, libraries and database if you like.

And if you are even more cautious, start with a pet project or just put the next thing you wanna play with (language, framework, database, …) inside a virtual machine from the beginning! This way you’ll learn two things at once.

Share this article

Share on Facebook