Luke Kanies: Puppet author

A server automation tool
"... because SSH and a for loop just don't cut it any more."

Some things it does
	Manage machines without connecting directly
	Creating multiple identical machines quickly
	Deploying new apps and app instances across networks

Every component in the system can be replaced and reused separately
	Server
		Compiler (change language)
		Fileserver
		CA
		Report Handler
	Networking (XMLRPC over HTTPS)
	Client
		Resource abstraction layer
		Transactions
		Resource server

Resource abstraction layer: biggest difference
	Don't care about the details
		e.g.: diffs betw dpkg, rpm, ebuilds, ports, etc

Puppet is mostly about specifying and applying configurations

Configuration process
	Facter (collects host info) -- contacts server
	Server tells client what it should be like
	Client checks whether it's in sync for each resource

Transactions do the actual work
	Make change, log it, etc

Specifying configurations
-------------------------

Resources
	Type, name, attributes
	V. good reference

Classes: collections of resources

Resource relationships
	e.g. starting service before replacing the configuration file
		with a secure one
	"subscribe" keyword: can auto-restart service if config file changes
	another 3 keywords to do similar things

The whole service
	class ssh {
		package { ssh: ensure => installed }
		file { sshd_config:
			name => "/etc/ssh/sshd_config",
			owner => root,
			group => root,
			source => "puppet://server/apps/ssh/sshd_config"
			before => Package[ssh]
		}
		service { sshd:
			ensure => running
			subscribe => [Pcackage[ssh], File[sshd_config]]
		}
	}

Q: Is there any library of Puppet config files ("recipes")?
A: Not there yet, but wants to provide it and working on it

Defined types
	Based on collections of existing resource types
	Generating files, making small changes to existing systems

	define apache::virtual_host($docroot, $ip, $order = 50,
	$ensure = "enabled") {
		...
	}

	Template config files (httpd.conf precursor e.g.) are essentially full Ruby.

Bringing it together
	node culain inherits basenode {
		include puppet::server, mailserver
		include webserver, webserver::mail
	}
	node rh3a inherits basenode {
		include os::redhat
	}
	node laeg inherits basenode {
		include yum::repository, puppet::server
		include webserver, webserver::trac
	}

Not just centralized
	ralsh: resource abstraction layer shell
		- Queries info about any resource
	Can run just on a single host.
		- For example, building a Puppet server with Puppet configs
		- Or when the network's down, etc

Thinking about the future
	Moving parts into standalone tools (e.g. nodes)
	Building a site to facilitate sharing of modules
	Formalizing best practices

Other planned projects: Runnels, Kinial?

Approach
	Use bare minimum with kickstart, just enough to run Puppet
	Take it from there with Puppet

Q: Scalability
A: Issues around 300-400 with default server Webrick. There is Mongrel
	integration, and can run multiple Mongrel processes to scale essentially
	infinitely.

Can simultaneously generate host configuration and a config to monitor it

Change control has become the biggest problem.