More on Cookbook Design Patterns


#1

Ohai Chefs!

I have been reviewing the different cookbook design patterns and I’m coming to
a crossroad about where specific types of cookbooks fall. I have my idea but
some of the blog posts I have read recently seem to contradict mine. I am
going to list out a few cookbooks and where I think they fall and the reason I
have chosen to do it this way:

Library Cookbooks:
Cookbooks that provide lwrps and libraries that are used for building blocks.
May depend on another library cookbook. Most of the time these are from the
community.
Examples:
apt
yum
dns

Infrastructure Cookbooks:
Cookbooks that are like a library but have recipes for installing a service or
software that is not business software. May depend on other library or
infrastructure cookbooks.
java
apache2
mysql
mongodb

Wrapper Cookbooks:
Wrap a library or infrastructure cookbook. Uses the optimistic operator in
metadata for dependencies.
acme-java
acme-mysql
acme-mongodb

Application Cookbooks:
Installs and configures the software relating to my business. May depend on a
wrapper, library or infrastructure cookbook. Defines a run list so acts like a
role cookbook as well. Uses the optimistic operator for dependency version
management.
Examples:
my_rails_app
my_java_app

With the above patterns I would only lock my application cookbooks in my
environment files and all other version constraints would be handled at the
metadata.rb level. I would also use Berkshelf to manage the dependencies to
keep things sane.

I also have a few other cookbooks that I’m not sure where they fall and would
like some help on that. Such as a base cookbook that runs on all our nodes.
What pattern does that fall under?

I was also wondering about a “datacenter” cookbook which I brought up on a post
from Jullian
(http://www.getchef.com/blog/2013/12/03/doing-wrapper-cookbooks-right/#comment-1315553649)
about how best to handle various settings and potentially a few extra
resources/recipes that might need to be run in a particular datacenter. Does
any one have any thoughts on what cookbook pattern this type falls under? Any
examples would be greatly appreciated.

I’m sure a lot of folks have pondered over where their cookbook falls so at the
least I hope this sparks a good discussion.

  • Jay

#2

Hey Jay,
I’ve been thinking about the same thing for awhile. I came up with a
framework to break cookbooks into three categories: infrastructure,
platform and application. I presented this idea at a meetup in Minneapolis (
https://tomduffield.com/everything-as-a-cookbook-devops-minneapolis-meetup/)
and it was well received. A few individuals took this pattern back to their
jobs and are still using it today.

If you follow the pattern I outline its pretty easy to decide which pattern
to follow based on what you want your cookbook to do. For your base
cookbook, that would be an application cookbook since it specific to your
environment. I think if you wanted to create a “datacenter” cookbook, that
being a cookbook that had patterns for how you determine information about
the data center you are in, that would be an infrastructure cookbook. If
you are looking for a place to just stick information about your data
center, I don’t think a cookbook is the best place for that.

Take a look at those slides and let me know if any of that makes sense to
you.

Thanks,
Tom

Tom Duffield — Consulting Engineer

651.769.7497 – tom@getchef.com – *my:
*Linkedinhttp://www.linkedin.com/in/thomasduffield
Twitter http://www.twitter.com/tomduffield
CHEF

GETCHEF.COM http://www.getchef.com/

TM

getchef.com http://www.getchef.com/ Bloghttp://www.opscode.com/blog/
Facebook https://www.facebook.com/getchefdotcom
Twitterhttps://twitter.com/chef
Youtube https://www.youtube.com/getchef

Meet me at #ChefConf 2014 http://chefconf.com/

On Wed, Apr 2, 2014 at 3:37 PM, JayP bosoxjay@gmail.com wrote:

Ohai Chefs!

I have been reviewing the different cookbook design patterns and I’m
coming to
a crossroad about where specific types of cookbooks fall. I have my idea
but
some of the blog posts I have read recently seem to contradict mine. I am
going to list out a few cookbooks and where I think they fall and the
reason I
have chosen to do it this way:

Library Cookbooks:
Cookbooks that provide lwrps and libraries that are used for building
blocks.
May depend on another library cookbook. Most of the time these are from
the
community.
Examples:
apt
yum
dns

Infrastructure Cookbooks:
Cookbooks that are like a library but have recipes for installing a
service or
software that is not business software. May depend on other library or
infrastructure cookbooks.
java
apache2
mysql
mongodb

Wrapper Cookbooks:
Wrap a library or infrastructure cookbook. Uses the optimistic operator in
metadata for dependencies.
acme-java
acme-mysql
acme-mongodb

Application Cookbooks:
Installs and configures the software relating to my business. May depend
on a
wrapper, library or infrastructure cookbook. Defines a run list so acts
like a
role cookbook as well. Uses the optimistic operator for dependency version
management.
Examples:
my_rails_app
my_java_app

With the above patterns I would only lock my application cookbooks in my
environment files and all other version constraints would be handled at the
metadata.rb level. I would also use Berkshelf to manage the dependencies
to
keep things sane.

I also have a few other cookbooks that I’m not sure where they fall and
would
like some help on that. Such as a base cookbook that runs on all our
nodes.
What pattern does that fall under?

I was also wondering about a “datacenter” cookbook which I brought up on a
post
from Jullian
(
http://www.getchef.com/blog/2013/12/03/doing-wrapper-cookbooks-right/#comment-1315553649
)
about how best to handle various settings and potentially a few extra
resources/recipes that might need to be run in a particular datacenter.
Does
any one have any thoughts on what cookbook pattern this type falls under?
Any
examples would be greatly appreciated.

I’m sure a lot of folks have pondered over where their cookbook falls so
at the
least I hope this sparks a good discussion.

  • Jay