ATXPUG Meetup 11/11/14 - Managing complexity in Puppet Code
-
Upload
byron-miller -
Category
Technology
-
view
62 -
download
0
Transcript of ATXPUG Meetup 11/11/14 - Managing complexity in Puppet Code
Austin Puppet Users Group
(ATXPUG)
Managing Puppet Complexity
Modules & Complexity
Complexity is generally used to characterize something with many parts where those parts interact with each other in multiple ways.
Style
• Make quality a requirement
• Know when to stop (don’t over optimize)
• DRY – Don’t Repeat Yourself
DRY – Don’t repeat yourself
• Imposed Duplication – Apparent lack of choice
• Inadvertent Duplication – Not realize that they’re duplicating information
• Impatient Duplication – lazy / duplicate because it seems easier
• Interdeveloper Duplication – Multiple people on teams / multiple teams.
Code
• Keep low level knowledge in code
• Reserve Comments for high level expectations
• Foster an environment where it’s easier to find and reuse existing stuff than to write it yourself.
Avoid Global data
• Every time you reference global data it ties you to the other components that share data – frowned upon since 2.x days but still in a lot of puppet code
Orthogonal - Safe to Fail
• Independent / lightly coupled systems
– Eliminates effects of unrelated things
– Design self contained things
• Increased productivity & contained risk
Prototype (experiment)
• Architecture
• New functionality in existing systems
• Structure or contents of external data
• Third party tools or components
• Performance issues
• User interface / experience / design
Experiements
• Worry less about correctness, completeness, robustness and style.
• Focus on design / definition
• Is coupling minimized?
• Can you identify potential sources of duplication?
Style Guides
• https://docs.puppetlabs.com/guides/style_guide.html
Test
• Loosely coupled systems easier to test –interactions between components are limited.
– Unit testing is easier
– Test in CI pipeline
• Beaker / rspect / puppet lint
Refactor
• Avoid code rot. Don’t let bad code fester and turn all your code into abandonware
It’s code
• Version control
• Test
• Refactor
• Share.
• forge
Module Template
• Puppet Module Generate – use the boiler plate
• Use Garethr’s boiler plate – nice & updated
https://github.com/garethr/puppet-module-skeleton (more assumptions though)
Data Separation
• Some use hiera.. Me no like
• ENC
– Puppet PE
– Foreman
– Homebrew
– ?
• Single source of truth? How?
Parameterized Classes
• Great for ENCs
• Easy to set default values
• Portable / Shareable
Class Inheritance
• Use within a module to reduce repetition (DRY)
• Inheriting from other modules decreases modularity, but hard to avoid
– ENC confusion
Code Defensively
• Catch unexpected events before they break things – gracefully bow out if you don’t support platform
• Puppet Future parser helps –
– Line error failure reporting
– Type checking (out of stdlib)
I wish
• More modules exposed puppet resources
• Augeus (or similar) was internalized across every platform so there was an easy meta catalog instead of is osfamily = yaddy yaddyyadda
• Open source puppet had strong direction.. 3.7 PE is out.. What next for OS?
Discussions
• I’m out of slides, time for interaction