Here is some advice of deploying chef in your environment, that may help you avoid some of the pitfalls of Chef

Try not to Fork Community Recipes #

I did it, and it took me a lot of work to revert to the community Versions. Once you fork a recipe by changing directly into the community version, merging upstream changes will be your task. Unless you do a lot of merging you will disconnect from the community versions rather quickly, and all the maintenance burden will be yours.

A better way is to write wrapper cookbooks that just add to the community version. The way to do so, is to create a new cookbook, add a depends 'cookbook' to the ‘metadata.rb, and create your recipe that starts with include_recipe 'nginx', after which you can proceed to make your changes.

Some cookbooks from the community though are extremely weak, and sometimes don’t really warrant a wrapper cookbook.

Another advantage is, that you can actually upstream fixes you make to a community cookbook, without having to worry about the local changes that are specific to your environment.

Do not use roles for run_lists #

Today i use Chef Roles and Environments just for configuration. Roles and Environments have one big flaw: They are not versioned in Chef. So if you want to add a new cookbook to your run list on a development server to your “Webserver” Role, the Production environment will receive that change too.

Create another cookbook that uses the metadata.rb depends, and include_recipe to build your run lists. That way you can version the run-list cookbook and don’t have to worry about spilling into environments that you didn’t intend it to. These run list cookbooks can also be used to set defaults, which are then also versionable.

Test your Work #

This is probably a somewhat alien concept to a lot of the more traditional admin folk, but once you start with Chef, your infrastructure is code. And code has to be tested.

Create a Development Environment that suits your needs, and use Chef Minitests to verify your results. Do not deploy to your Production Environment.

The better your Test Coverage becomes, the less scary changes to your infrastructure become. If you write a large cookbook today, and skip out on the tests, you will be scared to touch the thing in half a year or so, once you’re not in the code anymore.

Other minor tips #

• If you don’t already use berkshelf, keep your cookbooks in a separate directory in your repo, and use the cookbook_path in your knife.rb
• Where applicable use a dedicated Git Repository for each of your cookbooks
• Put a universal .chef/knife.rb into your repository
• Don’t put site specific configuration into your cookbooks. Use the meta ones, or roles and environments
• shef -z is a good way to interactively work with a chef server
• Don’t run the chef-client as daemon, it is a memory hog, and grows over time. I prefer the Cron variation.
• If at all possible, consider different distributions in your recipes. Try not to specialize onto one. Quite a few of the community cookbooks are impossible to use on RHEL variants because they have been developed on Ubuntu.