Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Ten years of [Puppet] installations. What now?


Published on

Lessons learned, sane suggestions, outlook for the future.
A presentation that outlines the kind of challenges that faces whoever has to automate the configuration and the management of an IT infrastructure.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Ten years of [Puppet] installations. What now?

  1. 1. Ten years of [Puppet] installations. What now? Lessons learned, sane suggestions, outlook for the future.
  2. 2. Who am I?
 Alessandro Franceschi More Op than Dev for more than 20 years Puppet consultant for more than 10 years CTO example42 Gmbh Author of puppi, tp, psick … @alvagante
  3. 3. Who are We? We are expected to be who works or is interested in IT automation In particular, “classic” Configuration Management tools like [Puppet|Ansible|Chef| Salt|Cfengine..] and their future in a in container world
  4. 4. Infrastructure as code Code and data that configure the status of out infrastructure (servers’ configurations, network, storage, cloud resources…) Is typically versioned and centralised Change to the code implies changes to our infrastructure Code has to be written, tested, deployed, applied
  5. 5. Pains
  6. 6. Common failures When dealing with variables values When classifying nodes (what goes where) When shipping wrong code or data Files changing in the wrong way Things happening where they shouldn’t Things keep on happening
  7. 7. [Big] failures They happen Sometimes from small errors Often due to lack of knowledge [Appropriate] Tests would have avoided them Wide spread failures CAN be mitigated
  8. 8. Limit impact Understand the extent and the potential risk of every change (quantity and quality of affected resources) [noop] manage critical nodes Controlled rollouts that stop at early warnings Have a red button
  9. 9. Projects
  10. 10. Greenfield implementations Start with the easier, faster, simpler, most useful First manage systems baselines Then the most common applications Prioritise according to effort/benefit [Don’t] automate, what you do once
  11. 11. Infrastructure code design Seek experts’ advice Design for future exception (if cheap) Divide et Impera (Single Point of Responsibility) Easy to read, easy to use Avoid or limit coupling Document, at least the essential
  12. 12. Brownfield migrations (from * to managed and automated) First automate new deployments Prioritise what takes more global time Consider replacement alternative Migration is on 2 axes:
 systems migrated , applications managed Grab the 80s in the 80/20 rule Don’t migrate what is going to die
  13. 13. Automating applications Involve domain users and experts Define together change mode and process Design for ease of use and expandability Understand where to place sane defaults Understand conditions for different data
  14. 14. Infrastructure code upgrades A [module|class|component] at a time Test (at least the most common conditions) Refactoring is always an option If it works, without compromises, keep it This is where unit tests make the difference
  15. 15. Day by day
  16. 16. [yaml] operations Change requests mostly involve modifying infrastructure code and data Ideally only data Once it’s data is easier to delegate to the same requesters Pick ticket, write, test, deploy, apply, check 
 (automate as much as possible)
  17. 17. Test Changes “I like tests. I just don’t like to write them” Do single simple useful tests on what matters Then connect, integrate and automate Start from the basics, the commons, the sensible Test different conditions (os, role, env, dc…) [x2] peer review changes on what’s critical
  18. 18. People and tools
  19. 19. Tool is not the issue Start with what looks most fitting The sage, when ignorant, 
 asks for advice and learns Implementation makes the difference Integrations of overlapping tools are common
  20. 20. Share knowledge The better we know the tool,
 more we do with it Make people familiar with the tool Share the right info for the right audience Gather feedbacks, design with user in mind
  21. 21. Classic Tools are mature [Puppet|Ansible|Chef|Salt|Cfengine..] They solved real problems of the past They handle [old|new] technologies [They] evolved to fix their weaknesses [They] feature: provisioning, cfgmgmt, orchestration
  22. 22. Future
  23. 23. Future is present [Tools] manage current IT infrastructures [Tools] manage newest IT technologies IT of today will still be used in [10] years Tools with evolve, and us with them
  24. 24. For sure in the future We will have to manage more and more
 [cloud|Hardware|VM|container|device|thing] Someone or something have to do it Automation is unavoidable We are here for that
  25. 25. a last tip It applies to all the previous
  26. 26. Ask always the usual questions WHAT WHY WHO WHERE WHEN HOW Share the answers