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

Agile 2014 - Agile Infrastructure Development with Test Kitchen

Agile 2014 - Agile Infrastructure Development with Test Kitchen

Why would we test infrastructure code? Well, you test your application code, right? You wouldn't think of putting a complex website into production without a test harness, would you? We've come a long way with infrastructure as code and are getting closer to better test frameworks and facilities.

Test Kitchen (http://kitchen.ci/) is an integration tool for developing and testing infrastructure code and software on isolated target platforms. It was originally developed with Chef in mind, but it is now being used across different configuration management tools.

This talk will focus on how Test Kitchen can help you shorten the feedback cycle during the development of infrastructure code and discover how it plays nice with other existing tools like ChefSpec, RSpec Puppet, Docker containers, and Vagrant. We will cover getting up and running with Test Kitchen, we will work up a basic greenfield Chef cookbook, and add testing support to a larger real world project. Learn how you can develop infrastructure code using quick iterations and in a Test Driven Development (TDD) cycle. Besides the technology we will look into the benefits of this faster feedback cycle and the current/future state of infrastructure as code testing.

9891e8299426fb9b6e361b84b3155a2d?s=128

Fletcher Nichol

August 04, 2014
Tweet

More Decks by Fletcher Nichol

Other Decks in Technology

Transcript

  1. Agile Infrastructure Development with Test Kitchen Agile 2014, Orlando Fletcher

    Nichol @fnichol github.com/fnichol
  2. Heavy Water Operations http://hw-ops.com

  3. @fnichol

  4. Our time together

  5. 1. Context From pain and frustration to Test Kitchen

  6. 2. Theory Agile Infrastructure and Test Kitchen introduction

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

    code
  8. I. Context

  9. I want to bring joy to others

  10. I want to be happy

  11. My Why? I want to be happy.

  12. What makes me happy? Having confidence in my work.

  13. What can make me confident about my work? Knowing that

    my work functions correctly by watching it succeed & recover in failure.
  14. How can I run my work regularly? Have an automated

    test suite that can execute on demand.
  15. What prevents failures and regressions over time? Drive development &

    design with tests.
  16. JamieCI

  17. The Accidental Project

  18. I write infrastructure code

  19. Chef cookbook code

  20. Open Source Software… In free time

  21. RVM cookbook

  22. RVM Cookbook Complex

  23. RVM Cookbook Multiple installation setups

  24. RVM Cookbook Lenghty converges (+40 minutes per platform)

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

  26. Friday Night Hacks™

  27. December 1, 2012

  28. RVM pull request testing

  29. Frustration

  30. “I know, I’ll use Vagrant!”

  31. Insane Vagrantfile

  32. Extract to Ruby Hash

  33. Extract to YAML

  34. “Houston, we have a library!”

  35. commit fda10bb71cc45c7eebeb4355f8dafa2b55f00709 Author: Fletcher Nichol <fnichol@nichol.ca> 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?
  36. Validate in December 2012

  37. Combine forces with Opscode (Chef), January 2013

  38. Jamie code + Test Kitchen name

  39. commit c8303426363a50a08137e518e124dad31facb9f1 Author: Fletcher Nichol <fnichol@nichol.ca> 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
  40. YAY!

  41. Open to wider community

  42. Happiness!

  43. None
  44. I want to bring joy to others

  45. I want to be happy

  46. II. Theory

  47. Agile Infrastructure

  48. Agile Software

  49. 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:
  50. Manifesto for Agile Software Development * Individuals and interactions over

    processes and tools
  51. Manifesto for Agile Software Development * Working software over comprehensive

    docs
  52. Manifesto for Agile Software Development * Customer collaboration over contract

    negotiation
  53. Manifesto for Agile Software Development * Responding to change over

    following a plan
  54. 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.”
  55. Agile Infrastructure?

  56. 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:
  57. 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:
  58. Manifesto for Agile Software Development * Working software over comprehensive

    docs
  59. Manifesto for Agile Software Development * Working infrastructure over comprehensive

    docs
  60. Manifesto for Agile Software Development * Customer collaboration over contract

    negotiation
  61. Manifesto for Agile Infrastructure Development * Dev and Ops collaboration

    over siloed teams
  62. Manifesto for Agile Software Development * Responding to change over

    following a plan
  63. Manifesto for Agile Infrastructure Development * Responding to change over

    following a plan ;)
  64. What is missing?

  65. Infrastructure as code

  66. What is infrastructure as code?

  67. 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
  68. Infrastructure as Code Fr D v r’ P f V

    w Devopsdays Portland 2013 Fletcher Nichol @fnichol http://hw-ops.com/
  69. Infrastructure as Code, from a Developer’s Point of View http://vimeo.com/album/2598520/video/78770945

  70. IaC let’s us use software development practices and processes

  71. Agile is a set of practices and processes

  72. TDD

  73. TDD “‘Only ever write code to fix a failing test.’

    That's test-driven development, or TDD, in one sentence.” - Lasse Koskela, Test Driven
  74. From Test Driven: Three Benefits

  75. TDD Benfits 1. “I rarely get a support call or

    end up in a long debugging session.” - Lasse Koskela, Test Driven
  76. TDD Benfits 2. “I feel confident in the quality of

    my work.” - Lasse Koskela, Test Driven
  77. TDD Benfits 3. “I have more time to develop as

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

    works.” - Lasse Koskela, Test Driven
  79. BDD

  80. BDD “Behavior-Driven Development is about implementing an application by describing

    its behavior from the perspective of its stakeholders.” - David Chelimsky, The RSpec Book
  81. 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
  82. Outside-in

  83. Acceptance features

  84. Unit tests

  85. A flow

  86. Also…

  87. Given When Then

  88. 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
  89. Given

  90. When

  91. Then

  92. Make sense?

  93. Test Kitchen

  94. Test Kitchen is: A test harness tool to execute your

    configured code on one or more platforms in isolation
  95. Goals

  96. Simple workflow

  97. Declarative static configuration

  98. Favors speed in development

  99. But optimizes for freshness of code

  100. Decoupled plugin architecture

  101. Dead simple CI integration

  102. Testing freedom

  103. Framework agnostic

  104. Concurrent execution

  105. Isolated log files

  106. Virtualization freedom

  107. Explicit vs. Implicit

  108. Concepts

  109. Kitchen converges with provisioners and runs specific suites on target

    platforms called instances using drivers
  110. Platform Operating system or target environment

  111. Platform Hardware architecture, networking, virtualization, etc.

  112. Platform It has a name

  113. --- platforms: - name: ubuntu-14.04 - name: centos-6.5 - name:

    ubuntu-14.04-chef10
  114. Suite A particular setup on a platform

  115. Suite A Chef configuration

  116. Suite run-list, node attributes, etc.

  117. Suite It has a name

  118. --- suites: - name: client-libs run_list: - recipe[derp::client] attributes: chef:

    is_fun - name: server - name: runit-server
  119. Instance A platform + suite with auto- generated name

  120. Instance A platform + suite

  121. Instance Name is auto-generated

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

    ...
  123. Instance Has associated actions

  124. Instance Action 1. Create

  125. Instance Action 2. Converge

  126. Instance Action 3. Setup

  127. Instance Action 4. Verify

  128. Instance Action 5. Destroy

  129. Instance Action (11). Test

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

  131. Driver Packaged as a RubyGem

  132. Driver One driver per instance

  133. Driver Defines its own configuration requirements

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

  135. Drivers ec2, rackspace, digital_ocean, openstack, bluebox, lxc, vagrant, cloudstack, joyent,

    vsphere, gce, azure, docker, etc.
  136. Driver Need another one? Write one!

  137. Provisioner Implementation of infrastructure automation tool or framework

  138. Chef Provisioners chef_solo chef_zero

  139. Provisioners shell

  140. Community Provisioners Puppet, Salt, others

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

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

  143. Kitchen converges with provisioners and runs specific blah blah blababibty

    blah and lets you optionally run tests on them to verify state
  144. Busser Prepares instances for test suites and runs them

  145. “Your Mars Rover on a converged node” - me

  146. “Your tests, your way!” - also me

  147. Busser Only dependency is Ruby (and thor gem)

  148. Busser Installs test runner plugins

  149. Busser Runner Plugins busser-bash, busser-bats, busser- minitest, busser-shunit2, busser- aruba,

    busser-serverspec, busser- rspec, busser-shpec, busser-cucumber
  150. No tests? No problem!

  151. III. Practice

  152. Two katas:

  153. 1. Up & using

  154. Chef http://www.getchef.com/

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

  156. Vagrant http://www.vagrantup.com/

  157. Docker https://www.docker.com/

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

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

  160. 2. TDD flow

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

  162. Serverspec http://serverspec.org/

  163. Starting Yourself

  164. Step 1. gem install test-kitchen

  165. Step 2. kitchen init

  166. Step 2. kitchen test

  167. More Information

  168. Test Kitchen Site http://kitchen.ci/

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

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