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

2.
A Little History...

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

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

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

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

7.
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

8.
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

9.
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

10.
Agenda

11.
Agenda
• Coding Practices

12.
Agenda
• Coding Practices
• Packages vs. Puppet

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

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

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

16.
Coding Practices

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

18.
Style Guide

19.
Style Guide
• Legible, easy to parse

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

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

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

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

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

25.
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;
}

26.
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;
}

27.
Style Guide
• Legible, easy to parse

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

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

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

31.
Reusable Code

32.
Reusable Code
• logically divide into modules

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

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

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

36.
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

37.
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

38.
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

39.
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

40.
Well-Named

41.
Well-Named
• name classes and defined types well

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

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

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

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

46.
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

47.
Packages vs. Puppet

48.
Packages vs. Puppet
• Puppet for configurations

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

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

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

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

53.
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

54.
Team Practices

55.
Team Practices
• Never make local changes

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

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

58.
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

59.
Team Practices
• Lock puppet infrequently

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

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

62.
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

63.
Server Practices

64.
Server Practices
• Apache Passenger

65.
Server Practices
• Apache Passenger
• solves memory leak issue

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

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

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

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

70.
Server Practices

71.
Server Practices
• Pick a security model

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

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

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

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

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

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

78.
Server Practices
• Custom Reports

79.
Server Practices
• Custom Reports
• last check report

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

81.
ITIL

82.
ITIL
• Why ITIL?

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

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

85.
ITIL
• Environments

86.
ITIL
• Environments
• Change Management

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

88.
ITIL
• CMDB

89.
ITIL
• CMDB
• Stored Configs

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

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

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

93.
Management

94.
Management
• Give management visibility

95.
Management
• Give management visibility
• Send them the reports

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

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

98.
Work Together

99.
Work Together
• Think “Puppet”

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

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

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

103.
?
digant@stanford.edu