1.
Puppet @ Stanford University Digant C KasundraInformation 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.
Uncleantango { “alpha”: mode => 600, ref => “adam”, prelink => “yankee”, ensure => present,}tango { “delta”: mode => 644, prelink => “foxtrot”, ref => “dave”, ensure => present,}

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

24.
Uncleanpackage { 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.
Prettypackage { 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