Sprinkle – Automated Infrastructure for the Rest of us

by on November 26, 2009 · 5 comments

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.

Did you enjoy this article? Get new articles for free by email:


Comments

  1. says

    You nailed it with this blog post, Matthias. When your infrastructure is small (or bounded well) the push approach makes everything easier, and it just ‘feels’ right. Part of that is that you can fit the entire state of the system in your head at one time – if you have 10 servers, you can be pretty sure what they are all up to at any given time. A thousand is a different matter altogether. :)

    One of my favorite uses for Sprinkle has been to actually get Chef distributed to systems – at least two people have put out examples:

    * Michael Hale’s sprinkle_chef http://github.com/mikehale/sprinkle_chef/
    * Ladislav Martincik’s chef-bootstrap http://github.com/lacomartincik/chef-bootstrap

    I couldn’t be happier with the way the configuration management world is feeling it’s way towards a deeper understanding of the trade-off’s involved with tool selection, and that the “There’s More Than One Way To Do It” ethic is starting to creep in more and more.

    Great work!

  2. Amit says

    Nice article. I have been researching out on configuration management tools like Puppet, Salt, Sprinkle etc. You mention that Sprinkle works well when you have a small infrastructure. Can you detail on what range could be categorized as small? Would 200-500 servers be treat as small? Also what are key points why Sprinkle would suit small infrastructures and puppet/chef would not?

Trackbacks

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>