Getting Started with Puppet

@byron_miller 1

@Byron_Miller

@byron_miller 2

#ATXPUG

@byron_miller 3

Meetup! 2nd Tuesday

@byron_miller 4

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

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

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

Theory (is where it starts)

@byron_miller 8

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

Puppet docs

• The Docs

https://docs.puppetlabs.com/

• Types & Providers

https://docs.puppetlabs.com/references/stable/type.html

@byron_miller 10

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

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

Define Workflow

• Simple

– Easy to install & Maintain

• Safe

– Version Control - “Git workflow”

• Secure

– SSH / SSL / Accountability

• Scalable

– Handle 1000s of nodes

@byron_miller 13

Modules

• Everyone’s a developer

• Style Guide

• Testable

@byron_miller 14

Long term..

• Simple – Don’t add complexity

• Safe – Safe to fail experimentation

• Secure – Auditable

• Scalable – Point in time convergence.

@byron_miller 15

Practice

• Track your theories

• Test your theories

• Experiment

• Experiment again

• Never underestimate the value of POC’s.

@byron_miller 16

Module Development

@byron_miller 17

Be Pragmatic

@byron_miller 18

Style

• Make quality a requirement

• Know when to stop (don’t over optimize)

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.

Scope & Avoid Global data

• Every time you reference global data it ties you to the other components that share data

• Use Scoping

Manage Complexity

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

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

Experiments

• 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 / rspec / puppet lint

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

It’s code

• Version control

• Test

• Refactor

• Share.

• forge

Module Template

• “puppet module generate” – use the boiler plate scaffolding

• Use Garethr’s boiler plate – nice & updated

https://github.com/garethr/puppet-module-skeleton

Data Separation

• Hiera– Yaml, Mysql, GPG etc..

• ENC – Puppet PE

– Foreman

– Homemade

– ?

• Single source of truth.. Anyone have any?

Parameterized Classes

• Great for ENCs

• Easy to set default values

• Portable / Shareable

• Just do it..

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– Default case fail on unsupported platforms

• Plan for Puppet Future parser – Some changes / restrictions

– Expressions, Lambdas, Iterations & more

https://docs.puppetlabs.com/puppet/latest/reference/experiments_future.html

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

Practice

• Vagrant / VM instances

– Build / test / deploy

– Pull modules from forge

• Read

• Test

• Deploy

• experiment

@byron_miller 37

Operations

@byron_miller 38

More Thinking

• How do we work?

• What should we automate?

• What are our goals?

• Systems thinking..

• Sense Making..

@byron_miller 39

Sense Making

@byron_miller 40

Simple Domain

• Start with what you know

• Relieve pain points

• Remove constraints

• “Cause – effect” relationships – you can codify this

@byron_miller 41

Chaos

@byron_miller 42

Simple -> Chaos

• When simple breaks

– All hell breaks loose.

@byron_miller 43

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

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

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

Knowledge

• Theory, Experimentation, Statistical analysis, conveyed meaning, processes.

“Information is not knowledge”

-Deming

@byron_miller 47

Psychology

• Human Systems

• Drive out Fear

• Motivation

@byron_miller 48

Management Is..

• Prediction

• Theory

– What causes positive interactions?

– What removes conflict?

• Understanding & Conveying meaning of a system

• People..

@byron_miller 49

Think of ecology

• Adopt an ecological metaphor

• Codify stories

– Feedback loops

– Iterations

– Testing

– Reporting

@byron_miller 50

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

Future Backwards

@byron_miller 52

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

Your future

Getting there..• Flow• Measure• Retrospectives• Involve Stakeholders• Sense -> Categorize -> Respond

“Bias against creativity is fueled by uncertainty”-Deming

@byron_miller 54

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

Ops Pipeline

• Build Build Build

– Just like code rot, don’t have server rot

CI

• Puppet Lint

• Beaker/Rspec/ServerSpec

• Rubocop

@byron_miller 56

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

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

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

Enable People

• Puppet enables me to codify to “my future”

• Puppet enables me to know my past

@byron_miller 60

Practice

• Test Upgrades

• Test new forge modules

• “Safe to fail” experimentation

• Serverspec.. Beaker..

@byron_miller 61

Keep trying

• Look at logs

• puppet --debug –verbose

• Talk to community

• Use the dashboard

• puppet --help

@byron_miller 62

Community

• Google Groups

• Twitter

• “Ask” puppetlabs

• Online Documentation

• IRC

• User Groups!!

• Sh*t Gary Says - http://garylarizza.com/

@byron_miller 63

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