In my development workflow, my tools are the thing I deliberate over most. As anyone who follows me on Twitter can attest to, I’m a huge fan of Git and Sublime Text, and conversely I hate Subversion and PhpStorm. I genuinely believe that my tools can make or break how I work and I’m always looking to improve this, constantly searching out for new tools.
By far and away, the tool that has changed how I work the most in the past year is Vagrant with the Puppet configuration tool. For those who don’t know, Vagrant is a tool to create and manage virtual machines, while Puppet is a tool to configure and manage server configuration. The two work extremely well together as a tool for developing in a clean, reproducible environment. Plus, it also provides an easy way to replicate server configuration between your development and production servers.
So, how does it work? Let’s walk through how to set up a development server, plus using that configuration in production!
The first step to getting started is to work out what operating system you want to use. Personally, I’m a fan of Ubuntu Server (12.04 LTS, Precise Pangolin, to be specific), so I’ll be using that in examples, but you can use whatever you like. Some official boxes are available for Ubuntu, while others are available on VagrantBox.es (you can also build your own, but until you’re familiar with Vagrant, I’d recommend using a premade box).
To start off with, you’ll want to download your chosen box to avoid having to redownload it every time you recreate your box.
$ vagrant box precise32 http://files.vagrantup.com/precise32.box
Next up, you want to create your Vagrant configuration and get ready to boot it up. This will create a Vagrantfile in your current directory, so set yourself up a new directory where all your Vagrant-related stuff will live.
$ mkdir example-site/ $ cd example-site/ $ vagrant init precise32
Now, let’s boot up your new virtual machine and make sure it works. The
up command will create a virtual machine from your base box if you don’t already have one, boot it, then provision it for usage. We’ll come back to that part in a bit.
$ vagrant up
To get access to your new (running) virtual machine, you’ll want SSH access. If you’re on Linux/Mac,
vagrant ssh will work perfectly, but it’s a little harder on Windows. Vagrant tries to detect if your system supports command-line SSH, but doesn’t detect Cygwin environments. For cross-platform parity, I set up an alias called
vsh that points to
vagrant ssh on my Mac, and the SSH command on Windows, which looks something like:
# Mac/Linux $ alias vsh='vagrant ssh' # Windows $ alias vsh='ssh -p 2222 -i "~/.vagrant.d/insecure_private_key" firstname.lastname@example.org'
We’re done testing our basic setup, so we can shut our VM down and destroy it, since we’ll want to boot from scratch next time.
$ vagrant destroy
We’ve now verified that the virtual machine works nicely, so let’s bust open your Vagrantfile and get tweaking it. Networking is the first thing we’ll need to get set up, so that we can access our server. Vagrant automatically forwards port 22 from the VM to port 2222 locally so that we can connect, but we also need port 80 for nginx, and we might need more later. We can either set up separate forwarded ports, or enable private networking (my preferred option). Uncomment the private networking line to enable it:
config.vm.network :private_network, ip: "192.168.33.10"
This IP address can be whatever you want, but you need to make sure it’s not covered by your existing network’s subnet. This is usually fine unless you have a custom subnet, in which case
10.x.x.x might be a better choice.
You’ll also want to set up a hostname for this. In your
/etc/hosts file (on Windows,
vagrant.local to this IP, along with any subdomains you may want. (Note: I’ve seen people use other names here like
wp.dev. Keep in mind that these may end up being actual domain names some day with ICANN’s new TLD policy, whereas
.local is reserved for exactly this use.)
We’ve now got a working Vagrant setup. In part 2, we’ll take a look at setting up Puppet to get your software working automatically.
3 thoughts on “A Vagrant and the Puppet Master: Part 1”
Great intro post Sir! 🙂
I was thinking about this at 4am this morning (as you do) when I woke up in the middle of the night. I have a couple of questions (note this is before I’ve followed through the tute).
1) How much HDD space does this Vagrant setup normally take up?
2) How much RAM does Vagrant use on average?
1) Depends on the box used. For example the pre-built precise64 box (similar to the precise32 box used in this article) has a 10GB dynamically allocated disk, which means it grows to maximum 10GB. The actual size of my current vm is 2GB. Check http://www.vagrantbox.es/ for the initial sizes of those boxes. The ‘official’ precise64 box is around 320MB, but your free to build your own and make it smaller (if you can).
2) Vagrant’s default RAM size is 512MB per vm, but this can easily be configured in the Vagrantfile, globally or per vm.
Thanks for answering my questions! 🙂 Most appreciated. Since this post and my comment Ryan’s actually helped our company set up Vagrant for our projects so every time we work on each project we have a consistent starting base.
Check it out if you like: https://github.com/sennza/WordPress-Skeleton.