SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.
SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.
Successfully reported this slideshow.
Activate your 14 day free trial to unlock unlimited reading.
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
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
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
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
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
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)
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?