Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Continuously Testing Infrastructure - Beyond Module Testing - PuppetConf 2014

4,829 views

Published on

Continuously Testing Infrastructure - Beyond Module Testing - Gareth Rushgrove, Puppet Labs

Published in: Technology

Continuously Testing Infrastructure - Beyond Module Testing - PuppetConf 2014

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

×