Skip to content

Latest commit

 

History

History
7 lines (5 loc) · 1.55 KB

2016-06-10-chef-anti-patterns.md

File metadata and controls

7 lines (5 loc) · 1.55 KB

Chef anti-patterns and Chef

I've been doing some Chef work lately and wanted to know about some best pracices for managing and writing code of for roles, recipes, environemnts, etc. To me the best article is here: http://dougireton.com/blog/2013/02/16/chef-cookbook-anti-patterns/ . The summary is basically:

  • Modifying roles is a trap, you almost never want to do that. This is because roles, unlike recipes are not versioned, so updating a role can cause all kinds of headaches if you have to modify its run_list. The recommended way to set what roles do is to have a wrapper recipe that the role refers to. Since recipes are versionable, it should make updating a role less disruptive process
  • Modifying/forking community cookbooks is a mistake. It's a very easy mistake to make. Modifying a cookbook directly is not an obvious problem until you have to upgrade to the latest and greatest version of that cookbook. The much cleaner way to manage changes is to have a wrapper cookbook that refers to the community cook. This makes upgrading the cookbook much easier and cleaner.

That last point really makes me question why we even have to include the source of the cookbook at all in a chef repo. In fact, the chef modus operandi is to have the source available to you: commands like knife cookbook site download chef-client download the source of the chef-client recipe, check it in and commit it automatically for you. I'm not suprised forking cookbooks is such an easy mistake to make given that the chef workflow involves downloading the source in the first place.