Philosophy of getting things done with puppet

1. Getting Started with Puppet
@byron_miller 1

2. @Byron_Miller
@byron_miller 2

3. #ATXPUG
@byron_miller 3

4. Meetup! 2nd Tuesday
@byron_miller 4

5. How I got Started
• Oracle *.*
• Enterprise Linux
• Needed a way to not waste every Monday and
every day I needed to refresh/clone
• Kill technical debt
• “Classic Enterprise..”
@byron_miller 5

6. Vocabulary
• Convergence – stabilize over time
• Idempotent – unchanged element when
operated on by itself
• Orchestration – Coordination & Management
of complex systems
• Puppet – The ecosystem
• Manifests & Modules – The code
@byron_miller 6

7. More Vocabulary
• ENC – External Node Classifier
• Mcollective – orchestration tool set
• Hiera – key value lookup system
• Node – Server/VM
• Facter – node facts
• Types & Providers – Built in resources you
declare in puppet manifests
@byron_miller 7

8. Theory (is where it starts)
@byron_miller 8

9. Begin by thinking
• Puppet has a learning curve but making it
work for your organization is up to how you
define “getting things done” and your future
• The “vocabulary” and “Verbiage” of puppet is
well documented & simple with a little
practice
• Think about your work
• Think about your future
@byron_miller 9

10. Puppet docs
• The Docs
https://docs.puppetlabs.com/
• Types & Providers
https://docs.puppetlabs.com/references/stable/
type.html
@byron_miller 10

11. Getting Started – Set Goals
• What is your goal(s)?
• How do you measure success or failure?
• What is your Intent?
Know the theory of your desired state
@byron_miller 11

12. How do you work?
• Is your organization highly constrained &
highly ordered?
• Do you strive for self-regulating systems?
• Is your goal compliance?
• Stability?
• Agility?
@byron_miller 12

13. Define Workflow
• Simple
– Easy to install & Maintain
• Safe
– Version Control - “Git workflow”
• Secure
– SSH / SSL / Accountability
• Scalable
– Handle 1000s of nodes
@byron_miller 13

14. Modules
• Everyone’s a developer
• Style Guide
• Testable
@byron_miller 14

15. Long term..
• Simple – Don’t add complexity
• Safe – Safe to fail experimentation
• Secure – Auditable
• Scalable – Point in time convergence.
@byron_miller 15

16. Practice
• Track your theories
• Test your theories
• Experiment
• Experiment again
• Never underestimate the value of POC’s.
@byron_miller 16

17. Module Development
@byron_miller 17

18. Be Pragmatic
@byron_miller 18

19. Style
• Make quality a requirement
• Know when to stop (don’t over optimize)

20. 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.

21. 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.

22. Scope & Avoid Global data
• Every time you reference global data it ties
you to the other components that share data
• Use Scoping

23. Manage Complexity
Complexity is generally used to characterize
something with many parts where those parts
interact with each other in multiple ways.

24. Orthogonal - Safe to Fail
• Independent / lightly coupled systems
– Eliminates effects of unrelated things
– Design self contained things
• Increased productivity & contained risk

25. 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

26. Experiments
• Worry less about correctness, completeness,
robustness and style.
• Focus on design / definition
• Is coupling minimized?
• Can you identify potential sources of
duplication?

27. Style Guides
• https://docs.puppetlabs.com/guides/style_gui
de.html

28. Test
• Loosely coupled systems easier to test –
interactions between components are limited.
– Unit testing is easier
– Test in CI pipeline
• Beaker / rspec / puppet lint

29. Refactor
• Avoid code rot. Don’t let bad code fester and
turn all your code into abandonware
• Code rot will keep you from staying current,
maintaining your skills and generally cause
people to shy away from platform for new
shiny thing..

30. It’s code
• Version control
• Test
• Refactor
• Share.
• forge

31. Module Template
• “puppet module generate” – use the boiler
plate scaffolding
• Use Garethr’s boiler plate – nice & updated
https://github.com/garethr/puppet-module-
skeleton

32. Data Separation
• Hiera
– Yaml, Mysql, GPG etc..
• ENC
– Puppet PE
– Foreman
– Homemade
– ?
• Single source of truth.. Anyone have any? 

33. Parameterized Classes
• Great for ENCs
• Easy to set default values
• Portable / Shareable
• Just do it..

34. Class Inheritance
• Use within a module to reduce repetition
(DRY)
• Inheriting from other modules decreases
modularity, but hard to avoid
– ENC confusion

35. Code Defensively
• Catch unexpected events before they break
things – gracefully bow out if you don’t support
platform
– Default case fail on unsupported platforms
• Plan for Puppet Future parser
– Some changes / restrictions
– Expressions, Lambdas, Iterations & more
https://docs.puppetlabs.com/puppet/latest/refere
nce/experiments_future.html

