Puppet @
Stanford
University
Digant C Kasundra
Information Technology Services
digant@stanford.edu

A Little History...

A Little History...
• Consistency of configuration

A Little History...
• Consistency of configuration
• Consistency of practice

A Little History...
• Consistency of configuration
• Consistency of practice
• Started on August 24th 2006, 2:10pm

A Little History...
• Consistency of configuration
• Consistency of practice
• Started on August 24th 2006, 2:10pm
• 73, 167 lines of puppet manifests

A Little History...
• Consistency of configuration
• Consistency of practice
• Started on August 24th 2006, 2:10pm
• 73, 167 lines of puppet manifests
• 1, 784 classes

A Little History...
• Consistency of configuration
• Consistency of practice
• Started on August 24th 2006, 2:10pm
• 73, 167 lines of puppet manifests
• 1, 784 classes
• 20 sys admins

A Little History...
• Consistency of configuration
• Consistency of practice
• Started on August 24th 2006, 2:10pm
• 73, 167 lines of puppet manifests
• 1, 784 classes
• 20 sys admins
• 4 puppet masters servers, 2 puppet queue servers

Agenda

Agenda
• Coding Practices

Agenda
• Coding Practices
• Packages vs. Puppet

Agenda
• Coding Practices
• Packages vs. Puppet
• Team Practices

Agenda
• Coding Practices
• Packages vs. Puppet
• Team Practices
• Server Practices

Agenda
• Coding Practices
• Packages vs. Puppet
• Team Practices
• Server Practices
• ITIL and other crap as management interfaces

Coding Practices

Coding Practices
• Style Guide
• Reusable Code and Modules
• Well-named

Style Guide

Style Guide
• Legible, easy to parse

Style Guide
• Legible, easy to parse
• bigger the group, uglier the code

Style Guide
• Legible, easy to parse
• bigger the group, uglier the code
• bigger the manifest, the harder to parse

Unclean
tango { “alpha”:
mode => 600,
ref => “adam”,
prelink => “yankee”,
ensure => present,
}
tango { “delta”:
mode => 644,
prelink => “foxtrot”,
ref => “dave”,
ensure => present,
}

Pretty
tango {
“alpha”:
ensure => present,
mode => 600,
ref => “adam”,
prelink => “yankee”;
“delta”:
ensure => present,
mode => 644,
ref => “dave”,
prelink => “foxtrot”;
}

Unclean
package {
'gconf2': ensure => present;
}
package {
'gedit-common': ensure => present;
}
package {
'gedit-plugins':
ensure => present;
}
package {
'gettext': ensure => present;
}
package {'unixodbc':
ensure => present;
}

package {
'gedit-plugins':
ensure => present;
}
package { Unclean
'gettext': ensure => present;
}
package {'unixodbc':
ensure => present;
}
package {
'usbmount': ensure => present;
}
package {
'uswsusp': ensure => present;
}
package { 'vbetool':
ensure => present;
}
package {'vnc4server':
ensure => present;
}

Pretty
package {
'gconf2': ensure => present;
'gedit-common': ensure => present;
'gedit-plugins': ensure => present;
'gettext': ensure => present;
'unixodbc': ensure => present;
'usbmount': ensure => present;
'uswsusp': ensure => present;
'vbetool': ensure => present;
'vnc4server': ensure => present;
}

Style Guide
• Legible, easy to parse

Style Guide
• Legible, easy to parse
• Sensible chunks of code

Style Guide
• Legible, easy to parse
• Sensible chunks of code
• Develop an ordering scheme

Style Guide
• Legible, easy to parse
• Sensible chunks of code
• Develop an ordering scheme
• packages on top? files at the end?

Reusable Code

Reusable Code
• logically divide into modules

Reusable Code
• logically divide into modules
• e.g. ssh, users, apache

Reusable Code
• logically divide into modules
• e.g. ssh, users, apache
• break large modules into classes and subclasses

Reusable Code
• logically divide into modules
• e.g. ssh, users, apache
• break large modules into classes and subclasses
• use defined types

Reusable Code
• logically divide into modules
• e.g. ssh, users, apache
• break large modules into classes and subclasses
• use defined types
• something reusable with variables

Reusable Code
• logically divide into modules
• e.g. ssh, users, apache
• break large modules into classes and subclasses
• use defined types
• something reusable with variables
• use templates when possible

Reusable Code
• logically divide into modules
• e.g. ssh, users, apache
• break large modules into classes and subclasses
• use defined types
• something reusable with variables
• use templates when possible
• use subclasses

Reusable Code
• logically divide into modules
• e.g. ssh, users, apache
• break large modules into classes and subclasses
• use defined types
• something reusable with variables
• use templates when possible
• use subclasses
• subclasses do overrides

Well-Named

Well-Named
• name classes and defined types well

Well-Named
• name classes and defined types well
• useful when browsing a catalogue

