Sprinkle – Automated Infrastructure for the Rest of us

Automatically setting up and maintaining my servers is a must for me. Only if everything I install and configure on a server is scripted I’m sure I know what’s there and that it stays that way. Having automated infrastructure enables me to schedule a critical setup change at 3 am and be on the safe side even though my brain might already be half asleep. After having written a ton of capistrano tasks (and creating a mess with it), looking into puppet and chef, writing my own tool (carpet), my colleague finally gave Sprinkle a try.

Sprinkle is based on capistrano and uses the same push model without any additional infrastructure. That makes it easier to use than the more heavy weight tools like puppet and chef. As long as your infrastructure is small enough, you might be ok with actively pushing out changes – if it becomes bigger, puppet or chef are the way to go. So, how did we setup things?

Staging And Production Environments

For us, the very first thing we do with any new provisioning tool is make the configuration aware of the environment we want to setup. Usually we have a staging and a production environment. By default, the tool will use staging. If we want to touch production, we’ve to set a shell variable explicitly (we use DEPLOY_ENV=production for that).

Sprinkle Policies for Describing Server Setups

Sprinkle has the concept of policies to describe which services a server should run. We have a policy for our custom Ruby on Rails stack, which simply states that it needs a SCM, a web server and so on.

policy :ruby_on_rails_stack, :roles => :app do
  requires :private_key
  requires :webserver
  requires :balancer
  requires :memcached
  requires :database
  requires :appserver
  requires :scm
  requires :public_ip_reminder
end

The specification, which SCM (git for us) or which web server (nginx in our case) shall be installed, will be done by the packages you use.

Sprinkle Packages for Realizing Server Setups

Each package in Sprinkle provides a service (like SCM or web server) used, which can be used by policies. A package describes in detail, what needs to be done to get a service up and running. You can install OS packages (e.g. by using apt-get), configure them, etc. Here is the example of a ruby package (taken from the Sprinkle home page):

package :ruby do
  description 'Ruby Virtual Machine'
  version '1.8.6'
  source "ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-#{version}-p111.tar.gz"
  requires :ruby_dependencies

  verify do
    has_file '/usr/bin/ruby'
  end
end

Defining Your Infrastructure With Sprinkle

We use a CommonConfig object to hold all configuration parameters for our environments like the target server roles, IP addresses, memcached size, MySQL query cache size, etc. Using such a central place for all those parameters enables us to have a common way of using them throughout the Sprinkle policies, packages and configuration file templates. Depending on the environment (staging or production) our Sprinkle setup will pull in the CommonConfig for that environment. That comes in pretty handy.

Sprinkle Fits the Way we Work

Sprinkle’s push model and its usage of Capistrano fits the way we were doing things anyways. The fact, that Sprinkle only installs or changes things if they are not as defined as well as its dependency management of packages are a great value compared to self written Capistrano tasks.

CWT62DBW25S9