Continuously Testing Infrastructure - Beyond Module Testing - PuppetConf 2014
•
17 gefällt mir•5,329 views
Continuously Testing Infrastructure - Beyond Module Testing - Gareth Rushgrove, Puppet Labs
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (13)
Ähnlich wie Continuously Testing Infrastructure - Beyond Module Testing - PuppetConf 2014
Ähnlich wie Continuously Testing Infrastructure - Beyond Module Testing - PuppetConf 2014 (20)
Mehr von Puppet
Mehr von Puppet (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Continuously Testing Infrastructure - Beyond Module Testing - PuppetConf 2014
- 1. Continuously Testing Infrastructure Puppet Conf, San Francisco, 2014 Gareth Rushgrove Beyond Module Testing
- 2. @garethr
- 8. Testing individual modules Gareth Rushgrove
- 10. Gareth Rushgrove
- 11. Am talking about
- 13. Testing images and containers Gareth Rushgrove
- 14. Test driving infrastructure as a service Gareth Rushgrove
- 15. Testing with PuppetDB Gareth Rushgrove
- 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
- 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
- 36. Gareth Rushgrove
- 37. Same approach works with containers too Gareth Rushgrove
- 38. Gareth Rushgrove
- 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
- 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
- 66. Gareth Rushgrove
- 67. Now we have the tests, we can provision some infrastructure Gareth Rushgrove
- 69. Gareth Rushgrove
- 70. Gareth Rushgrove
- 72. Gareth Rushgrove
- 73. Gareth Rushgrove
- 75. 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
- 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
- 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