Home / server / Questions / 382628
In Process
Josh Nankin
Asked: 2012-04-25 07:26:01 +0800 CST

writing a chef cookbook for an application with lots of dependencies

  • 772

If i have a a software system that has a lot of dependencies on other libraries, like libssl, or libxml etc, should I be creating separate cookbooks for each of these libraries (with a recipe that really only has like 2 lines) or do people do several 'package' blocks in a cookbook to ensure the dependencies are there (and not split out these package blocks to their external cookbooks)?

chef

3 Answers

  1. If you only need to install package dependecies, you can do something simple like this:

    %w{ package1 package2 package3 }.each do |pkg|
  package pkg
end

    Or you can even create an attribute and iterate through those.

    attributes/default.rb:

    default['app']['deps'] = [ "package1", "package2" ]

    recipes/deps.rb:

    node['app']['deps'].each do |pkg|
  package pkg
end

    The second way will allow you to update the package list via overrides.

    You can even add this to a seperate recipe in your cookbook that you can add to the bootstrap run_list, or the application role.

    • 1

  2. As CS3 said it really isn't practical to have hundreds of cookbooks just to end up installing one application. Chef actually uses your system's package manager and can automatically resolve the dependencies for you.

    The only reason you would want to split off a dependency is if you have some specific configuration items that may change across systems, or may vary based on the package that depends on it.

    • 0

  3. I would start by suggesting to just embed your dependencies like installing libssl-dev, libxml2-dev, libxslt-dev, etc directly in the cookbook that installs your application for simplicity.

    Where this approach gets into trouble is if you ever deploy two different application cookbooks on the same image which both contain resources like package "libssl-dev" which is where you'll see a warning about CHEF-3694 resource cloning. Since both cookbooks have a resource named the same thing you wind up with that problem, at some point we do want that to go away and we really want to move to a world where package "libssl-dev" is only defined once in the chef run.

    You can then either start to collect those dependencies in a common cookbook that your application cookbooks will all include (if they're mostly the same deps for every application that you deploy). Or else you can start breaking them out into different application subtypes or being very explicit about single-purpose cookbooks like the opscode xml and zlib cookbooks.

    I would suggest creating a 'platform' cookbook that collects all kinds of misc base stuff that you tend to want on all your platforms (install lsof, tcpdump, strace, zsh, htop along with all the -dev/-devel RPMs and debs that you commonly need). Until that list of things to install becomes too unwieldy then you would need to break it up.

    All of this is debatable, though, and the advantage of more fine-grained cookbooks is that you understand your dependencies much better and your chef runs should have fewer resources and be smaller. Its a bit of a tradeoff between manageability and precision. As a best practice you probably 'should' break them all up. But if too many 'shoulds' start getting in the way of doing real work, then I'd consolidate.

    Berkshelf and test-kitchen and proper integration testing of cookbooks make it a lot easier to have smaller single-purpose cookbooks, but there's a learning curve there and its probably better not to get hung up on busting apart installing libssl-dev into its own cookbook until you're further down the road.

    • 0