Slide 1

Slide 1 text

Agile Infrastructure Development with Test Kitchen Agile 2014, Orlando Fletcher Nichol @fnichol github.com/fnichol

Slide 2

Slide 2 text

Heavy Water Operations http://hw-ops.com

Slide 3

Slide 3 text

@fnichol

Slide 4

Slide 4 text

Our time together

Slide 5

Slide 5 text

1. Context From pain and frustration to Test Kitchen

Slide 6

Slide 6 text

2. Theory Agile Infrastructure and Test Kitchen introduction

Slide 7

Slide 7 text

3. Practice Use Test Kitchen to drive development of infrastructure code

Slide 8

Slide 8 text

I. Context

Slide 9

Slide 9 text

I want to bring joy to others

Slide 10

Slide 10 text

I want to be happy

Slide 11

Slide 11 text

My Why? I want to be happy.

Slide 12

Slide 12 text

What makes me happy? Having confidence in my work.

Slide 13

Slide 13 text

What can make me confident about my work? Knowing that my work functions correctly by watching it succeed & recover in failure.

Slide 14

Slide 14 text

How can I run my work regularly? Have an automated test suite that can execute on demand.

Slide 15

Slide 15 text

What prevents failures and regressions over time? Drive development & design with tests.

Slide 16

Slide 16 text

JamieCI

Slide 17

Slide 17 text

The Accidental Project

Slide 18

Slide 18 text

I write infrastructure code

Slide 19

Slide 19 text

Chef cookbook code

Slide 20

Slide 20 text

Open Source Software… In free time

Slide 21

Slide 21 text

RVM cookbook

Slide 22

Slide 22 text

RVM Cookbook Complex

Slide 23

Slide 23 text

RVM Cookbook Multiple installation setups

Slide 24

Slide 24 text

RVM Cookbook Lenghty converges (+40 minutes per platform)

Slide 25

Slide 25 text

RVM Cookbook Many Chef cookbook components (recipes, providers, resources, etc.)

Slide 26

Slide 26 text

Friday Night Hacks™

Slide 27

Slide 27 text

December 1, 2012

Slide 28

Slide 28 text

RVM pull request testing

Slide 29

Slide 29 text

Frustration

Slide 30

Slide 30 text

Slide 31

Slide 31 text

“I know, I’ll use Vagrant!”

Slide 32

Slide 32 text

Insane Vagrantfile

Slide 33

Slide 33 text

Extract to Ruby Hash

Slide 34

Slide 34 text

Extract to YAML

Slide 35

Slide 35 text

“Houston, we have a library!”

Slide 36

Slide 36 text

commit fda10bb71cc45c7eebeb4355f8dafa2b55f00709 Author: Fletcher Nichol Date: Sat Dec 1 10:51:52 2012 -0700 Jamie: A Chef Convergence Integration Test Harness. Also, what the heck I am getting into here?

Slide 37

Slide 37 text

Validate in December 2012

Slide 38

Slide 38 text

Combine forces with Opscode (Chef), January 2013

Slide 39

Slide 39 text

Jamie code + Test Kitchen name

Slide 40

Slide 40 text

commit c8303426363a50a08137e518e124dad31facb9f1 Author: Fletcher Nichol Date: Mon Jan 28 22:22:08 2013 -0700 Thank you Jamie, hello Test Kitchen. This is a first-pass renaming of the Jamie project to test-kitchen. The following are major breaking changes: * all constant references of `Jamie` have been renamed to `Kitchen` * the .jamie.yml file has been renamed to .kitchen.yml * the binary bin/jamie has been renamed to bin/kitchen * the Rake task namespace :jamie is now :kitchen * the Thor task namespace :jamie is now :kitchen * the `kitchen new_plugin` subcommand will create a 'kitchen-*' gem project

Slide 41

Slide 41 text

YAY!

Slide 42

Slide 42 text

Open to wider community

Slide 43

Slide 43 text

Happiness!

Slide 44

Slide 44 text

No content

Slide 45

Slide 45 text

I want to bring joy to others

Slide 46

Slide 46 text

I want to be happy

Slide 47

Slide 47 text

II. Theory

Slide 48

Slide 48 text

Agile Infrastructure

Slide 49

Slide 49 text

Agile Software

Slide 50

Slide 50 text

Manifesto for Agile Software Development “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Slide 51

Slide 51 text

Manifesto for Agile Software Development * Individuals and interactions over processes and tools

Slide 52

Slide 52 text

Manifesto for Agile Software Development * Working software over comprehensive docs

Slide 53

Slide 53 text

Manifesto for Agile Software Development * Customer collaboration over contract negotiation

Slide 54

Slide 54 text

Manifesto for Agile Software Development * Responding to change over following a plan

Slide 55

Slide 55 text

Manifesto for Agile Software Development That is, while there is value in the items on the right, we value the items on the left more.”

Slide 56

Slide 56 text

Agile Infrastructure?

Slide 57

Slide 57 text

