This week, I was fortunate enough to meet up with the Cheadle Geeks group. I got talking to a couple of people about Vagrant and Puppet, and explaining how it works, and I thought the best thing to do would be to also write that down here, so that I can point anyone who missed any of what I was saying to it.
Essentially, Vagrant is program to read a config file which defines how to initialize a pre-built virtual machine. It has several virtual machine engines which it can invoke (see [1] for more details on that), but the default virtual machine to use is VirtualBox.
To actually find a virtual box to load, there’s a big list over at vagrantbox.es which have most standard cloud servers available to you. Personally I use the Ubuntu Precise 32bit image from VagrantUp.com for my open source projects (which means more developers can get involved). Once you’ve picked an image, use the following command to get it installed on your development machine (you only need to do this step once per box!):
vagrant box add {YourBoxName} {BoxURL}
After you’ve done that, you need to set up the Vagrant configuration file.
cd /path/to/your/dev/environment
mkdir Vagrant
cd Vagrant
vagrant init {YourBoxName}
This will create a file called Vagrantfile in /path/to/your/dev/environment/Vagrant. It looks overwhelming at first, but if you trim out some of the notes (and tweak one or two of the lines), you’ll end up with a file which looks a bit like this:
Vagrant.configure("2") do |config|
config.vm.box = "{YourBoxName}"
config.vm.hostname = "{fqdn.of.your.host}"
config.vm.box_url = "{BoxURL}"
config.vm.network :forwarded_port, guest: 80, host: 8080
# config.vm.network :public_network
config.vm.synced_folder "../web", "/var/www"
config.vm.provision :puppet do |puppet|
puppet.manifests_path = "manifests"
puppet.manifest_file = "site.pp"
end
end
This assumes you’ve replaced anything with {}’s in it with a real value, and that you want to forward TCP/8080 on your machine to TCP/80 on that box (there are other work arounds, using more Vagrant plugins, different network types, or other services such as pagekite, but this will do for now).
Once you’ve got this file, you could start up your machine and get a bare box, but that’s not much use to you, as you’d have to tell people how to configure your development environment every time they started up a new box. Instead, we’ll be using a Provisioning service, and we’re going to use Puppet for that.
Puppet was originally designed as a way of defining configuration across all an estate’s servers, and a lot of tutorials I’ve found online explain how to use it for that, but when we’re setting up Puppet for a development environment, we just need a simple file. This is the site.pp manifest, and in here we define the extra files and packages we need, plus any commands we need to run. So, let’s start with a basic manifest file:
node default {
}
Wow, isn’t that easy? :) We need some more detail than that though. First, let’s make sure the timezone is set. I live in the UK, so my timezone is “Europe/London”. Let’s put that in. We also need to make sure that any commands we run have the right path in them. So here’s our revised, debian based, manifest file.
node default {
Exec {
path => '/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/sbin:/usr/sbin'
}
package { "tzdata":
ensure => "installed"
}
file { "/etc/timezone":
content => "Europe/London\n",
require => Package["tzdata"]
}
exec { "Set Timezone":
unless => "diff /etc/localtime /usr/share/zoneinfo/`cat /etc/timezone`",
command => "dpkg-reconfigure -f noninteractive tzdata",
require => File["/etc/timezone"]
}
}
OK, so we’ve got some pretty clear examples of code to run here. The first Exec statement must always be in there, otherwise it gets a bit confused, but after that, we’re making sure the package tzdata is installed, we then make sure that, once the tzdata package is installed, we create or update the /etc/timezone file with the value we want, and then we use the dpkg-reconfigure command to set the timezone, but only if the timezone isn’t already set to that.
Just to be clear, this file describes what the system should look like at the end of it running, not a step-by-step guide to getting it running, so you might find that some of these packages install out of sequence, or something else might run before or after when you were expecting it to run. As a result, you should make good use of the “require” and “unless” statements if you want a proper sequence of events to occur.
Now, so far, all this does is set the timezone for us, it doesn’t set up anything like Apache or MySQL… perhaps you want to install something like WordPress here? Well, let’s see how we get other packages installed.
In the following lines of code, we’ll assume you’re just adding this text above the last curled bracket (the “}” at the end).
First, we need to ensure our packages are up to date:
exec { "Update packages":
command => "sudo apt-get update && sudo apt-get dist-upgrade -y",
}
Here’s Apache getting installed:
package { "apache2":
ensure => "installed",
require => Exec['Update packages']
}
And, maybe you’ll want to set up something that needs mod_rewrite and a custom site? Add this to your Vagrantfile
config.vm.synced_folder "../Apache_Site", "/etc/apache2/shared_config"
Create a directory called /path/to/your/dev/environment/Apache_Site which should contain your apache site configuration file called “default”. Then add this to your site.pp
exec { "Enable rewrite":
command => 'a2enmod rewrite',
onlyif => 'test ! -e /etc/apache2/mods-enabled/rewrite.load',
require => Package['apache2']
}
file { "/etc/apache2/sites-enabled/default":
ensure => link,
target => "/etc/apache2/shared_config/default",
}
So, at the end of all this, we have the following file structure:
/path/to/your/dev/environment
+ -- /Apache_Site
| + -- default
+ -- /web
| + -- index.html
+ -- /Vagrant
+ -- /manifests
| + -- site.pp
+ -- Vagrantfile
And now, you can add all of this to your Git repository [2], and off you go! To bring up your Vagrant machine, type (from the Vagrant directory):
vagrant up
And then to connect into it:
vagrant ssh
And finally to halt it:
vagrant halt
Or if you just want to kill it off…
vagrant destroy
If you’re tweaking the provisioning code, you can run this instead of destroying it and bringing it back up again:
vagrant provision
You can do some funky stuff with running several machines, and using the same puppet file for all of those, but frankly, that’s a topic for another day.
[1] Vagrant is extended using plugins. There is a list of plugins on this Github Wiki Page. The plugins here can include additional virtual machine back ends (called Providers in Vagrant terminology), and methods of configuring the OS after bootup (called Provisioners), but also anything around defining where to find resources, to define network addresses, even to handle caches and proxies.
[2] If you’re not using Git, you should be! However, you might want to add some stuff to your .gitignore – in particular, Vagrant adds a directory called /path/to/your/dev/environment/Vagrant/.vagrant where it puts the VMs it creates.