cookbook reusability @ chef community summit 2014
Post on 29-Nov-2014
320 Views
Preview:
DESCRIPTION
TRANSCRIPT
Cookbook Reusability!Chef Community Summit
2014
Sean OMeara!someara@getchef.com!
@someara
whoami
A Year in Review
Diversification
7zip!apache2!ark!application*!couchdb!Imagemagick!java
logrotate!mercurial!munin!nagios!nginx!ntp!openvpn
pacman!postgresql!python!reprepro!rabbitmq!runit!supervisor
selinux!tmux!varnish !wordpress!
Supermarket
https://www.flickr.com/photos/mobilestreetlife/10885044043
• Escaped the tyranny of JIRA!
• Moved to Github Issues!
• Automated CLA checking!
• OSS Artifact Repository
Rewrites
2009
0.5.2Chef
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.2TDI Capability
0.8.0
yum!yum-*!jenkins!mysql!httpd
The Evolution of a Chef Cookbook
Stage 1 - Paradise
https://www.flickr.com/photos/nattu/1385100375/
test / repair
test / repair
test / repair
Easy to read Easy to grok Easy to test}
Stage 2 - if statements
logic
compiled into resource collection
Resource DSL}
Just Ruby}
Resource DSL}
Just Ruby} }Chef
Stage 3 - Crazytown
https://www.flickr.com/photos/kwl/4595324641
wat
Why?
Reusable is useful
Cross-platform is useful
We desire useful things
Platform idioms are hard
Keeping the Dream Alive
https://www.flickr.com/photos/kalexanderson/7014655351/
Most people just write their own cookbooks from scratch
I really really really want reusable cross-platform cookbooks
Lessons Learned
Attributes are routinely abused
https://www.flickr.com/photos/jabberwocky381/2828863789
Attributes are an interface
Attributes are tunable knobs
You probably just want a variable
Or even a method
Using an attribute to track state during a Chef run causes tears and sorrow
Prefer resource parameters
Primitives are more useful than opinionated policy
“They’re Just Resources”!!
LWRP is Googleable
Zoom out a level!!
Think about services and runtimes, not files and processes
Singleton resources are good but confusing. Possibly even dangerous.!!
Multiple instance support is better!!
Cross-platform resources are best
BDD / TDD yields high quality cookbooks
https://www.flickr.com/photos/glenirah/4376553184
Test Kitchen!ServerSpec / Minitest / Bats!ChefSpec
2009
0.5.2Chef
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.2This Slide Again
0.8.0
Full test coverage is tedious
Full test coverage is totally worth it
Let users bring their own configurations
It is better to add to a resource_collection than to monkey patch it
Configuration files are the brains of a service
Manage minimal configuration to get a service running
Offload further configuration to the user
conf.d is your friend
Hide everything else inside a resource
Add resource parameters when appropriate
Cross-platform cookbooks are hard
https://www.flickr.com/photos/glenirah/4376553184
Cross-platform resources are even harder
They can be done!
Create a resource
Create a provider
Subclass platform providers
Set provider default for platforms
Do Repeat Yourself
Some resources are often the duplicated across providers
That’s fine. It’s the pattern as a whole that’s important
Maximize for grokability
People will be reading your code for the first time during operations work
Init systems are annoying
Using a service resource usually requires file or template resources in addition to service[thingd]
Debconf!Docker!LaunchD!Runit!SMF!Simple!SystemD!Sysvinit!Upstart!Windows Services
Subclassing is awesome
Customize before recipe compilation
Going Forward
Cookbooks that ship resource primitives
More examples to copy
More breaking backwards compatibility (sorry)
Providers implemented with Docker containers (why not?)
chef-metal
Tell me what you think
Please don’t hurt me =)
top related