Using Puppet to Deploy with a Push

Prior to Fiesta my ops background was pretty minimal. Managing ops for Fiesta quickly taught me the value of a configuration management system like Puppet. I think it’s a great tool and we’ll probably do some more posts about how we’re putting it to use. In this post I’m going to explain how we use Puppet to manage deploying new versions of our codebase.

Deploying from Git

One of the goals I had in mind with our deployment infrastructure was the ability to deploy new code just by doing a `git push`. This minimizes the friction involved in a deploy and incentivizes us to deploy often.

The first step in the deployment process is for puppet to update a version of our repository on each Puppet node (this happens every time that Puppet runs). Here’s the section of our configuration file that manages that:

vcsrepo { "/home/fiesta/fiesta":
  owner => fiesta,
  group => fiesta,
  ensure => latest,
  revision => "prod",
  provider => git,
  require => [ Package["git"],
               Sshkey["git.fiesta.cc"] ],
  source => "ssh://git@git.fiesta.cc/home/git/fiesta.git"
}

For those of you who are new to Puppet, I’ll walk through this rule. We are configuring a new `vcsrepo`, which is a resource type for working with version control systems. The repository will be located at “/home/fiesta/fiesta”, and we configure it with a series of parameters. “owner” and “group” specify Unix permissions for the repository. The “ensure” parameter tells Puppet to always update the repository to the latest version. “revision”, “provider” and “source” establish the branch we want to update, the type of VCS we are using, and where to update the repository from, respectively.

Lastly, we specify several requirements (using the “require” parameter). The requirements are used by Puppet to establish a dependency chain and properly order the operations that need to be performed in a given Puppet run. Here, we say that updating this repository depends on having Git installed and having the proper SSH key in place. Both of those steps are managed elsewhere in our configuration file.

After updating the repository, we still need to restart the various server processes that run based on that code. We do that by configuring each of those services in Puppet, here’s the configuration for one of our web servers:

service { "www":
  ensure => running,
  subscribe => Vcsrepo["/home/fiesta/fiesta"],
  start => "/home/fiesta/fiesta/www.py start",
  stop => "/home/fiesta/fiesta/www.py stop",
  status => "/home/fiesta/fiesta/www.py status",
  require => Service["mongod"]
}

We can see some of the same patterns as above. This time, we’re configuring a `service`, which we want Puppet to ensure is running. We specify “start”, “stop”, and “status” commands, which Puppet can use to determine the status of the service and start/stop/restart it as needed. Our service depends on another service, “mongod”, which we’ve configured elsewhere.

The interesting piece for the problem at hand is the “subscribe” parameter. We subscribe the “www” service to the `vcsrepo` that we configured above. That means that every time the repository is updated the “www” service will be restarted using the new code.

Next Steps

What we’ve configured so far is a system that will restart the web server when new code is pushed to the “prod” branch. The deployment happens only when Puppet next runs, though (we schedule Puppet runs for approximately every 30 minutes). It’d be interesting to look at adding a git post-receive hook to our server that could run the deployment immediately after a push. Another thing to look at would be improving our ability to roll-back deployed code.

Is anybody else using a set up similar to this? What issues have you encountered and how are you handling them?