Puppet Camp Austin 2015: Getting Started with Puppet

Download Puppet Camp Austin 2015: Getting Started with Puppet

Post on 14-Jul-2015




2 download

Embed Size (px)


  • Ge#ng Started with Puppet

    @byron_miller 1

  • @Byron_Miller

    @byron_miller 2


    @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 [me Idempotent unchanged element when operated on by itself

    Orchestra[on Coordina[on & Management of complex systems

    Puppet The ecosystem Manifests & Modules The code

    @byron_miller 6

  • More Vocabulary

    ENC External Node Classier Mcollec[ve orchestra[on 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 organiza[on is up to how you dene ge#ng things done and your future

    The vocabulary and Verbiage of puppet is well documented & simple with a liele prac[ce

    Think about your work Think about your future

    @byron_miller 9

  • Puppet docs

    The Docs heps://docs.puppetlabs.com/ Types & Providers heps://docs.puppetlabs.com/references/stable/type.html

    @byron_miller 10

  • Ge#ng 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 organiza[on highly constrained & highly ordered?

    Do you strive for self-regula[ng systems?

    Is your goal compliance? Stability? Agility?

    @byron_miller 12

  • Dene Workow

    Simple Easy to install & Maintain

    Safe Version Control - Git workow

    Secure SSH / SSL / Accountability

    Scalable Handle 1000s of nodes

    @byron_miller 13

  • Modules

    Everyones a developer

    Style Guide


    @byron_miller 14

  • Long term..

    Simple Dont add complexity Safe Safe to fail experimenta[on Secure Auditable Scalable Point in [me convergence.

    @byron_miller 15

  • Prac[ce

    Track your theories Test your theories Experiment Experiment again

    Never underes[mate the value of POCs.

    @byron_miller 16

  • Module Development

    @byron_miller 17

  • Be Pragma[c

    @byron_miller 18

  • Style

    Make quality a requirement Know when to stop (dont over op[mize)

  • DRY Dont repeat yourself

    Imposed Duplica/on Apparent lack of choice

    Inadvertent Duplica/on Not realize that theyre duplica[ng informa[on

    Impa/ent Duplica[on lazy / duplicate because it seems easier

    Interdeveloper Duplica/on Mul[ple people on teams / mul[ple teams.

  • Code

    Keep low level knowledge in code Reserve Comments for high level expecta[ons

    Foster an environment where its easier to nd and reuse exis[ng stu than to write it yourself.

  • Scope & Avoid Global data

    Every [me you reference global data it [es 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 mul[ple ways.

  • Orthogonal - Safe to Fail

    Independent / lightly coupled systems Eliminates eects of unrelated things Design self contained things

    Increased produc[vity & contained risk

  • Prototype (experiment)

    Architecture New func[onality in exis[ng 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 / deni[on Is coupling minimized? Can you iden[fy poten[al sources of duplica[on?

  • Style Guides


  • Test

    Loosely coupled systems easier to test interac[ons between components are limited. Unit tes[ng is easier Test in CI pipeline

    Beaker / rspec / puppet lint

  • Refactor

    Avoid code rot. Dont 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 platorm for new shiny thing..

  • Its code

    Version control Test Refactor Share. forge

  • Module Template

    puppet module generate use the boiler plate scaolding

    Use Garethrs boiler plate nice & updated


  • Data Separa[on

    Hiera Yaml, Mysql, GPG etc..

    ENC Puppet PE Foreman Homemade ?

    Single source of truth.. Anyone have any? J

  • Parameterized Classes

    Great for ENCs Easy to set default values Portable / Shareable Just do it..

  • Class Inheritance

    Use within a module to reduce repe[[on (DRY)

    Inheri[ng 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 dont support platorm Default case fail on unsupported platorms

    Plan for Puppet Future parser Some changes / restric[ons Expressions, Lambdas, Itera[ons & more


  • Its code but

    Dont think of it as object oriented from a programmers perspec[ve

    Its a Domain Specic Language (DSL) used to describe a desired state.

    @byron_miller 36

  • Prac[ce

    Vagrant / VM instances Build / test / deploy Pull modules from forge

    Read Test Deploy experiment

    @byron_miller 37

  • Opera[ons

    @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 eect rela[onships 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.. Bus[ng out some Deming.. As a System of profound knowledge

    A. Apprecia[on for a system B. Theory of Varia[on C. Theory of Knowledge D. Psychology

    @byron_miller 44

  • Systems Approach

    Taking a systems approach results in viewing the organiza[on in terms of many internal and external interrelated connec[ons and interac[ons as opposed to discrete and independent departments or processes governed by various chains of command. Apprecia[on for a system..

    @byron_miller 45

  • Varia[on

    Why did something go wrong? How can we repeat success? Common Cause predictable varia[on within a system Special Cause unique event outside the system

    @byron_miller 46

  • Knowledge

    Theory, Experimenta[on, Sta[s[cal analysis, conveyed meaning, processes.

    Informa)on is not knowledge -Deming

    @byron_miller 47

  • Psychology

    Human Systems Drive out Fear Mo[va[on

    @byron_miller 48

  • Management Is..

    Predic[on Theory What causes posi[ve interac[ons? What removes conict?

    Understanding & Conveying meaning of a system


    @byron_miller 49

  • Think of ecology

    Adopt an ecological metaphor Codify stories Feedback loops Itera[ons Tes[ng Repor[ng

    @byron_miller 50

  • The system

    Intent.. What causes behaviors outside the system?

    The obliga[on 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: Perspec[ves of people within an organiza[on give them a limited view of the present, and such entrained paeerns of past percep[on can determine its future.

    @byron_miller 53

  • Your future Ge#ng there.. Flow Measure Retrospec[ves Involve Stakeholders Sense -> Categorize -> Respond

    Bias against crea)vity is fueled by uncertainty -Deming

    @byron_miller 54

  • Puppet Opera[ons

    Develop your System to allow experimenta[on, upkeep, maintenance and opera[onal agility.

    Keep it Simple Grow & Learn Prac[ce all the [me Prac[ce More

    @byron_miller 55

  • Ops Pipeline

    Build Build Build Just like code rot, dont have server rot

    CI Puppet Lint Beaker/Rspec/ServerSpec Rubocop

    @byron_miller 56

  • Keep it simple

    Decouple! Use Roles & Proles (the one paeern Ill always recommend)

    Hiera is your friend, but dont go too nuts Keep your ENC simple - categoriza[on

    @byron_miller 57

  • Use the feedback loops