Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

After 2000

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

Bussiness provider perspective • Speed • Innovation • Availability • Stability

Slide 6

Slide 6 text

Speed • Time to market matters • Cycle time matters

Slide 7

Slide 7 text

Innovation • Collaboration • Experimentation • Rapid validation • Market needs

Slide 8

Slide 8 text

Availability • Downtime

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

No content

Slide 13

Slide 13 text

Consequences higher complexity

Slide 14

Slide 14 text

Consequences Know-How of SAMURAI

Slide 15

Slide 15 text

Consequences Concentration of knowledge

Slide 16

Slide 16 text

Consequences No documentation or poor documentations of procedures

Slide 17

Slide 17 text

Consequences High probabilities of failure

Slide 18

Slide 18 text

No content

Slide 19

Slide 19 text

No content

Slide 20

Slide 20 text

SOLUTIONS?

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

Configuration Management Tools

Slide 23

Slide 23 text

Infrastructure as Code

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

No content

Slide 27

Slide 27 text

Who is using them?

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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.

Slide 30

Slide 30 text

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.

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

Test Driven Infrastructure (TDI)

Slide 37

Slide 37 text

How do it? • Syntax check • TDD • BDD

Slide 38

Slide 38 text

Tools and resources

Slide 39

Slide 39 text

Ansible

Slide 40

Slide 40 text

Why Ansible in Cuba?

Slide 41

Slide 41 text

Test: Use new tools Vs known tools

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

Example: nginx role structure

Slide 44

Slide 44 text

Example: nginx role use-case.yml

Slide 45

Slide 45 text

Example: nginx role unit test.yml

Slide 46

Slide 46 text

Example: nginx role behavior-test.yml

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

IaC test environment

Slide 49

Slide 49 text

Test pipeline

Slide 50

Slide 50 text

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