PuppetCamp Austin 2015 Talk - Getting started with puppet
Download as pptx, pdf1 like524 views
This document provides an overview of getting started with Puppet, including establishing goals, understanding key concepts and vocabulary, developing modules, and practicing an operations workflow. It emphasizes taking a systems thinking approach, focusing on simplicity, experimentation, and continuous improvement through testing, monitoring, and seeking feedback to refine processes over time.
PuppetCamp Austin 2015 Talk - Getting started with puppet
- 1. Getting Started with Puppet @byron_miller 1
- 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 Everyones a developer Style Guide Testable @byron_miller 14
- 15. Long term.. Simple Dont 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 POCs. @byron_miller 16
- 19. Style Make quality a requirement Know when to stop (dont over optimize)
- 20. DRY Dont repeat yourself Imposed Duplication Apparent lack of choice Inadvertent Duplication Not realize that theyre 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 its 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?
- 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. 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 platform for new shiny thing..
- 30. Its code Version control Test Refactor Share. forge
- 31. Module Template puppet module generate use the boiler plate scaffolding Use Garethrs 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 dont 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. Its code but Dont think of it as object oriented from a programmers perspective Its 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
- 39. More Thinking How do we work? What should we automate? What are our goals? Systems thinking.. Sense Making.. @byron_miller 39
- 41. Simple Domain Start with what you know Relieve pain points Remove constraints Cause effect relationships you can codify this @byron_miller 41
- 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
- 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, dont have server rot CI Puppet Lint Beaker/Rspec/ServerSpec Rubocop @byron_miller 56
- 57. Keep it simple Decouple! Use Roles & Profiles (the one pattern Ill always recommend) Hiera is your friend, but dont go too nuts Keep your ENC simple - categorization @byron_miller 57
- 58. Use the feedback loops Pay attention to pipeline Dont 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. Dont stop Thinking Maintain a consistency of understanding and effort Dont 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
Editor's Notes
- #9: Theory gives us the philosophical rails we need to have a successful implementation. It helps us think through what matters to the teams, the business and the operations of the systems that puppet is managing.
- #10: Puppet has a learning curve, but it is fairly simple
- #12: Is your goal to automate specific tasks, scale growth? Build out hundreds or thousands of servers? What are your success criteria's? How do you define your intent and how to establish that? I like to create a story in a wiki to describe the state of the system myself.
- #13: Organization type will help you know your boundaries and deliverables. If you have a highly ordered/constrained work environment you may focus more on controls in your pipeline, how you audit changes and restrict who has access to one. If you have a self-regulated system a Pull Request github style If no one has a firm grasp of puppet you may constrain your own system as you gain experience.
- #14: Workflow philosophy
- #15: Module Philosophy.. - everyone is a developer, everyone should adhere to style guide and everything should be testable and tested.
- #16: Start simple, but plan for long term goals have them in back of your mind. Dont add complexity for sake of complexity. For some people as they grow scalability is less of an issue and long term your goals may be point in time convergence. Not every node needing to check in every x minutes, but orchestrated puppet runs satisfying business needs.
- #17: I would never under estimate the value of a proof of concept and experimenting with your theories in fact, Id wager many of us have gone awry or had regrets because our initial design is what became production
- #20: Your entire success lies in making quality a requirement. If you have bad code, you will have a bad time. If no one can read it, understand it, embrace it, use it or it just doesnt work your entire ecosystem will reflect this. On the flipside I wouldnt look at the puppet DSC in the light of say a pythonista or rubyist looking for the most elegant way to do something in least amount of code. Puppet DSC should be readable and simple
- #24: Decouple!
- #31: Worth repeating. Puppet manifests are code, treat it as such.
- #41: Kin-ev-in cynafin many places
- #47: Common cause can address with experimentation and puppet Special Cause
- #50: What does it mean to be in operations? Managing what?
- #53: Helps give an overview of the hopes and fears of their organization and helps them understand which entrained patterns of past perception are influencing its future.
- #54: The ecology of getting work done has more impact on delivering your future than the tech/tools themselves. ASHEN methodology
- #60: Were not striving for perfection, I choose to strive for getting the most work done with least resistance and most consistency.
- #61: Puppet enables me to operate in Complex and Complicated domains to seek out innovation & emergent properties of system