Puppet101

3,749 views

Published on

Digant

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,749
On SlideShare
0
From Embeds
0
Number of Embeds
110
Actions
Shares
0
Downloads
74
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • \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
  • Puppet101

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

    ×