Digant

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