Ge#ng  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  [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  Classifier  •  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  define  “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  

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  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  POC’s.  

@byron_miller   16  

Module  Development  

@byron_miller   17  

Be  Pragma[c  

@byron_miller   18  

Style  

•  Make  quality  a  requirement  •  Know  when  to  stop  (don’t  over  op[mize)    

DRY  –  Don’t  repeat  yourself  

•  Imposed  Duplica/on  –  Apparent  lack  of  choice  

•  Inadvertent  Duplica/on  –  Not  realize  that  they’re  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  it’s  easier  to  find  and  reuse  exis[ng  stuff  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  effects  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  /  defini[on  •  Is  coupling  minimized?  •  Can  you  iden[fy  poten[al  sources  of  duplica[on?  

 

Style  Guides  

•  heps://docs.puppetlabs.com/guides/style_guide.html  

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

heps://github.com/garethr/puppet-­‐module-­‐skeleton  

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  don’t  support  platorm  – Default  case  fail  on  unsupported  platorms  

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

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

It’s  code  but…  

•  Don’t  think  of  it  as  “object  oriented”  from  a  programmers  perspec[ve  

•  It’s  a  “Domain  Specific  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  –  effect”  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  conflict?  

•  Understanding  &  Conveying  meaning  of  a  system  

•  People..    

@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,  don’t  have  server  rot  

 CI  •  Puppet  Lint  •  Beaker/Rspec/ServerSpec  •  Rubocop  

@byron_miller   56  

Keep  it  simple  

•  Decouple!  – Use  Roles  &  Profiles  (the  one  “paeern”  I’ll  always  recommend)  

– Hiera  is  your  friend,  but  don’t  go  too  nuts  – Keep  your  ENC  simple  -­‐  categoriza[on  

@byron_miller   57  

Use  the  feedback  loops  

•  Pay  aeen[on  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  op[mums  •  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  

Prac[ce  

•  Test  Upgrades  •  Test  new  forge  modules  •  “Safe  to  fail”  experimenta[on  •  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  •  Twieer  •  “Ask”  puppetlabs  •  Online  Documenta[on  •  IRC    •  User  Groups!!  •  Sh*t  Gary  Says  -­‐  hep://garylarizza.com/    

@byron_miller   63  

Ques[ons?  

 

“Organiza)ons  which  design  systems…  are  constrained  to  produce  designs  which  are  copies  of  the  communica)on  structures  of  these  organiza)ons.”  

               -­‐  M.  Conway  

 @byron_miller   64