Cookbook Reusability

Transcript

1. 1.

   Cookbook Reusability! Chef Community Summit 2014

2. 2.

   Sean OMeara! someara@getchef.com! @someara

3. 3.

   whoami

4. 4.

   A Year in Review

5. 5.

   Diversification

6. 6.

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

7. 7.

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

8. 8.

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

9. 9.

   selinux! tmux! varnish ! wordpress!

10. 10.

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

11. 11.

    • Escaped the tyranny of JIRA! • Moved to Github

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

    Rewrites

13. 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. 14.

    yum! yum-*! jenkins! mysql! httpd

15. 15.

    The Evolution of a Chef Cookbook

16. 16.

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

17. 17.

    None
18. 18.

    test / repair test / repair test / repair

19. 19.

    Easy to read Easy to grok Easy to test }

20. 20.

    Stage 2 - if statements

21. 21.

    logic compiled into resource collection

22. 22.

    Resource DSL } Just Ruby }

23. 23.

    Resource DSL } Just Ruby } }Chef

24. 24.

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

25. 25.

    None
26. 26.

    wat

27. 27.

    Why?

28. 28.

    Reusable is useful

29. 29.

    Cross-platform is useful

30. 30.

    We desire useful things

31. 31.

    Platform idioms are hard

32. 32.

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

33. 33.

    Most people just write their own cookbooks from scratch

34. 34.

    I really really really want reusable cross-platform cookbooks

35. 35.

    Lessons Learned

36. 36.

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

37. 37.

    None
38. 38.

    Attributes are an interface

39. 39.

    Attributes are tunable knobs

40. 40.

    None
41. 41.

    You probably just want a variable

42. 42.

    None
43. 43.

    Or even a method

44. 44.

    None
45. 45.

    Using an attribute to track state during a Chef run

    causes tears and sorrow
46. 46.

    Prefer resource parameters

47. 47.

    None
48. 48.

    None
49. 49.

    Primitives are more useful than opinionated policy

50. 50.

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

51. 51.

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

    not files and processes
52. 52.

    Singleton resources are good but confusing. Possibly even dangerous.! !

    Multiple instance support is better! ! Cross-platform resources are best
53. 53.

    None
54. 54.

    BDD / TDD yields high quality cookbooks https://www.flickr.com/photos/glenirah/4376553184

55. 55.

    Test Kitchen! ServerSpec / Minitest / Bats! ChefSpec

56. 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. 57.

    Full test coverage is tedious

58. 58.

    Full test coverage is totally worth it

59. 59.

    Let users bring their own configurations

60. 60.

    It is better to add to a resource_collection than to

    monkey patch it
61. 61.

    Configuration files are the brains of a service

62. 62.

    Manage minimal configuration to get a service running

63. 63.

    Offload further configuration to the user

64. 64.

    conf.d is your friend

65. 65.

    Hide everything else inside a resource

66. 66.

    Add resource parameters when appropriate

67. 67.

    None
68. 68.

    None
69. 69.

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

70. 70.

    Cross-platform resources are even harder

71. 71.

    They can be done!

72. 72.

    Create a resource

73. 73.

    None
74. 74.

    Create a provider

75. 75.

    None
76. 76.

    Subclass platform providers

77. 77.

    None
78. 78.

    None
79. 79.

    None
80. 80.

    None
81. 81.

    None
82. 82.

    Set provider default for platforms

83. 83.

    None
84. 84.

    Do Repeat Yourself

85. 85.

    Some resources are often the duplicated across providers

86. 86.

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

87. 87.

    Maximize for grokability

88. 88.

    People will be reading your code for the first time

    during operations work
89. 89.

    Init systems are annoying

90. 90.

    Using a service resource usually requires file or template resources

    in addition to service[thingd]
91. 91.

    Debconf! Docker! LaunchD! Runit! SMF! Simple! SystemD! Sysvinit! Upstart! Windows

    Services
92. 92.

    Subclassing is awesome

93. 93.

    None
94. 94.

    Customize before recipe compilation

95. 95.

    Going Forward

96. 96.

    Cookbooks that ship resource primitives

97. 97.

    More examples to copy

98. 98.

    More breaking backwards compatibility (sorry)

99. 99.

    Providers implemented with Docker containers (why not?)

100. 100.

     chef-metal

101. 101.

     Tell me what you think

102. 102.

     Please don’t hurt me =)

103. 103.

     None