DevOpsDays Cuba 2016: Infrastructure as Code with test approach

Author: Enrique Carbonell
Summary:
Infrastructure as Code is the automation in the DevOps movement. It is about dynamic infrastructure as a software system, which means that development practices like TDD, BDD, CI, and CD would be used. In some cases, our development and operations teams are using tools such as CFEngine, Puppet, Chef, Ansible, Salt, etc. But not many are using them to their full potential and with test approach. This talk explains some of the core challenges of managing infrastructure and shares how do Test Driven Infrastructure in general terms. The talk walks through from definition of the usual problems managing infrastructures to implementation of infrastructure project with Ansible in order to build a change management pipeline to automatically test and release infrastructure projects. Attendees should come away with an understanding of how concepts such as Test Driven Development, Continuous Integration and Continuous Delivery can be applied to infrastructure.

Transcript

1. Infrastructure as Code with test approach Enrique Carbonell DevOpsDays Cuba October 2016
2. About me • BS Computer Science • Software Engineer • Team Leader • Ops team • DevOps Enthusiast Twitter: @kikicarbonell LinkedIn: /enrique-carbonell
3. After 2000
4. Client perspective - Emplear aplicaciones y servicios de calidad: - Que cubran una necesidad - Que sean fáciles de usar - Que respondan en el tiempo esperado (mínimo) - Que siempre estén disponibles - Que sean seguras - Que….
5. Bussiness provider perspective • Speed • Innovation • Availability • Stability
6. Speed • Time to market matters • Cycle time matters
7. Innovation • Collaboration • Experimentation • Rapid validation • Market needs
8. Availability • Downtime
9. Stability • Infrastructure trust • Mean time to recovery (MTTR) • Mean Time Between Failure (MTBF)
10. IT Considerations? • Hosting • Dependencies • Installation • Configuration • Updates
11. 90’s style • Manual installation • Manual configuration • Manual updates • Manual fixtures • Manual scale • Manual …
13. Consequences higher complexity
14. Consequences Know-How of SAMURAI
15. Consequences Concentration of knowledge
16. Consequences No documentation or poor documentations of procedures
17. Consequences High probabilities of failure
20. SOLUTIONS?
21. Configuration Management Tools? “The configuration management tools (CMT) essentially allow automation of installation, configuration and update of system’s software.….” “Comparison of configuration management tools” Informática 2016
22. Configuration Management Tools
23. Infrastructure as Code
24. Infrastructure as Code (IaC) “…is an approach to infrastructure automation based on practices from software development. It emphasizes consistent, repeatable routines for provisioning and changing systems and their configuration…” Kief Morris Book: Infrastructure as Code 2016
25. Infrastructure as Code (IaC) “…is the process of managing and provisioning computing infrastructure (processes, bare-metal servers, virtual servers, etc.) and their configuration through machine-processable definition files, rather than physical hardware configuration or the use of interactive configuration tools. The definition files may be in a version control system. This has been achieved previously through either scripts or declarative definitions, rather than manual processes…” Wikipedia 2016
27. Who is using them?
28. Goals of IaC • Changes to the system are routine, without drama or stress for users or IT staff. Kieff Morris
29. Goals of IaC • IT staff spends their time on valuable things that engage their abilities, not on routine, repetitive tasks. • Users are able to define, provision, and manage the resources they need, without needing IT staff to do it for them.
30. Goals of IaC • Teams are able to easily and quickly recover from failures, rather than assuming failure can be completely prevented. • Improvements are made continuously, rather than done through expensive and risky “big bang” projects. • Solutions to problems are proven through implementing, testing, and measuring them, rather than by discussing them in meetings and documents.
31. Goals of IaC • Work as developer • Code is documented • Peer review and pairing • Continuous delivery • Auditing
32. Work as developer • Code is portable • Code is reusable • Code is version controlled
33. Peer review and pairing • Code can be developed by anyone • Code changes can be reviewed by anyone
34. Continuous delivery • Code is repeatable • Code is shareable • Code is promotable • Code is testeable
35. Auditing • Code execution can provide detailed, accurate report on actions taken • Code promotion and execution provide authorization records • Code run reports provide defensible audit trails
36. Test Driven Infrastructure (TDI)
37. How do it? • Syntax check • TDD • BDD
38. Tools and resources
39. Ansible
40. Why Ansible in Cuba?
41. Test: Use new tools Vs known tools
42. Our role test • Syntax check • First success • Idempotence check • Unit test • Behavior test
43. Example: nginx role structure
44. Example: nginx role use-case.yml
45. Example: nginx role unit test.yml
46. Example: nginx role behavior-test.yml
47. Our playbook test • Syntax check • First success • Idempotence check • Integration test
48. IaC test environment
49. Test pipeline
50. Recomendation • Have a sysadmins as coworker of developers • Automate the most repetitive tasks in Ops •Test…Test…Test