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.

Infrastructure as code with test approach

300 views

Published on

Main Talk of first DevOpsDays Cuba 2016.

Published in: Engineering
  • D0WNL0AD FULL ▶ ▶ ▶ ▶ http://1lite.top/WxWkuI ◀ ◀ ◀ ◀
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • D0WNL0AD FULL ▶ ▶ ▶ ▶ http://1lite.top/WxWkuI ◀ ◀ ◀ ◀
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

Infrastructure as code with test approach

  1. 1. Infrastructure as Code with test approach Enrique Carbonell DevOpsDays Cuba October 2016
  2. 2. About me • BS Computer Science • Software Engineer • Team Leader • Ops team • DevOps Enthusiast Twitter: @kikicarbonell LinkedIn: /enrique-carbonell
  3. 3. After 2000
  4. 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. 5. Bussiness provider perspective • Speed • Innovation • Availability • Stability
  6. 6. Speed • Time to market matters • Cycle time matters
  7. 7. Innovation • Collaboration • Experimentation • Rapid validation • Market needs
  8. 8. Availability • Downtime
  9. 9. Stability • Infrastructure trust • Mean time to recovery (MTTR) • Mean Time Between Failure (MTBF)
  10. 10. IT Considerations? • Hosting • Dependencies • Installation • Configuration • Updates
  11. 11. 90’s style • Manual installation • Manual configuration • Manual updates • Manual fixtures • Manual scale • Manual …
  12. 12. Consequences higher complexity
  13. 13. Consequences Know-How of SAMURAI
  14. 14. Consequences Concentration of knowledge
  15. 15. Consequences No documentation or poor documentations of procedures
  16. 16. Consequences High probabilities of failure
  17. 17. SOLUTIONS?
  18. 18. 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
  19. 19. Configuration Management Tools
  20. 20. Infrastructure as Code
  21. 21. 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
  22. 22. 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
  23. 23. Who is using them?
  24. 24. Goals of IaC • Changes to the system are routine, without drama or stress for users or IT staff. Kieff Morris
  25. 25. 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.
  26. 26. 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.
  27. 27. Goals of IaC • Work as developer • Code is documented • Peer review and pairing • Continuous delivery • Auditing
  28. 28. Work as developer • Code is portable • Code is reusable • Code is version controlled
  29. 29. Peer review and pairing • Code can be developed by anyone • Code changes can be reviewed by anyone
  30. 30. Continuous delivery • Code is repeatable • Code is shareable • Code is promotable • Code is testeable
  31. 31. 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
  32. 32. Test Driven Infrastructure (TDI)
  33. 33. How do it? • Syntax check • TDD • BDD
  34. 34. Tools and resources
  35. 35. Ansible
  36. 36. Why Ansible in Cuba?
  37. 37. Test: Use new tools Vs known tools
  38. 38. Our role test • Syntax check • First success • Idempotence check • Unit test • Behavior test
  39. 39. Example: nginx role structure
  40. 40. Example: nginx role use-case.yml
  41. 41. Example: nginx role unit test.yml
  42. 42. Example: nginx role behavior-test.yml
  43. 43. Our playbook test • Syntax check • First success • Idempotence check • Integration test
  44. 44. IaC test environment
  45. 45. Test pipeline
  46. 46. Recomendation • Have a sysadmins as coworker of developers • Automate the most repetitive tasks in Ops •Test…Test…Test

×