Why is configuration management software written in Ruby?

• http://rcrowley.org/talks/ruby-on-ales-2011/index.html

Hi, I’m Richard Crowley

• Equal opportunity technology hater.
• DevStructure’s operator and UNIX hacker.

Puppet

Puppet

• There once was a systems administrator named Luke who didn’t want to use CFEngine anymore...

Puppet

• Ruby won out over Python and Perl.
• The autoloader is the
  frequently cited reason.

Puppet autoloader

• glob for source files.
• Each one registers itself
  using an internal DSL.

Puppet internal DSL

Puppet::Type.newtype(:package) do
  # ...
  def insync?
    # ...
  end
  # ...
end

Internal DSLs

• Give one kind of context
  while taking another away.

Internal DSLs

Puppet::Type.newtype(:package) do
  # ...
end

• It’s obvious this introduces a type.
• It’s not obvious what Ruby code goes here.

Internal DSLs

These are questions I shouldn’t have to ask:

• Can I define classes, modules,
  and/or methods in this scope?
• What is the fully-qualified name of
  a constant defined in this scope?
• Can I return in this scope?

Puppet resources

package { "ruby": ensure => installed }
file { "/etc/sysctl.conf":
    ensure => file,
    group => "root",
    mode => 0644,
    owner => "root",
    source => "puppet:///sysctl.conf",
}

• Orthogonal resources.
• Puppet makes its best-effort.

Puppet logging

WTF?

puppet agent --verbose

Seriously, WTF?

puppet agent --verbose --debug --trace

Puppet logging

• Uses syslog-appropriate levels.
• Color-coded if logging to a TTY.

Chef

Chef versus Puppet

This is not a religious war

• Functionally similar.
• Philisophically different.

Chef

• External Ruby DSL.
• Internal Ruby Ruby.

Chef resources

package "ruby" do
  action :install
end
cookbook_file "/etc/sysctl.conf" do
  group "root"
  mode 0644
  owner "root"
  source "sysctl.conf"
end

Chef insides

require 'chef/resource'

class Chef
  class Resource
    class Package < Chef::Resource
      # ...
    end
  end
end

External DSLs

Homegrown grammar versus
piggybacking on Ruby

• Not better. Not worse.

Internal DSLs

“What scope is that?” versus Ruby Ruby

• This is not the place to get fancy.

Whatever, I still like Puppet better

• Let’s drink beer and argue about it, though.

Despite their differences, Puppet and Chef both codify common systems administration tasks

• That sounds like how
  people used to use Perl.

Ruby as a better Perl

• First-class regular expressions like Perl.
• Backtick operator like Perl and shell.
• Relaxed parentheses like Perl.

Ruby as a better Perl

• Blocks are better than subroutine references.
• Real objects are better than fake objects.
  No more structs full of function pointers!

RubyGems == CPAN

• No release management or feature freezes.
• Double-edged sword.

RubyGems for
people on-call

• Regression testing.
• Semantic versioning.
• Slow-and-steady release cycle.

RubyGems for
people on-call

• Stability first.
• No one wants to depend on a moving target.

Rake

• A better GNU make.
• External Ruby DSL. Internal Ruby Ruby.

Rake

task :deploy do
  sh "git push production master"
end
file "foo.o" => "foo.c" do |t|
  sh "gcc -o foo.o foo.c"
end

Dependency programming

• Start with a goal.
• Satisfy its prerequisites first, recursively.
• If a prerequisite cannot be satisfied, abort.

Rake

• Intended for interactive use.
• Logging isn’t as necessary
  with fail-fast execution.

Capistrano

ssh-in-a-for-loop meets Rake

• Dependency-oriented but works
  on multiple hosts in parallel.

Capistrano

$ cap foo
  * executing `foo'
  * executing "echo foo >&1"
    servers: ["rcrowley.org"]
    [root@rcrowley.org] executing command
 ** [out :: root@rcrowley.org] foo
    command finished
  * executing "echo foo >&2"
    servers: ["rcrowley.org"]
    [root@rcrowley.org] executing command
*** [err :: root@rcrowley.org] foo
    command finished
$

• Each host can fail or succeed independently.
• Everything’s logged.

The Marionette Collective

• Orchestration via STOMP
  publish/subscribe rather than SSH.
• Scalable upgrade to ssh-in-a-for-loop.

The Marionette Collective

• General systems administration
  gone framework.

The Marionette Collective

• Lots of small tools:
  mc-ping, mc-find-hosts, mc-rpc, and more.
• Compose these to form new programs.
• It’s a UNIX system. I know this.

From middleware
to MCollective

• Everything starts life as a “script.”

“Scripts?”

• So trivial you don’t need to test them.

Idempotence

• N > 1 runs equivalent to N = 1 runs.
• PUT not POST.
• Manage whole files.

API design

• Principle of least surprise.
• Namespaces.
• Look for generic solutions.
  Not too hard, though.

Why even bother
with Ruby?

Data structures programs versus UNIX programs

UNIX programs

• Filesystem manipulation.
• System calls via GNU coreutils.

Data structures programs

• Need more than POSIX shell’s
  scalar variables.
• Need more than Bash’s one-dimensional indexed and associative arrays.
• Classes, methods, sockets,
  threads, events, etc.

Ruby can do both!

UNIX programs in Ruby

• File, Dir, and FileUtils
• Process
• Etc
• (Ruby editorializes too much.)
• http://tomayko.com/writings/unicorn-is-unix

Data structures in Ruby

• A hopefully obvious exercise
  left to the listener.

Composable Ruby, too

• It’s still a UNIX system.

Declare inter-file dependencies

• Make it easy to use part of your package.

...just to do this

require 'devise/orm/active_record'

Explicit is better
than implicit

• (Says The Zen of Python.)

Coupling

From the perspective of foo.rb

• Don’t trust that your dependencies are met.
• This implicitly couples you to the loader.

Magic

• The enemy of operable.
• Don’t get cute: it’s OK
  if your code looks like code.

Patterns, anti-patterns, and philosophies

Pattern

External DSLs

• Brevity is a virtue.
• Require developer restraint.

Anti-pattern

Internal DSLs

• Obscure the Ruby Ruby scope.

Pattern

Dependency programming

• Powerful failure handling.
• Natural for interactive tasks.

Pattern

Idempotence

• Never be scared to run it again.

Anti-pattern

Magic

• Requires intimate knowledge
  to maintain and operate.

Philosophy

Explicit is better
than implicit

• Reduces coupling.
• Provides context.
• Promotes reuse.

Philosophy

Look for generic solutions

• Not too hard, though.
• Strive to remove special cases.

Thank you

• richard@devstructure.com or @rcrowley
• P.S. Use DevStructure!