Advertisement
Advertisement

More Related Content

Advertisement
Advertisement

Puppet101

  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

Editor's Notes

  1. \n
  2. \n
  3. \n
  4. \n
  5. \n
  6. \n
  7. \n
  8. \n
  9. \n
  10. \n
  11. \n
  12. \n
  13. \n
  14. \n
  15. \n
  16. \n
  17. \n
  18. \n
  19. \n
  20. \n
  21. \n
  22. \n
  23. \n
  24. \n
  25. \n
  26. \n
  27. \n
  28. \n
  29. \n
  30. \n
  31. \n
  32. \n
  33. \n
  34. \n
  35. \n
  36. \n
  37. \n
  38. \n
  39. \n
  40. \n
  41. \n
  42. \n
  43. \n
  44. \n
  45. \n
  46. \n
  47. \n
  48. \n
  49. \n
  50. \n
  51. \n
  52. \n
  53. \n
  54. \n
  55. \n
  56. \n
  57. \n
  58. \n
  59. \n
  60. \n
  61. \n
  62. \n
  63. \n
  64. \n
  65. \n
  66. \n
  67. \n
  68. \n
  69. \n
  70. \n
  71. \n
  72. \n
  73. \n
  74. \n
  75. \n
  76. \n
  77. \n
  78. \n
  79. \n
  80. \n
  81. \n
  82. \n
  83. \n
  84. \n
  85. \n
  86. \n
  87. \n
  88. \n
  89. \n
Advertisement