LAMP development setup with Vagrant and Puppet

June 23, 2013

I’m borrowing this idea from a fellow co-worker. My usual dev setup is a virtual Debian machine in hyper-v which I configure with samba. My old way has worked quite well until I started using Sourcetree full time. The problem with Sourcetree and a huge git repository over Samba is that the performance is painfully slow, too many small files wrecks network speeds. So I’ve been experimenting with making my virtual machines mount /var/www from my local machine instead, this works, but there’s a lot more configuration involved in that process.

I’ve known for quite sometime that a coworker uses Vagrant for his dev-setup, but I’ve been avoiding it because I don’t really like virtualbox, but this weekend I felt I had to try it out, and I’m convinced that this is the most appropriate way to setup a local dev environment. It’s important that you deactivate hyper-v on your windows system if you have it activated, this is because it “hi-jacks” VT-x (and I guess AMD-VT) which means that virtualbox can’t run 64-bit operating systems.

I feel I need to say this before I go in to too many details, I’m not familiar with puppet, and I’ve never worked with it before, so I cooked this up by browsing through various projects on github and taking notes on how they’ve solved different issues. And because I like being on the testing repository when using debian I had to roll my own Vagrant box.

I’m guessing you’re scratching your head and haven’t yet really figured out what the hell vagrant and puppet is? Well vagrant is just a packaging tool for virtual machines. In other words, people can create basic stripped down virtual machines (called boxes in vagrant-language), these base-boxes can then be used as the basic building blocks for an environment (be it php, python, ruby, you name it). The base box is copied over to each new project that you run, and this is why it’s powerful, none of your data should be on the virtual machine, as it’s just a container, if something breaks, you just destroy the machine and create a new from the base model (almost no downtime), but the base machine must still be configured for you needs, right?

And this is where Puppet comes in, puppet is something that is called a provisioner (there’s other provisioners too, but I chose puppet). What puppet does is that it follows pre-determined paths, like for instance, you always want to have the latest MySQL-server version on your machine, then you can instruct puppet that on every boot of the machine, it should do an apt-get update and apt-get install mysql-server. This means that you can create unlimited and identical development setups, and you can be sure that they’re all exactly the same. And if you break something in the virtual machine, you can always recreate the machine with just a few simple commands.

So let’s get down to business, I’ve already documented on how you should use this vagrant machine on github (the readme.md). But I thought I’d go through the ins and outs of the machine that I’ve created.

My puppet script, should in theory, always get the latest versions of apache, mysql and php. After it has done these steps it starts to mount different files from the repository to the virtual machine. These files are just standard config files that you usually want to change and they’re all located under configs. The files that you might be most interested in is dev-environment/configs/mysql/init.sql which is a sql script that runs everytime it changes, here you can add all users that you need, and the other file that you might be interested in is dev-environment/configs/apache2/default.conf which is the default virtualhost file that is loaded to apache.

If you’ve followed my installation instructions, then you should also have a folder called www located in dev-environment/www this is the web root for apache, and this is where all your code should be.

And there really isn’t that much more too it, clone the repository and happy coding!

Tags