Introduction

I really enjoy using Vagrant to do my development. I’ve even posted my Base Vagrant Package.

But I found I was still doing the same things over and over again: setting up postgres, and setting up the RVM. Yes, I had automated 80% of my “get a new Rails box up”, but that extra 20% eluded me.

Today I said, “No more”

I’ve improved on my package - now we set up postgres and RVM.

Now, my strategy

My strategy for new virtual machines is now

$ git clone git://github.com/rwilcox/vagrant_base.git rpw_NEWPROJECT
$ vi Vagrantfile # tweak project paths etc
$ vi manifests/lucid32. # search for PROJECT_NAME, start adding packages and editing the RVM name
$ vagrant up

(go get a sandwhich, because the first vagrant up will take 15 minutes)

Take a look

The best place to look at what I do is to dig into the manifest file.

I believe this provides one of the few examples on the net on how to do all these things together.

Notes

The RVM puppet manifests require Puppet 2.7.11, released Feb 23, 2012. You may need to update the puppet in your base boxes (sudo gem install puppet), then package them up again.

It’s important to remember that Puppet is a great tool for machine setup, but Capistrano (or your favorite deploy tool flavor) is better for deploying actual code.

Capistrano as a machine setup tool isn’t all that great. Even a simple task can get caught up in headbashing, as I found out when trying to set up RVM and gemsets. It’s so much easier when you’re using a tool (Puppet) that’s meant for those things.

Likewise, I wouldn’t want to use Puppet to deploy, bundle install, etc etc. the Capistrano community does all that stuff really well, thank you.

How to make your Rails deployments better with Puppet

Vagrant and virtual machines are great for development environments, but I’m also a big fan of reusing everything I can. Puppet was really meant to automate managing of servers… so why don’t we use the same Puppet files in managing our servers?

You can! Use the puppet modules and scripts in my vagrant base and Supply Drop.

If you’re using Vagrant to test this locally, do NOT set a provisioner - supply_drop will take care of that for us. (Normally you’d want a provisioner, because you don’t cap deploy:dev, but this is a simulated deploy test).

Your cap deploy:setup should call cap puppet:bootstrap: (appropriate OS here), in addition to creating a folder for your Git repo to land. Nothing else.

cap deploy should call cap puppet:apply. (You may want to create a cap deploy:pre task, which checks the syntax of the puppet files as well as doing anything else you need).

The thing to watch out for here is that your Puppet file must be named puppet.pp in current versions of Supply Drop.

Using Puppet both insures your development environments are consistent with your production environment, AND uses a tool that’s declarative instead of procudural (avoiding Capfile hell).

Supply Drop needs some improvements (for example, different machine roles in Capistrano should be able to have different puppet configs), but it’s a tool worth keeping an eye on.

Next Episode: A local QA stack with Vagrant

Over the upcoming weeks I hope to write about Puppet, Vagrant and Supply Drop to bring up a local QA stack for your application stack. Your application stack probably has multiple machines (web front end, application server, database server), and you can replicate the entire stack with Vagrant. For now, there’s an excellent starter article: Bootstrapping Vagrant with Puppet.