This post is over a year old, its content may be outdated.

Matt Wilcox

Web Development

Notes Jan 01st 2014

Vagrant, Puppet, Docker?

What are these and why should I care?

Over the last few months there have been a few technologies that have piqued my interest – three in particular were Vagrant, Puppet, and Docker. In true Open Source style the website's don't do a particularly good job of explaining why you'd want to use them – unless you already understand what they do – and then their explanations make perfect sense. Over Christmas I sat down, bought a book or two, and learned more…

What problems could Vagrant, Puppet, and Docker solve for web developers?

It turns out quite a few things depending on what type of work you do, but some key points;

  • They enable you to develop on your local machine exactly as if it was the real 'live' server – because they allow your home machine to be an exact duplicate of your live server's configuration (if you want).
  • They enable your local machine to run as if it were any number of different servers, even simultaniously – got three projects all running utterly different software, different operating systems, and configured completely different? No problem, you can run them all on your local machine. Your project requires a seperate web server and database server? No problem, run both at once on your local machine.
  • They enable you to test old or current projects on new or different servers – will your app run on PHP5.8 without hickups? Find out the really easy way.
  • They enable anyone else to work on the exact same set-up simply by installing Vagrant, copying your project files, and then typing 'vagrant up'. You configure your project once, you (or anyone else you want to) can use it again, anywhere, with no further set-up.

What's the workflow?

The workflow is largely based around Virtual Machines. Vagrant is just a manager for getting, running, and destroying Virtual Machines – and that really is all it does. But in doing that it allows you to have a tailored server for every project instead of having your local machine set up as a MAMP/WAMP server with dozens of projects running off it. With Vagrant, once you've configured your server for a specific project, you navigate to your projects working directory in Terminal (which contains a file for Vagrant telling it what Vagrant needs to load) then type 'vagrant up' – and it loads up a local development environment that is running a virtual server configured exactly how you need it. As tailored as you need it to be. Puppet is what you use to configure the virtual server that Vagrant starts and stops. Vagrant uses a 'base box' which is essentially a fresh install of whichever operating system it is you need to run at the time. Puppet is a utility that runs automatically after you've typed 'vagrant up' and it ensures that the virtual server is set-up to your specification if it isn't already: getting the latest nginx, adding users, setting permissions, starting services, etc. Why have Puppet do that instead of having a base-box already configured? Economy. Instead of having 10 projects each with 10 full OS installs, Vagrant can just re-use the base-box which any of the projects share. The stuff Puppet does is done on top of the base box, without actually changing it. Docker is very new, and it kind of does both Vagrant and Puppet's jobs, but in a different way. It's a bit too new to use just now (it even says so on their site) – and I've not entirely wrapped my head around it – but it's one to keep an eye on in 2014 for sure. Docker promises to be more efficient than Vagrant due to the way it works.

What am I going to use them for?

I'm hoping to replace our current workflow at View Creative. Right now we all have Macs with their own installs of Apache and PHP – when we upgrade, or a new person comes along, we have to manually set-up each and every Mac. It's easy to end up with problems where one machine isn't configured quite the same as another, and it's just a waste of everyone's time having to repeat the same tasks for each member of staff. With this workflow, we can set up the project once, save the vagrant & puppet configuration files in with the project, and that's that. Whenever one of us checks out that project fresh onto a new machine all the set-up required is: Terminal, vagrant-up. Done. If we upgrade OSX and it borks the Apache config again, or forces a newer version of PHP, it makes no difference. If we have to look at a 4yr old project and we're all running utterly different software now – no bother, it doesn't matter. The project itself has the same VM we built it with. Another benefit, I hope, is that we'll be able to get Grunt configured as part of it all; which would mean that whoever checks out the repository for the project has the same SCSS builder with the same settings, the same auto image optimisations applied, the same minification settings, the same unit tests, etc.

What else could you do?

Actually integrate your live servers. There's nothing to stop you having Puppet installed on a live server. And no doubt a bunch more things. I'm quite literally only just getting started with it all, so no doubt there's a lot left to learn.