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.

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. …
31. “I know, I’ll use Vagrant!”
32. Insane Vagrantfile
33. Extract to Ruby Hash
34. Extract to YAML
35. “Houston, we have a library!”
36. 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?
37. Validate in December 2012
38. Combine forces with Opscode (Chef), January 2013
39. Jamie code + Test Kitchen name
40. 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
41. YAY!
42. Open to wider community
43. Happiness!
45. I want to bring joy to others
46. I want to be happy
47. II. Theory
48. Agile Infrastructure
49. Agile Software
50. 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:
51. Manifesto for Agile Software Development * Individuals and interactions over processes and tools
52. Manifesto for Agile Software Development * Working software over comprehensive docs
53. Manifesto for Agile Software Development * Customer collaboration over contract negotiation
54. Manifesto for Agile Software Development * Responding to change over following a plan
55. 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.”
56. Agile Infrastructure?
57. 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:
58. 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:
59. Manifesto for Agile Software Development * Working software over comprehensive docs
60. Manifesto for Agile Software Development * Working infrastructure over comprehensive docs
61. Manifesto for Agile Software Development * Customer collaboration over contract negotiation
62. Manifesto for Agile Infrastructure Development * Dev and Ops collaboration over siloed teams
63. Manifesto for Agile Software Development * Responding to change over following a plan
64. Manifesto for Agile Infrastructure Development * Responding to change over following a plan ;)
65. What is missing?
66. Infrastructure as code
67. What is infrastructure as code?
68. 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
69. Infrastructure as Code Fr D v r’ P f V w Devopsdays Portland 2013 Fletcher Nichol @fnichol http://hw-ops.com/
70. Infrastructure as Code, from a Developer’s Point of View http://vimeo.com/album/2598520/video/78770945
71. IaC let’s us use software development practices and processes
72. Agile is a set of practices and processes
73. TDD
74. TDD “‘Only ever write code to fix a failing test.’ That's test-driven development, or TDD, in one sentence.” - Lasse Koskela, Test Driven
75. From Test Driven: Three Benefits
76. TDD Benfits 1. “I rarely get a support call or end up in a long debugging session.” - Lasse Koskela, Test Driven
77. TDD Benfits 2. “I feel confident in the quality of my work.” - Lasse Koskela, Test Driven
78. TDD Benfits 3. “I have more time to develop as a professional.” - Lasse Koskela, Test Driven
79. Test Driven “Deep down, we want to write code that works.” - Lasse Koskela, Test Driven
80. BDD
81. BDD “Behavior-Driven Development is about implementing an application by describing its behavior from the perspective of its stakeholders.” - David Chelimsky, The RSpec Book
82. 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
83. Outside-in
84. Acceptance features
85. Unit tests
86. A flow
87. Also…
88. Given When Then
89. 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
90. Given
91. When
92. Then
93. Make sense?
94. Test Kitchen
95. Test Kitchen is: A test harness tool to execute your configured code on one or more platforms in isolation
96. Goals
97. Simple workflow
98. Declarative static configuration
99. Favors speed in development
100. But optimizes for freshness of code
101. Decoupled plugin architecture
102. Dead simple CI integration
103. Testing freedom
104. Framework agnostic
105. Concurrent execution
106. Isolated log files
107. Virtualization freedom
108. Explicit vs. Implicit
109. Concepts
110. Kitchen converges with provisioners and runs specific suites on target platforms called instances using drivers
111. Platform Operating system or target environment
112. Platform Hardware architecture, networking, virtualization, etc.
113. Platform It has a name
114. --- platforms: - name: ubuntu-14.04 - name: centos-6.5 - name: ubuntu-14.04-chef10
115. Suite A particular setup on a platform
116. Suite A Chef configuration
117. Suite run-list, node attributes, etc.
118. Suite It has a name
119. --- suites: - name: client-libs run_list: - recipe[derp::client] attributes: chef: is_fun - name: server - name: runit-server
120. Instance A platform + suite with auto- generated name
121. Instance A platform + suite
122. Instance Name is auto-generated
123. > 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 ...
124. Instance Has associated actions
125. Instance Action 1. Create
126. Instance Action 2. Converge
127. Instance Action 3. Setup
128. Instance Action 4. Verify
129. Instance Action 5. Destroy
130. Instance Action (11). Test
131. Driver Implementation of instance actions: create, converge, setup, verify, destroy
132. Driver Packaged as a RubyGem
133. Driver One driver per instance
134. Driver Defines its own configuration requirements
135. --- driver: name: docker socket: <%= ENV[‘DOCKER_HOST’] %>
136. Drivers ec2, rackspace, digital_ocean, openstack, bluebox, lxc, vagrant, cloudstack, joyent, vsphere, gce, azure, docker, etc.
137. Driver Need another one? Write one!
138. Provisioner Implementation of infrastructure automation tool or framework
139. Chef Provisioners chef_solo chef_zero
140. Provisioners shell
141. Community Provisioners Puppet, Salt, others
142. --- provisioner: name: chef_zero require_chef_omnibus: 11.10.2 nodes_path: ./nodes
143. Provisioner Need one? Write one! (For now) just be careful
144. Kitchen converges with provisioners and runs specific blah blah blababibty blah and lets you optionally run tests on them to verify state
145. Busser Prepares instances for test suites and runs them
146. “Your Mars Rover on a converged node” - me
147. “Your tests, your way!” - also me
148. Busser Only dependency is Ruby (and thor gem)
149. Busser Installs test runner plugins
150. Busser Runner Plugins busser-bash, busser-bats, busser- minitest, busser-shunit2, busser- aruba, busser-serverspec, busser- rspec, busser-shpec, busser-cucumber
151. No tests? No problem!
152. III. Practice
153. Two katas:
154. 1. Up & using
155. Chef http://www.getchef.com/
156. Chef DK http://downloads.getchef.com/chef-dk
157. Vagrant http://www.vagrantup.com/
158. Docker https://www.docker.com/
159. dvm http://fnichol.github.io/dvm/
160. bats https://github.com/sstephenson/bats
161. 2. TDD flow
162. RSpec https://github.com/rspec/rspec
163. Serverspec http://serverspec.org/
164. Starting Yourself
165. Step 1. gem install test-kitchen
166. Step 2. kitchen init
167. Step 2. kitchen test
168. More Information
169. Test Kitchen Site http://kitchen.ci/
170. Getting Started Guide http://kitchen.ci/docs/getting-started/
171. Thank you! Fletcher Nichol @fnichol github.com/fnichol