36. It’s code but…
• Don’t think of it as “object oriented” from a
programmers perspective
• It’s a “Domain Specific Language” (DSL) used
to describe a desired state.
@byron_miller 36

37. Practice
• Vagrant / VM instances
– Build / test / deploy
– Pull modules from forge
• Read
• Test
• Deploy
• experiment
@byron_miller 37

38. Operations
@byron_miller 38

39. More Thinking
• How do we work?
• What should we automate?
• What are our goals?
• Systems thinking..
• Sense Making..
@byron_miller 39

40. Sense Making
@byron_miller 40

41. Simple Domain
• Start with what you know
• Relieve pain points
• Remove constraints
• “Cause – effect” relationships – you can codify
this
@byron_miller 41

42. Chaos
@byron_miller 42

43. Simple -> Chaos
• When simple breaks
– All hell breaks loose.
@byron_miller 43

44. Infrastructure
• as code..
Busting out some Deming..
“As a System of profound knowledge”
A. Appreciation for a system
B. Theory of Variation
C. Theory of Knowledge
D. Psychology
@byron_miller 44

45. Systems Approach
Taking a systems approach results in viewing the
organization in terms of many internal and
external interrelated connections and
interactions as opposed to discrete and
independent departments or processes
governed by various chains of command.
Appreciation for a system..
@byron_miller 45

46. Variation
Why did something go wrong? How can we
repeat success?
Common Cause – predictable variation within a
system
Special Cause – unique event outside the system
@byron_miller 46

47. Knowledge
• Theory, Experimentation, Statistical analysis,
conveyed meaning, processes.
“Information is not knowledge”
-Deming
@byron_miller 47

48. Psychology
• Human Systems
• Drive out Fear
• Motivation
@byron_miller 48

49. Management Is..
• Prediction
• Theory
– What causes positive interactions?
– What removes conflict?
• Understanding & Conveying meaning of a
system
• People..
@byron_miller 49

50. Think of ecology
• Adopt an ecological metaphor
• Codify stories
– Feedback loops
– Iterations
– Testing
– Reporting
@byron_miller 50

51. The system
Intent..
• What causes behaviors outside the system?
“The obligation of any component is to
contribute its best to the system but it will not
do that unless the system is managed”
@byron_miller 51

52. Future Backwards
@byron_miller 52

53. Where we want to be
Future Backwards: Perspectives of people
within an organization give them a limited view
of the present, and such entrained patterns of
past perception can determine its future.
@byron_miller 53

54. Your future
Getting there..
• Flow
• Measure
• Retrospectives
• Involve Stakeholders
• Sense -> Categorize -> Respond
“Bias against creativity is fueled by uncertainty”
-Deming
@byron_miller 54

55. Puppet Operations
• Develop your “System” to allow
experimentation, upkeep, maintenance and
operational agility.
• Keep it Simple
• Grow & Learn
• Practice all the time
• Practice More
@byron_miller 55

56. Ops Pipeline
• Build Build Build
– Just like code rot, don’t have server rot
CI
• Puppet Lint
• Beaker/Rspec/ServerSpec
• Rubocop
@byron_miller 56

57. Keep it simple
• Decouple!
– Use Roles & Profiles (the one “pattern” I’ll always
recommend)
– Hiera is your friend, but don’t go too nuts
– Keep your ENC simple - categorization
@byron_miller 57

58. Use the feedback loops
• Pay attention to pipeline
– Don’t let things rot
– Seek out improvements
– Share lessons learned
– Get feedback
• Puppet Reports..
• Puppet Dashboard..
• Event Inspector (PE).. (and other tools)
@byron_miller 58

59. Don’t stop Thinking
• Maintain a consistency of understanding and
effort
• Don’t focus on local optimums
• Quality starts here
• Quality starts with intent
• No system whatever the effort put in will be
free from accident/incident/error
@byron_miller 59

60. Enable People
• Puppet enables me to codify to “my future”
• Puppet enables me to know my past
@byron_miller 60

61. Practice
• Test Upgrades
• Test new forge modules
• “Safe to fail” experimentation
• Serverspec.. Beaker..
@byron_miller 61

62. Keep trying
• Look at logs
• puppet --debug –verbose
• Talk to community
• Use the dashboard
• puppet --help
@byron_miller 62

63. Community
• Google Groups
• Twitter
• “Ask” puppetlabs
• Online Documentation
• IRC
• User Groups!!
• Sh*t Gary Says - http://garylarizza.com/
@byron_miller 63

64. Questions?
“Organizations which design systems… are constrained to
produce designs which are copies of the communication
structures of these organizations.”
- M. Conway
@byron_miller 64