Successfully reported this slideshow.

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Puppet101

  1. 1. Puppet @ Stanford University Digant C Kasundra Information Technology Services digant@stanford.edu
  2. 2. A Little History...
  3. 3. A Little History... • Consistency of configuration
  4. 4. A Little History... • Consistency of configuration • Consistency of practice
  5. 5. A Little History... • Consistency of configuration • Consistency of practice • Started on August 24th 2006, 2:10pm
  6. 6. A Little History... • Consistency of configuration • Consistency of practice • Started on August 24th 2006, 2:10pm • 73, 167 lines of puppet manifests
  7. 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. 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. 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. 10. Agenda
  11. 11. Agenda • Coding Practices
  12. 12. Agenda • Coding Practices • Packages vs. Puppet
  13. 13. Agenda • Coding Practices • Packages vs. Puppet • Team Practices
  14. 14. Agenda • Coding Practices • Packages vs. Puppet • Team Practices • Server Practices
  15. 15. Agenda • Coding Practices • Packages vs. Puppet • Team Practices • Server Practices • ITIL and other crap as management interfaces
  16. 16. Coding Practices
  17. 17. Coding Practices • Style Guide • Reusable Code and Modules • Well-named
  18. 18. Style Guide
  19. 19. Style Guide • Legible, easy to parse
  20. 20. Style Guide • Legible, easy to parse • bigger the group, uglier the code
  21. 21. Style Guide • Legible, easy to parse • bigger the group, uglier the code • bigger the manifest, the harder to parse
  22. 22. Unclean tango { “alpha”: mode => 600, ref => “adam”, prelink => “yankee”, ensure => present, } tango { “delta”: mode => 644, prelink => “foxtrot”, ref => “dave”, ensure => present, }
  23. 23. Pretty tango { “alpha”: ensure => present, mode => 600, ref => “adam”, prelink => “yankee”; “delta”: ensure => present, mode => 644, ref => “dave”, prelink => “foxtrot”; }
  24. 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. 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. 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. 27. Style Guide • Legible, easy to parse
  28. 28. Style Guide • Legible, easy to parse • Sensible chunks of code
  29. 29. Style Guide • Legible, easy to parse • Sensible chunks of code • Develop an ordering scheme
  30. 30. Style Guide • Legible, easy to parse • Sensible chunks of code • Develop an ordering scheme • packages on top? files at the end?
  31. 31. Reusable Code
  32. 32. Reusable Code • logically divide into modules
  33. 33. Reusable Code • logically divide into modules • e.g. ssh, users, apache
  34. 34. Reusable Code • logically divide into modules • e.g. ssh, users, apache • break large modules into classes and subclasses
  35. 35. Reusable Code • logically divide into modules • e.g. ssh, users, apache • break large modules into classes and subclasses • use defined types
  36. 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. 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. 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. 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. 40. Well-Named
  41. 41. Well-Named • name classes and defined types well
  42. 42. Well-Named • name classes and defined types well • useful when browsing a catalogue
  43. 43. Well-Named • name classes and defined types well • useful when browsing a catalogue • tell from name alone the expected behavior
  44. 44. Well-Named • name classes and defined types well • useful when browsing a catalogue • tell from name alone the expected behavior • ldap
  45. 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. 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. 47. Packages vs. Puppet
  48. 48. Packages vs. Puppet • Puppet for configurations
  49. 49. Packages vs. Puppet • Puppet for configurations • Package anything compiled
  50. 50. Packages vs. Puppet • Puppet for configurations • Package anything compiled • Packages to stage changes
  51. 51. Packages vs. Puppet • Puppet for configurations • Package anything compiled • Packages to stage changes • e.g. version, beta, release candidates
  52. 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. 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. 54. Team Practices
  55. 55. Team Practices • Never make local changes
  56. 56. Team Practices • Never make local changes • prevent reboot mysteries and rebuild inconsistencies
  57. 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. 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. 59. Team Practices • Lock puppet infrequently
  60. 60. Team Practices • Lock puppet infrequently • lock mechanism should track who and why
  61. 61. Team Practices • Lock puppet infrequently • lock mechanism should track who and why • enforce a max time for leaving puppet locked or disabled
  62. 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. 63. Server Practices
  64. 64. Server Practices • Apache Passenger
  65. 65. Server Practices • Apache Passenger • solves memory leak issue
  66. 66. Server Practices • Apache Passenger • solves memory leak issue • scale easily
  67. 67. Server Practices • Apache Passenger • solves memory leak issue • scale easily • Use version control
  68. 68. Server Practices • Apache Passenger • solves memory leak issue • scale easily • Use version control • precommit syntax checks
  69. 69. Server Practices • Apache Passenger • solves memory leak issue • scale easily • Use version control • precommit syntax checks • use Git (it is truly better)
  70. 70. Server Practices
  71. 71. Server Practices • Pick a security model
  72. 72. Server Practices • Pick a security model • who can run Puppet?
  73. 73. Server Practices • Pick a security model • who can run Puppet? • who can commit?
  74. 74. Server Practices • Pick a security model • who can run Puppet? • who can commit? • certificate
  75. 75. Server Practices • Pick a security model • who can run Puppet? • who can commit? • certificate • auto sign?
  76. 76. Server Practices • Pick a security model • who can run Puppet? • who can commit? • certificate • auto sign? • how do you revoke?
  77. 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. 78. Server Practices • Custom Reports
  79. 79. Server Practices • Custom Reports • last check report
  80. 80. Server Practices • Custom Reports • last check report • tangled report
  81. 81. ITIL
  82. 82. ITIL • Why ITIL?
  83. 83. ITIL • Why ITIL? • Because your boss has heard of it
  84. 84. ITIL • Why ITIL? • Because your boss has heard of it • It can be a good thing
  85. 85. ITIL • Environments
  86. 86. ITIL • Environments • Change Management
  87. 87. ITIL • Environments • Change Management • (little divergence between stable and dev)
  88. 88. ITIL • CMDB
  89. 89. ITIL • CMDB • Stored Configs
  90. 90. ITIL • CMDB • Stored Configs • use asynchronous stored-configs
  91. 91. ITIL • CMDB • Stored Configs • use asynchronous stored-configs • CMDBf
  92. 92. ITIL • CMDB • Stored Configs • use asynchronous stored-configs • CMDBf • Custom data types using defined types
  93. 93. Management
  94. 94. Management • Give management visibility
  95. 95. Management • Give management visibility • Send them the reports
  96. 96. Management • Give management visibility • Send them the reports • Puppet Dashboard
  97. 97. Management • Give management visibility • Send them the reports • Puppet Dashboard • Malkovich
  98. 98. Work Together
  99. 99. Work Together • Think “Puppet”
  100. 100. Work Together • Think “Puppet” • Adopt a style guide
  101. 101. Work Together • Think “Puppet” • Adopt a style guide • Keep it in Puppet
  102. 102. Work Together • Think “Puppet” • Adopt a style guide • Keep it in Puppet • Watch your logs and reports
  103. 103. ? digant@stanford.edu

Editor's Notes

  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • ×