Configuration Management Camp 2015

Transcript

1. Chef Reusability! Config Management Camp! Ghent, Belgium! February 2015

2. Sean OMeara! sean@chef.io! @someara

3. whoami

4. Part 1

5. Things that are true

6. New Chef users expect community cookbooks to just work

7. Especially the Chef maintained cookbooks

8. This is not the current state of things

9. This leads to sadness

10. We must repair it

11. People copy patterns

12. The status quo cannot be allowed to continue

13. Common pain points https://www.flickr.com/photos/kwl/4595324641

14. Platform and version support

15. Weak scoping

16. No standard interface

17. Compilation phase work

18. Needing chef-rewind

19. Attributes and precedence

20. Pattern proliferation

21. The path out of the darkness https://www.flickr.com/photos/71267357@N06/15864687537

22. Change how cookbooks are written

23. systems beliefs! behaviors

24. Standardize interfaces

25. Eliminate the pain points

26. Focus on resources

27. Make it super easy! to write resources

28. Ship resources for ALL THE THINGS

29. Copy better patterns

30. Make it fucking delightful

31. None

32. Part 2

33. Simple design patterns https://www.flickr.com/photos/pollock/4172865252

34. None
35. None

36. You just separated data from code

37. You also just built an interface

38. Complex design patterns https://www.flickr.com/photos/alanosaur/6417040565

39. None
40. None

41. This is where things get weird

42. amazon debian-6 debian-7 ubuntu-10.04 ubuntu-12.04 ubuntu-14.04 centos-5 centos-6 centos-7 freebsd-9

    freebsd-10

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

    Services

44. There is a large amount of variation between software versions

45. There is an insane amount variation across platforms

46. These differences need to be handled somewhere

47. Early techniques did everything in the recipe

48. data resource pattern

49. Later techniques focused on isolation

50. Resource pattern isolation

51. None

52. private recipes by convention

53. Resource data isolation

54. None
55. None

56. We now have decision logic in our interface

57. Default values often need to be computed

58. Doing this in the interface leads to sorrow

59. None

60. We need a better way

61. Consumption Patterns https://www.flickr.com/photos/ektogamat/2578779839

62. None
63. None
64. None
65. None

66. Why resources are best https://www.flickr.com/photos/cross_stitch_ninja/4932950637

67. node attributes roles environments databags are nice to haves

68. They drive data about resources

69. Resources are fundamental

70. Resources are strongly scoped

71. Resources have a standardized interface

72. Resources have types, names, and parameters

73. Type

74. Name

75. Parameters

76. Resources have identities

77. None

78. Resource can see each other

79. Promise to talk

80. Promise to listen

81. Resource behave the same across platforms

82. None
83. None
84. None

85. Resource can have multiple providers

86. None

87. Writing simple resources

88. yum

89. </switches github>

90. Writing complex resources

91. mysql httpd

92. </switches github>

93. fin