Manifesto for Agile Software Development “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Slide 58

Slide 58 text

Manifesto for Agile Infrastructure Development “We are uncovering better ways of deploying infrastructure by doing it and helping others do it. Through this work we have come to value:

Slide 59

Slide 59 text

Manifesto for Agile Software Development * Working software over comprehensive docs

Slide 60

Slide 60 text

Manifesto for Agile Software Development * Working infrastructure over comprehensive docs

Slide 61

Slide 61 text

Manifesto for Agile Software Development * Customer collaboration over contract negotiation

Slide 62

Slide 62 text

Manifesto for Agile Infrastructure Development * Dev and Ops collaboration over siloed teams

Slide 63

Slide 63 text

Manifesto for Agile Software Development * Responding to change over following a plan

Slide 64

Slide 64 text

Manifesto for Agile Infrastructure Development * Responding to change over following a plan ;)

Slide 65

Slide 65 text

What is missing?

Slide 66

Slide 66 text

Infrastructure as code

Slide 67

Slide 67 text

What is infrastructure as code?

Slide 68

Slide 68 text

Infrastructure as code “Enable the reconstruction of the business from nothing but a source code repository, an application data backup, and bare metal resources” - Adam Jacob, Web Operations

Slide 69

Slide 69 text

Infrastructure as Code Fr D v r’ P f V w Devopsdays Portland 2013 Fletcher Nichol @fnichol http://hw-ops.com/

Slide 70

Slide 70 text

Infrastructure as Code, from a Developer’s Point of View http://vimeo.com/album/2598520/video/78770945

Slide 71

Slide 71 text

IaC let’s us use software development practices and processes

Slide 72

Slide 72 text

Agile is a set of practices and processes

Slide 73

Slide 73 text

TDD

Slide 74

Slide 74 text

TDD “‘Only ever write code to fix a failing test.’ That's test-driven development, or TDD, in one sentence.” - Lasse Koskela, Test Driven

Slide 75

Slide 75 text

From Test Driven: Three Benefits

Slide 76

Slide 76 text

TDD Benfits 1. “I rarely get a support call or end up in a long debugging session.” - Lasse Koskela, Test Driven

Slide 77

Slide 77 text

TDD Benfits 2. “I feel confident in the quality of my work.” - Lasse Koskela, Test Driven

Slide 78

Slide 78 text

TDD Benfits 3. “I have more time to develop as a professional.” - Lasse Koskela, Test Driven

Slide 79

Slide 79 text

Test Driven “Deep down, we want to write code that works.” - Lasse Koskela, Test Driven

Slide 80

Slide 80 text

BDD

Slide 81

Slide 81 text

BDD “Behavior-Driven Development is about implementing an application by describing its behavior from the perspective of its stakeholders.” - David Chelimsky, The RSpec Book

Slide 82

Slide 82 text

BDD “BDD is a second-generation, outside-in, pull- based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well- defined outputs, resulting in the delivery of working, tested software that matters.” - Dan North, Agile specifications, BDD and Testing eXchange

Slide 83

Slide 83 text

Outside-in

Slide 84

Slide 84 text

Acceptance features

Slide 85

Slide 85 text

Unit tests

Slide 86

Slide 86 text

A flow

Slide 87

Slide 87 text

Also…

Slide 88

Slide 88 text

Given When Then

Slide 89

Slide 89 text

Given/When/Then “Given, When, Then, the BDD triad, are simple words that we use whether we’re talking about application behavior or object behavior. They are easily understood by business analysts, testers, and developers alike.” - David Chelimsky, The RSpec Book

Slide 90

Slide 90 text

Given

Slide 91

Slide 91 text

When

Slide 92

Slide 92 text

Then

Slide 93

Slide 93 text

Make sense?

Slide 94

Slide 94 text

Test Kitchen

Slide 95

Slide 95 text

Test Kitchen is: A test harness tool to execute your configured code on one or more platforms in isolation

Slide 96

Slide 96 text

Goals

Slide 97

Slide 97 text

Simple workflow

Slide 98

Slide 98 text

Declarative static configuration

Slide 99

Slide 99 text

Favors speed in development

Slide 100

Slide 100 text

But optimizes for freshness of code

Slide 101

Slide 101 text

Decoupled plugin architecture

Slide 102

Slide 102 text

Dead simple CI integration

Slide 103

Slide 103 text

Testing freedom

Slide 104

Slide 104 text

Framework agnostic

Slide 105

Slide 105 text

Concurrent execution

Slide 106

Slide 106 text

Isolated log files

Slide 107

Slide 107 text

Virtualization freedom

Slide 108

Slide 108 text

Explicit vs. Implicit

Slide 109

Slide 109 text

Concepts

Slide 110

Slide 110 text

Kitchen converges with provisioners and runs specific suites on target platforms called instances using drivers

Slide 111

Slide 111 text

Platform Operating system or target environment

Slide 112

Slide 112 text

Platform Hardware architecture, networking, virtualization, etc.

Slide 113

