Continuously testing infrastructure

Talk from #puppetconf 2014 all about moving towards infrastructure as code and why policy driven development is a cool idea.

Transcript

1. Continuously Testing Infrastructure Puppet Conf, San Francisco, 2014 Gareth Rushgrove Beyond Module Testing
2. @garethr
3. Gareth Rushgrove
4. Gareth Rushgrove
5. Gareth Rushgrove
6. Not talking about
7. Finished software Gareth Rushgrove
8. Testing individual modules Gareth Rushgrove
9. puppet-lint, puppet-syntax, rspec-puppet, beaker Gareth Rushgrove
10. Gareth Rushgrove
11. Am talking about
12. Experiments Gareth Rushgrove
13. Testing images and containers Gareth Rushgrove
14. Test driving infrastructure as a service Gareth Rushgrove
15. Testing with PuppetDB Gareth Rushgrove
16. Testing images and containers 1
17. Gareth Rushgrove
18. Packer builds images based on a JSON template Gareth Rushgrove
19. Gareth Rushgrove
20. It has some Puppet integration too Gareth Rushgrove
21. Gareth Rushgrove
22. But how do we know the image works? Gareth Rushgrove
23. Lets add some tests! Gareth Rushgrove
24. Gareth Rushgrove
25. shaunduncan/packer-provisioner-host-command Gareth Rushgrove
26. serverspec.org Gareth Rushgrove
27. Gareth Rushgrove
28. Gareth Rushgrove
29. Gareth Rushgrove
30. Serverspec also supports port, file, ppa, selinux, user, group, lxc, iptables, cron and more Gareth Rushgrove
31. Only publish the image if the tests pass Gareth Rushgrove
32. Run tests automatically with a continuous integration system Gareth Rushgrove
33. Gareth Rushgrove
34. Gareth Rushgrove
35. garethr/packer-serverspec-example Gareth Rushgrove
36. Gareth Rushgrove
37. Same approach works with containers too Gareth Rushgrove
38. Gareth Rushgrove
39. garethr/docker-spec-example Gareth Rushgrove
40. Test drive your IaaS 2
41. Test driven development Gareth Rushgrove
42. First the developer writes an automated test case that defines a desired improvement or new function Gareth Rushgrove
43. Then produces the minimum amount of code to pass that test Gareth Rushgrove
44. And finally refactors the new code Gareth Rushgrove
45. Gareth Rushgrove First the developer writes an automated test case that defines a desired improvement or new function
46. Your infrastructure should! have an API Gareth Rushgrove
47. What if we write assertions against! that API? Gareth Rushgrove
48. Aside: Clojure 2.1
49. Gareth Rushgrove
50. Great for building DSLs Gareth Rushgrove
51. Don’t worry, you could write the examples in any language Gareth Rushgrove
52. Policy driven development Gareth Rushgrove
53. I don’t want to launch too many nodes, they’re expensive Gareth Rushgrove Policy
54. Gareth Rushgrove
55. I don’t want any stopped nodes, they are costing me money Gareth Rushgrove Policy
56. Gareth Rushgrove
57. Large nodes are really expensive, so limit their usage Gareth Rushgrove Policy
58. Gareth Rushgrove
59. We should be backing up every node Gareth Rushgrove Policy
60. Gareth Rushgrove
61. I only want nodes in London and ! San Francisco Gareth Rushgrove Policy
62. Gareth Rushgrove
63. All our nodes should be named environment-name Gareth Rushgrove Policy
64. Gareth Rushgrove
65. garethr/digitalocean-expect Gareth Rushgrove
66. Gareth Rushgrove
67. Now we have the tests, we can provision some infrastructure Gareth Rushgrove
68. Aside: Provisioning with Puppet 2.2
69. Gareth Rushgrove
70. Gareth Rushgrove
71. puppetlabs/gce_compute Gareth Rushgrove
72. Gareth Rushgrove
73. Gareth Rushgrove
74. garethr/digitalocean Gareth Rushgrove
75. Gareth Rushgrove
76. bobtfish/aws_api Gareth Rushgrove
77. Testing with PuppetDB 3
78. Aside: PuppetDB 3.1
79. puppetlabs/puppetdb Gareth Rushgrove
80. PuppetDB can store a lot of data about your infrastructure Gareth Rushgrove
81. The most recent facts from every node Gareth Rushgrove
82. The most recent catalog for every node Gareth Rushgrove
83. A wide range of metrics Gareth Rushgrove
84. Gareth Rushgrove
85. I want to run the same operating system on all hosts Gareth Rushgrove Policy
86. Gareth Rushgrove
87. Security enforcing packages should be installed everywhere Gareth Rushgrove Policy
88. Gareth Rushgrove
89. I want to limit how many puppet resources I’m using Gareth Rushgrove Policy
90. Gareth Rushgrove
91. We should avoid heavy I/ O load on the database by maintaining a high catalog duplication rate Gareth Rushgrove Policy
92. Gareth Rushgrove
93. garethr/puppetdb-expect Gareth Rushgrove
94. Testing based on PuppetDB 3.2
95. PuppetDB is a great source of context for tests Gareth Rushgrove
96. Generate serverspec tests from PuppetDB data Gareth Rushgrove
97. Automatically detect hosts, and generate commands Gareth Rushgrove
98. Gareth Rushgrove
99. Match puppet resources to serverspec resources Gareth Rushgrove
100. Gareth Rushgrove
101. For instance on a Puppet Enterprise master Gareth Rushgrove
102. Gareth Rushgrove
103. Run serverspec tests on all puppet managed hosts Gareth Rushgrove
104. Gareth Rushgrove
105. garethr/serverspec-puppetdb Gareth Rushgrove
106. Conclusions
107. Is this monitoring? Gareth Rushgrove
108. We’re still moving towards infrastructure as code Gareth Rushgrove
109. Infrastructure as code rather than infrastructure from code Gareth Rushgrove
110. Taking about policy as code might help communicate intent Gareth Rushgrove
111. Questions? And thanks for listening