Velocity 08: Puppet In-Depth and Hands-On


The final talk of the day (hope I make my flight) was by Luke Kanies of Reductive Labs on Puppet.

Most automation tools are based on SSH and as a result, they suck. The problem is that the intersection of administrator and developers is very small. Luke wanted Puppet to be so good it was like bringing a gun to a knife fight. The goal: manage lots of machines with very little effort.

Luke makes an analogy about the transition from assembly to C and moving from commands and files to "resources." Resources are abstract and portable. Abstraction is the most important idea here. Why do we have to know how to, for example, update packages on Fedora and Debian.

Packages are the basic unit. You can install, uninstall, update, etc. packages. There are 23 package types. Resources say what to do for a given package. Here's an example for SSH:

class ssh {
  package { ssh: ensure => installed }
  file { sshd_config:
    name => $operatingsystem ? {
      Darwin  => "/etc/sshd_config",
      Solaris => "/opt/csw/etc/ssh/sshd_config",
      default => "/etc/ssh/sshd_config"
    },
    source => "puppet://server.domain.com/files/ssh/sshd_config"
  }
  service { ssh:
    name => $operatingsystem ? {
      Solaris => openssh,
      default => ssh
    },
    ensure    => running,
    subscribe => [Package[ssh], File[sshd_config]]
  }
}

The class provides intent; by creating a class for ssh, you're saying it should be installed and running. Note that the installation, configuration, and service all have their own definitions.

Nodes allow you to associate hosts, by type, with resources. Transactions make sure everything is in it's correct state. Transactions are idempotent--they don't have an effect if machines are in the right state. Idempotency allows management throughout the lifecyce. Puppet should manage a machine from it's birth to death.