Well-Named
• name classes and defined types well
• useful when browsing a catalogue
• tell from name alone the expected behavior

Well-Named
• name classes and defined types well
• useful when browsing a catalogue
• tell from name alone the expected behavior
• ldap

Well-Named
• name classes and defined types well
• useful when browsing a catalogue
• tell from name alone the expected behavior
• ldap
• ldap::master

Well-Named
• name classes and defined types well
• useful when browsing a catalogue
• tell from name alone the expected behavior
• ldap
• ldap::master
• ldap::replica

Packages vs. Puppet

Packages vs. Puppet
• Puppet for configurations

Packages vs. Puppet
• Puppet for configurations
• Package anything compiled

Packages vs. Puppet
• Puppet for configurations
• Package anything compiled
• Packages to stage changes

Packages vs. Puppet
• Puppet for configurations
• Package anything compiled
• Packages to stage changes
• e.g. version, beta, release candidates

Packages vs. Puppet
• Puppet for configurations
• Package anything compiled
• Packages to stage changes
• e.g. version, beta, release candidates
• Packages handle dependencies much better

Packages vs. Puppet
• Puppet for configurations
• Package anything compiled
• Packages to stage changes
• e.g. version, beta, release candidates
• Packages handle dependencies much better
• consider meta packages

Team Practices

Team Practices
• Never make local changes

Team Practices
• Never make local changes
• prevent reboot mysteries and rebuild
inconsistencies

Team Practices
• Never make local changes
• prevent reboot mysteries and rebuild
inconsistencies
• “I’ll go put it in Puppet later” -- later never
comes

Team Practices
• Never make local changes
• prevent reboot mysteries and rebuild
inconsistencies
• “I’ll go put it in Puppet later” -- later never
comes
• let Puppet revert changes made locally

Team Practices
• Lock puppet infrequently

Team Practices
• Lock puppet infrequently
• lock mechanism should track who and why

Team Practices
• Lock puppet infrequently
• lock mechanism should track who and why
• enforce a max time for leaving puppet locked
or disabled

Team Practices
• Lock puppet infrequently
• lock mechanism should track who and why
• enforce a max time for leaving puppet locked
or disabled
• watch for locked puppet clients

Server Practices

Server Practices
• Apache Passenger

Server Practices
• Apache Passenger
• solves memory leak issue

Server Practices
• Apache Passenger
• solves memory leak issue
• scale easily

Server Practices
• Apache Passenger
• solves memory leak issue
• scale easily
• Use version control

Server Practices
• Apache Passenger
• solves memory leak issue
• scale easily
• Use version control
• precommit syntax checks

Server Practices
• Apache Passenger
• solves memory leak issue
• scale easily
• Use version control
• precommit syntax checks
• use Git (it is truly better)

Server Practices

Server Practices
• Pick a security model

Server Practices
• Pick a security model
• who can run Puppet?

Server Practices
• Pick a security model
• who can run Puppet?
• who can commit?

Server Practices
• Pick a security model
• who can run Puppet?
• who can commit?
• certificate

Server Practices
• Pick a security model
• who can run Puppet?
• who can commit?
• certificate
• auto sign?

Server Practices
• Pick a security model
• who can run Puppet?
• who can commit?
• certificate
• auto sign?
• how do you revoke?

Server Practices
• Pick a security model
• who can run Puppet?
• who can commit?
• certificate
• auto sign?
• how do you revoke?
• puppet.domain.com?

Server Practices
• Custom Reports

Server Practices
• Custom Reports
• last check report

Server Practices
• Custom Reports
• last check report
• tangled report

ITIL

ITIL
• Why ITIL?

ITIL
• Why ITIL?
• Because your boss has heard of it

ITIL
• Why ITIL?
• Because your boss has heard of it
• It can be a good thing

ITIL
• Environments

ITIL
• Environments
• Change Management

ITIL
• Environments
• Change Management
• (little divergence between stable and dev)

ITIL
• CMDB

ITIL
• CMDB
• Stored Configs

ITIL
• CMDB
• Stored Configs
• use asynchronous stored-configs

ITIL
• CMDB
• Stored Configs
• use asynchronous stored-configs
• CMDBf

ITIL
• CMDB
• Stored Configs
• use asynchronous stored-configs
• CMDBf
• Custom data types using defined types

Management

Management
• Give management visibility

Management
• Give management visibility
• Send them the reports

Management
• Give management visibility
• Send them the reports
• Puppet Dashboard

Management
• Give management visibility
• Send them the reports
• Puppet Dashboard
• Malkovich

Work Together

Work Together
• Think “Puppet”

Work Together
• Think “Puppet”
• Adopt a style guide

Work Together
• Think “Puppet”
• Adopt a style guide
• Keep it in Puppet

Work Together
• Think “Puppet”
• Adopt a style guide
• Keep it in Puppet
• Watch your logs and reports

?
digant@stanford.edu