Upgrade to Pro — share decks privately, control downloads, hide ads and more …

DevOpsDays Cuba 2016: Infrastructure as Code with test approach

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.

DevOpsDays Cuba

October 20, 2016
Tweet

More Decks by DevOpsDays Cuba

Other Decks in Technology

Transcript

  1. Infrastructure as Code with test approach
    Enrique Carbonell
    DevOpsDays Cuba
    October 2016

    View full-size slide

  2. About me
    • BS Computer Science
    • Software Engineer
    • Team Leader
    • Ops team
    • DevOps Enthusiast
    Twitter: @kikicarbonell
    LinkedIn: /enrique-carbonell

    View full-size slide

  3. 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….

    View full-size slide

  4. Bussiness provider perspective
    • Speed
    • Innovation
    • Availability
    • Stability

    View full-size slide

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

    View full-size slide

  6. Innovation
    • Collaboration
    • Experimentation
    • Rapid validation
    • Market needs

    View full-size slide

  7. Availability
    • Downtime

    View full-size slide

  8. Stability
    • Infrastructure trust
    • Mean time to recovery (MTTR)
    • Mean Time Between Failure (MTBF)

    View full-size slide

  9. IT Considerations?
    • Hosting
    • Dependencies
    • Installation
    • Configuration
    • Updates

    View full-size slide

  10. 90’s style
    • Manual installation
    • Manual configuration
    • Manual updates
    • Manual fixtures
    • Manual scale
    • Manual …

    View full-size slide

  11. Consequences
    higher complexity

    View full-size slide

  12. Consequences
    Know-How of SAMURAI

    View full-size slide

  13. Consequences
    Concentration of knowledge

    View full-size slide

  14. Consequences
    No documentation or poor
    documentations of procedures

    View full-size slide

  15. Consequences
    High probabilities of failure

    View full-size slide

  16. 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

    View full-size slide

  17. Configuration Management Tools

    View full-size slide

  18. Infrastructure as Code

    View full-size slide

  19. 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

    View full-size slide

  20. 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

    View full-size slide

  21. Who is using them?

    View full-size slide

  22. Goals of IaC
    • Changes to the system are routine, without drama or stress for users
    or IT staff.
    Kieff Morris

    View full-size slide

  23. 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.

    View full-size slide

  24. 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.

    View full-size slide

  25. Goals of IaC
    • Work as developer
    • Code is documented
    • Peer review and pairing
    • Continuous delivery
    • Auditing

    View full-size slide

  26. Work as developer
    • Code is portable
    • Code is reusable
    • Code is version controlled

    View full-size slide

  27. Peer review and pairing
    • Code can be developed by anyone
    • Code changes can be reviewed by anyone

    View full-size slide

  28. Continuous delivery
    • Code is repeatable
    • Code is shareable
    • Code is promotable
    • Code is testeable

    View full-size slide

  29. 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

    View full-size slide

  30. Test Driven Infrastructure (TDI)

    View full-size slide

  31. How do it?
    • Syntax check
    • TDD
    • BDD

    View full-size slide

  32. Tools and resources

    View full-size slide

  33. Why Ansible in Cuba?

    View full-size slide

  34. Test: Use new tools Vs known tools

    View full-size slide

  35. Our role test
    • Syntax check
    • First success
    • Idempotence check
    • Unit test
    • Behavior test

    View full-size slide

  36. Example: nginx role structure

    View full-size slide

  37. Example: nginx role use-case.yml

    View full-size slide

  38. Example: nginx role unit test.yml

    View full-size slide

  39. Example: nginx role behavior-test.yml

    View full-size slide

  40. Our playbook test
    • Syntax check
    • First success
    • Idempotence check
    • Integration test

    View full-size slide

  41. IaC test environment

    View full-size slide

  42. Test pipeline

    View full-size slide

  43. Recomendation
    • Have a sysadmins as coworker of developers
    • Automate the most repetitive tasks in Ops
    •Test…Test…Test

    View full-size slide