sprinkle

Sprinkle

Sprinkle is a software provisioning tool you can use to build remote servers with, after the base operating system has been installed. For example, to install a Rails or Merb stack on a brand new slice directly after its been created.

• #sprinkle channel on the Freenode IRC Network

Installation

Install:

$ gem install sprinkle

Packages

Properties of packages such as their name, type, dependencies, etc, and what packages apply to what machines is described via a domain specific language that Sprinkle executes (in fact one of the aims of Sprinkle is to define as concisely as possible a language for installing software).

An example:

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

This defines a package called ruby, that uses the source based installer to build Ruby 1.8.6 from source, installing the package ruby_dependencies beforehand. The package verifies it was installed correctly by verifying the file /usr/bin/ruby exists after installation. If this verification fails, the sprinkle script will gracefully stop.

Reasonable defaults are set by sprinkle, such as the install prefix, download area, etc, but can be customized globally or per package (see below for an example).

Since packages come in many forms (eg. gems, pre-compiled debs, compressed source tar.gz, etc), Sprinkle supports many different installer types, giving you the most amount of flexibility of how you'd like software installed. New installer types can be added into the system easily.

For example, you could install Rails via gems, nginx via source, and mysql via APT, while retaining the flexibility of changing installer types as software is updated upstream.

Sprinkle also supports dependencies between packages, allowing you specify pre-requisites that need to be installed in order.

Policies

Packages can be grouped into polices to define several packages that should be installed together. An example:

policy :rails, :roles => :app do
  requires :rails, :version => "3.2"
  requires :appserver
  requires :database
  requires :webserver
end

This defines a policy called Rails, that applies to machines of role :app. The policy includes the packages rails (version 3.2), appserver, database and webserver.

The appserver, database and webserver packages can also be virtual, prompting the user for selection if multiple choices for the virtual package exist.

Sprinkle is architected to be extendable in many ways, one of those areas is in its deployment of commands to remote hosts. Currently Sprinkle supports the use of Capistrano, Vlad, or a direct net/ssh connection to issue commands on remote hosts via ssh, but could also be extended to use any other command transport mechanism desired. Sprinkle can also be configured to simply issue installation commands to provision the local system.

Sprinkle is a work in progress and I'm excited to hear if anyone finds it useful - please feel free to comment, ask any questions, or send in any ideas, patches, bugs. All most welcome.

Marcus Crafter -

APPENDIX

A full example deployment

A full example Sprinkle deployment script for deploying Rails (via gems), MySQL (via APT), Apache (via source) and Git (via source with dependencies from APT):

…

Please see the examples directory for more complete examples of Sprinkle deployment scripts, and also the Passenger Stack github page and video by Ben Schwarz.