So You Want to Set Up a Vagrant Environment

The Problem with Local Environments

The problem with developing on local environments happens when everyone’s environment is different. The same problem may not necessarily have the exact same solution in all the environments. So, setting up the exact same website on my local environment and on the environment of the person to my left might output no errors for me, but it could give her a blank screen. This slows us down as we debug what is going wrong, even though we know everything but the environments is identical.

I Love Vagrant

After just one day of using Vagrant I realized it solved this potential problem, and that I loved it. I wanted to get our team on board with the idea of using this awesome tool for local development. If you want to do the same thing, or are just interested in Vagrant and setting up your first Vagrant Box, then you are reading the right blog post. The Vagrant getting started guide is another great place to get started. On this post I try to talk about why I use, and to explain some concepts the Vagrant guide assumes you have previous knowledge about.

I am breaking up these Vagrant posts into multiple parts. In post one (what you’re reading) I’ll point you in the direction to get started as easily as possible and explain some basic concepts. Then, in the next post we will set up multiple websites in one Vagrant environment, I’ll also suggest folder structures that have worked for us here at NJI. After that, I’ll write about how to actually match a production environment using Vagrant and Puppet as a provisioner (short explanation of provisioners is in this post).

My focus through these series of posts will be on LAMP (Linux, Apache, MySQL, and PHP) stacks on Vagrant. The bulk of our development is on Drupal, WordPress, ExpressionEngine, Symfony and other PHP-based frameworks/CMSs, so it makes sense to me to introduce Vagrant that way. However, you can set up a Vagrant Box with anything from Node to Ruby to COBOL running on Ubuntu. Also, I am on a Mac, which is worth mentioning.

Why Vagrant Works

My local setup used to consist of my MacBook pro’s local web server (Apache 2.4.10), PHP (5.5.21) and MySQL. This worked ok, but there were some problems. For one thing, my local environment didn’t match our production environment. I couldn’t catch an error caused by differing environments until I pushed code to our staging server (staging servers match production servers for testing). But what bothered me more was that every time I updated my operating system (OS) I had to take time out of my day to reconfigure Apache, PHP, and so on. These were small, yet annoying configurations to redo.

Vagrant solved those problems. My local environment won’t be affected by OS upgrades/updates, and I can develop locally on a clone of production confident that my code won’t break when deployed.

Wait, What is Vagrant?

Vagrant is a tool for building development environments. Meaning you can get an encapsulated LAMP stack that matches your production server exactly. This ensures than when you push your project to production there are no surprise blank screens or errors (at least not because of different versions of PHP or other environmental differences).

Vagrant uses base boxes to set up a virtual machine (VM) running whatever software you want it to. You don’t have to set up that box yourself, you can find one that matches what your needs on a catalog like the HashiCorp’s Atlas box catalog.

But hold on that for a minute. For a very detailed explanation of base boxes see the Vagrant documentation. For a less detailed explanation, read this.

Base boxes are the smallest building block to set up a Vagrant environment. At it’s simplest a base box will have an operating system (Linux based in our case), a package manager (like apt-get in Ubuntu or yum in CentOS, this allows you to install software), SSH (which allows you to connect to your box, you will do this later), and a SSH user so Vagrant can actually connect. A note for the uninitiated: SSH stands for Secure Shell and in plain english means you can open your terminal, type in a command to connect to the Vagrant VM (vagrant ssh), and you will now be using the terminal inside your VM – it’s basically Inception for computers.

In case you are not familiar with what a VM is, it is an emulation of a different computer. If you have ever done any Internet Explorer testing on a Mac, you may have used or heard about VirtualBox or Parallels which allow you to boot up a Windows Machine and test on Internet Explorer, you’re familiar with a VM – these are VMs running windows as an OS.

We want our VM to be an emulator and not a simulator (at least eventually we do). We want to duplicate the inner workings of our production environment and not mimic the behavior of our production environments. You could say setting up something like MAMP out of the box is a simulation of your production environment (ie. a website is displayed, you can click around, there is a database and you can use PHP). What we want is for all the same software on our production environment to run the same way on our local machine. Having said that, at first, let’s set up a Vagrant Environment that is a simulation of our production environment … for science!

Get Started with Scotch (Box)

If you want to get started quickly and play around with a Vagrant Box I suggest checking out Scotch Box. This won’t match your production environment (unless it happens to be that by coincidence) but it will get you familiar with Vagrant pretty quickly.

It is worth noting that Scotch Box is not Vagrant. Scotch Box is a base box that comes provisioned (i.e. loaded up with) all the software they mention on the site (PHP, Apache, git, etc). Vagrant uses that box to set up the VM that will run all that software. Alternatively you could get a more bare bones base box that only has an OS and some basic necessities (as mentioned above when I talked about base boxes), you could then use something like Puppet as a provisioner to install all the software Scotch Box comes loaded up with. If you are wondering what a provisioner is or what provisioning is, I’ll explain that more in another post. For now, basically, provisioning is installing software on your VM and making it ready to use. A provisioner is a tool for doing just that. Usually it will work with a package manager (like yum or apt-get) to install software, and then run scripts to modify/add/delete directories and files. Vagrant gives you many options for provisioners such as shell scripting, puppet, and chef amongst others.

What’s Next?

Hopefully this has been a helpful introduction to Vagrant, I promise more “follow-along-at-home” type posts in the future. I wanted something to point back to as an absolute start-from-zero post. For that reason, let me know if there is anything that needs more clarification, if you find inaccuracies, if you have any questions. You can comment on this post or tweet @NJIMedia or @PoettersBetter to reach me personally.