Implementing Infrastructure as Code ConfigMgtCamp 2017
•
13 likes•1,512 views
Run-through of key patterns and approaches for applying software engineering practices and microservice design to infrastructure. Infrastructure as Code is the "A" (Automation) in the "CAMS" model for DevOps.
Report
Share
Implementing Infrastructure as Code ConfigMgtCamp 2017
- 2. kief@thoughtworks.com Cloud Practice Lead (UK) DevOps, Continuous Delivery, Agile Ops Twitter: @kief Book: http://oreil.ly/1JKIBVe Site: http://infrastructure-as-code.com February 2017
- 3. SPEED
- 4. RISK
- 7. INFRASTRUCTURE AS CODE Applying tools and practices from software engineering to managing infrastructure.
- 8. DEFINE SYSTEMS AS CODE System design is: ▪ Reusable ▪ Consistent ▪ Visible ▪ Versioned
- 10. DYNAMIC INFRASTRUCTURE PLATFORMS Cloud (IaaS) Virtual Physical Compute Storage Network
- 14. CONFIGURATION DRIFTServers start out identical But changes accumulate over time
- 16. AUTOMATION LAG The longer it’s been since an automated process has run in the same context … … the more work is needed to run it again
- 17. Apply small changes frequently rather than large batches infrequently
- 20. DEVOOPS How can we avoid damage from automated mistakes?
- 21. AUTOMATICALLY TEST EVERY CHANGE
- 23. BUILD COMPLIANCE INTO THE PIPELINE Humans focus on the implementation of the pipeline and audit trailsUse the pipeline to continuously validate operational requirements and compliance, and to implement controls
- 24. INFRASTRUCTURE DESIGN PATTERNS Organizing code for dynamic infrastructure
- 26. INFRASTRUCTURE DESIGN PRINCIPLE Structure your code to minimize risks for making (small, frequent) changes
- 29. How do we build and test this stuff? It runs sooooo sloooooow! L
- 30. Nginx Cookbook ORGANIZE INFRASTRUCTURE INTO SEPARATELY TESTABLE PIECES Tomcat Cookbook JDK Cookbook MyApp Vhost Cookbook MyApp.war Application Server Web Server
- 31. FAN-IN PIPELINES TEST TOMCAT COOKBOOK TEST MYAPP CODE TEST JDK COOKBOOK TEST APP SERVER TEST MYAPP DEPLOYMENT Test components individually Cumulatively integrate and test components together
- 32. DESIGNING FOR CHANGE Cope with growth, evolving requirements, expanding teams
- 33. DESIGN TO ENABLE FREQUENT CHANGES Split infrastructure according to the scope of typical changes Minimize the risk of changes by limiting the blast radius Keep infrastructure units loosely coupled
- 34. ALIGN INFRASTRUCTURE DESIGN WITH ORGANIZATION STRUCTURE
- 37. Split infrastructure in ways that reduce the friction for making changes
- 38. SHARING How can teams share their stuff?
- 39. LIBRARY PATTERN FOR INFRA Tested server images BUILD TEST BUILD TEST PROD BUILD TEST PROD Server image pipeline Application environment pipelines
- 40. DECOUPLED CHANGE PIPELINES Application A with its environment TESTBUILD Application B TESTBUILD Application C TESTBUILD QA PROD QA PROD QA PROD
- 41. HANDLING DEPENDENCIES TESTBUILD QA PROD TESTBUILD QA PROD Self-service test instances Consumer Driven Contract (CDC) Tests Mocks, stubs, and fakes
- 42. CYCLE TIME Measure and optimize the elapsed time from identifying a need to satisfying it
- 43. SOME ACTIVITIES TO MEASURE Rebuild (Recover) New environment Update existing environments Introducing a new tech stack
- 44. SOME OTHER BOOKS
- 45. Book: http://oreil.ly/1JKIBVe Site: http://infrastructure-as-code.com Twitter: @kief kief@thoughtworks.com Cloud Practice Lead (UK) DevOps, Continuous Delivery, Agile Ops