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.
Tags:
velocity08
puppet
automation
infrastructure
