DevOpsDays Cuba 2016: Infrastructure as Code with test approach

DevOpsDays Cuba 2016: Infrastructure as Code with test approach

Author: Enrique Carbonell
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.


DevOpsDays Cuba

October 20, 2016


  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 •

  6. Speed • Time to market matters • Cycle time matters

  7. Innovation • Collaboration • Experimentation • Rapid validation • Market

  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 …
  12. None
  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

  18. None
  19. None

  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
  26. None
  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