Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Cookbook Reusability

Ea72b50eef37ebe730c37d96c5b5dd51?s=47 someara
October 02, 2014

Cookbook Reusability

Chef Summit 2014

Ea72b50eef37ebe730c37d96c5b5dd51?s=128

someara

October 02, 2014
Tweet

Transcript

  1. Cookbook Reusability! Chef Community Summit 2014

  2. Sean OMeara! someara@getchef.com! @someara

  3. whoami

  4. A Year in Review

  5. Diversification

  6. 7zip! apache2! ark! application*! couchdb! Imagemagick! java

  7. logrotate! mercurial! munin! nagios! nginx! ntp! openvpn

  8. pacman! postgresql! python! reprepro! rabbitmq! runit! supervisor

  9. selinux! tmux! varnish ! wordpress!

  10. Supermarket https://www.flickr.com/photos/mobilestreetlife/10885044043

  11. • Escaped the tyranny of JIRA! • Moved to Github

    Issues! • Automated CLA checking! • OSS Artifact Repository
  12. Rewrites

  13. 2009 0.5.2 Chef Vagrant ChefSpec 0.1.0 0.0.2 Minitest-Chef Berkshelf Test

    Kitchen 2010 0.9.0 2011 0.10.0 2012 10.12.0 1.0.0 0.2.0 1.0.0 0.7.0 1.0.0 2013 2014 1.0.0 2.0.0 1.0.0 2.0.0 1.4.0 11.0.0 12.0.0 1.6.5 3.0.0 3.0.0 1.2.2 ServerSpec ChefDK 0.0.1 2.0.0 0.2.2 TDI Capability 0.8.0
  14. yum! yum-*! jenkins! mysql! httpd

  15. The Evolution of a Chef Cookbook

  16. Stage 1 - Paradise https://www.flickr.com/photos/nattu/1385100375/

  17. None
  18. test / repair test / repair test / repair

  19. Easy to read Easy to grok Easy to test }

  20. Stage 2 - if statements

  21. logic compiled into resource collection

  22. Resource DSL } Just Ruby }

  23. Resource DSL } Just Ruby } }Chef

  24. Stage 3 - Crazytown https://www.flickr.com/photos/kwl/4595324641

  25. None
  26. wat

  27. Why?

  28. Reusable is useful

  29. Cross-platform is useful

  30. We desire useful things

  31. Platform idioms are hard

  32. Keeping the Dream Alive https://www.flickr.com/photos/kalexanderson/7014655351/

  33. Most people just write their own cookbooks from scratch

  34. I really really really want reusable cross-platform cookbooks

  35. Lessons Learned

  36. Attributes are routinely abused https://www.flickr.com/photos/jabberwocky381/2828863789

  37. None
  38. Attributes are an interface

  39. Attributes are tunable knobs

  40. None
  41. You probably just want a variable

  42. None
  43. Or even a method

  44. None
  45. Using an attribute to track state during a Chef run

    causes tears and sorrow
  46. Prefer resource parameters

  47. None
  48. None
  49. Primitives are more useful than opinionated policy

  50. “They’re Just Resources”! ! LWRP is Googleable

  51. Zoom out a level! ! Think about services and runtimes,

    not files and processes
  52. Singleton resources are good but confusing. Possibly even dangerous.! !

    Multiple instance support is better! ! Cross-platform resources are best
  53. None
  54. BDD / TDD yields high quality cookbooks https://www.flickr.com/photos/glenirah/4376553184

  55. Test Kitchen! ServerSpec / Minitest / Bats! ChefSpec

  56. 2009 0.5.2 Chef Vagrant ChefSpec 0.1.0 0.0.2 Minitest-Chef Berkshelf Test

    Kitchen 2010 0.9.0 2011 0.10.0 2012 10.12.0 1.0.0 0.2.0 1.0.0 0.7.0 1.0.0 2013 2014 1.0.0 2.0.0 1.0.0 2.0.0 1.4.0 11.0.0 12.0.0 1.6.5 3.0.0 3.0.0 1.2.2 ServerSpec ChefDK 0.0.1 2.0.0 0.2.2 This Slide Again 0.8.0
  57. Full test coverage is tedious

  58. Full test coverage is totally worth it

  59. Let users bring their own configurations

  60. It is better to add to a resource_collection than to

    monkey patch it
  61. Configuration files are the brains of a service

  62. Manage minimal configuration to get a service running

  63. Offload further configuration to the user

  64. conf.d is your friend

  65. Hide everything else inside a resource

  66. Add resource parameters when appropriate

  67. None
  68. None
  69. Cross-platform cookbooks are hard https://www.flickr.com/photos/glenirah/4376553184

  70. Cross-platform resources are even harder

  71. They can be done!

  72. Create a resource

  73. None
  74. Create a provider

  75. None
  76. Subclass platform providers

  77. None
  78. None
  79. None
  80. None
  81. None
  82. Set provider default for platforms

  83. None
  84. Do Repeat Yourself

  85. Some resources are often the duplicated across providers

  86. That’s fine. It’s the pattern as a whole that’s important

  87. Maximize for grokability

  88. People will be reading your code for the first time

    during operations work
  89. Init systems are annoying

  90. Using a service resource usually requires file or template resources

    in addition to service[thingd]
  91. Debconf! Docker! LaunchD! Runit! SMF! Simple! SystemD! Sysvinit! Upstart! Windows

    Services
  92. Subclassing is awesome

  93. None
  94. Customize before recipe compilation

  95. Going Forward

  96. Cookbooks that ship resource primitives

  97. More examples to copy

  98. More breaking backwards compatibility (sorry)

  99. Providers implemented with Docker containers (why not?)

  100. chef-metal

  101. Tell me what you think

  102. Please don’t hurt me =)

  103. None