Slide 113 text

Platform It has a name

Slide 114

Slide 114 text

--- platforms: - name: ubuntu-14.04 - name: centos-6.5 - name: ubuntu-14.04-chef10

Slide 115

Slide 115 text

Suite A particular setup on a platform

Slide 116

Slide 116 text

Suite A Chef configuration

Slide 117

Slide 117 text

Suite run-list, node attributes, etc.

Slide 118

Slide 118 text

Suite It has a name

Slide 119

Slide 119 text

--- suites: - name: client-libs run_list: - recipe[derp::client] attributes: chef: is_fun - name: server - name: runit-server

Slide 120

Slide 120 text

Instance A platform + suite with auto- generated name

Slide 121

Slide 121 text

Instance A platform + suite

Slide 122

Slide 122 text

Instance Name is auto-generated

Slide 123

Slide 123 text

> kitchen list --bare client-libs-ubuntu-1404 server-ubuntu-1404 runit-server-ubuntu-1404 client-libs-centos-65 server-centos-65 runit-server-centos-65 ...

Slide 124

Slide 124 text

Instance Has associated actions

Slide 125

Slide 125 text

Instance Action 1. Create

Slide 126

Slide 126 text

Instance Action 2. Converge

Slide 127

Slide 127 text

Instance Action 3. Setup

Slide 128

Slide 128 text

Instance Action 4. Verify

Slide 129

Slide 129 text

Instance Action 5. Destroy

Slide 130

Slide 130 text

Instance Action (11). Test

Slide 131

Slide 131 text

Driver Implementation of instance actions: create, converge, setup, verify, destroy

Slide 132

Slide 132 text

Driver Packaged as a RubyGem

Slide 133

Slide 133 text

Driver One driver per instance

Slide 134

Slide 134 text

Driver Defines its own configuration requirements

Slide 135

Slide 135 text

--- driver: name: docker socket: <%= ENV[‘DOCKER_HOST’] %>

Slide 136

Slide 136 text

Drivers ec2, rackspace, digital_ocean, openstack, bluebox, lxc, vagrant, cloudstack, joyent, vsphere, gce, azure, docker, etc.

Slide 137

Slide 137 text

Driver Need another one? Write one!

Slide 138

Slide 138 text

Provisioner Implementation of infrastructure automation tool or framework

Slide 139

Slide 139 text

Chef Provisioners chef_solo chef_zero

Slide 140

Slide 140 text

Provisioners shell

Slide 141

Slide 141 text

Community Provisioners Puppet, Salt, others

Slide 142

Slide 142 text

--- provisioner: name: chef_zero require_chef_omnibus: 11.10.2 nodes_path: ./nodes

Slide 143

Slide 143 text

Provisioner Need one? Write one! (For now) just be careful

Slide 144

Slide 144 text

Kitchen converges with provisioners and runs specific blah blah blababibty blah and lets you optionally run tests on them to verify state

Slide 145

Slide 145 text

Busser Prepares instances for test suites and runs them

Slide 146

Slide 146 text

“Your Mars Rover on a converged node” - me

Slide 147

Slide 147 text

“Your tests, your way!” - also me

Slide 148

Slide 148 text

Busser Only dependency is Ruby (and thor gem)

Slide 149

Slide 149 text

Busser Installs test runner plugins

Slide 150

Slide 150 text

Busser Runner Plugins busser-bash, busser-bats, busser- minitest, busser-shunit2, busser- aruba, busser-serverspec, busser- rspec, busser-shpec, busser-cucumber

Slide 151

Slide 151 text

No tests? No problem!

Slide 152

Slide 152 text

III. Practice

Slide 153

Slide 153 text

Two katas:

Slide 154

Slide 154 text

1. Up & using

Slide 155

Slide 155 text

Chef http://www.getchef.com/

Slide 156

Slide 156 text

Chef DK http://downloads.getchef.com/chef-dk

Slide 157

Slide 157 text

Vagrant http://www.vagrantup.com/

Slide 158

Slide 158 text

Docker https://www.docker.com/

Slide 159

Slide 159 text

dvm http://fnichol.github.io/dvm/

Slide 160

Slide 160 text

bats https://github.com/sstephenson/bats

Slide 161

Slide 161 text

2. TDD flow

Slide 162

Slide 162 text

RSpec https://github.com/rspec/rspec

Slide 163

Slide 163 text

Serverspec http://serverspec.org/

Slide 164

Slide 164 text

Starting Yourself

Slide 165

Slide 165 text

Step 1. gem install test-kitchen

Slide 166

Slide 166 text

Step 2. kitchen init

Slide 167

Slide 167 text

Step 2. kitchen test

Slide 168

Slide 168 text

More Information

Slide 169

Slide 169 text

Test Kitchen Site http://kitchen.ci/

Slide 170

Slide 170 text

Getting Started Guide http://kitchen.ci/docs/getting-started/

Slide 171

Slide 171 text

Thank you! Fletcher Nichol @fnichol github.com/fnichol