Continuously testing infrastructure

Continuously testing infrastructure

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

98234c645fe8c935edc0fec0186d28b8?s=128

Gareth Rushgrove

September 24, 2014
Tweet

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