Chef Role cookbooks and Automate Workflow

Eventually you will have multiple base cookbooks and you may want to combine them into a single logical unit, so that can be tested together. Take for example a cookbook called role_my_company_website. This cookbook’s default recipe might look like the following:

include_recipe 'my_company_windows_base::default'

include_recipe 'my_company_audit::default'

include_recipe 'my_company_iis::default'

include_recipe 'my_company_website::default'

Then in this cookbook’s metadata.rb you would have hard version pinnings for each of the dependent cookbooks.

By doing this you can now apply role_my_company_website to a node and test it as a cumulative collection of all its underlying cookbooks. Then, if all the dependant cookbooks have proper tests, you only have to worry about testing the output of role_my_company_website without having to test each of its underlying components.

This reduces the amount of repeated work and produces an artifact that is:

• Easy to understand 
• Version controlled 
• Independently testable 

This leads to a cookbook that succinctly describes a particular node in your Chef managed ecosystem. You could use this succinct description of node function to your advantage. For example, your load balancer cookbook could find all nodes that have the run_list of recipes['role_my_company_website'] and automatically add them to its backend server list.

The importance of role cookbooks is also seen when using automate workflow. 

If using base cookbooks for multiple projects, pinning should not be done on the base cookbook itself. Since cookbooks are pinned at an environment level if the base cookbook is pinned at the environment and then updated, that base cookbook update will in effect alter all projects using it in that environment (acceptance, union, rehearsal delivered. To prevent this pinning from taking place, through workflow, under

.delivery/build-cookbook/provision.rb 

comment out

delivery-truck::provision

In turn if we version pin only the role cookbook at the environment level, being project specific, any changes made to the role cookbook should not have an effect on any other project.

This does mean that in order for a base cookbook to be updated in a project its version must be changed in the role cookbook. So for every underlying cookbook change the role cookbook will need to be version bumped. This is a much more manual process, but it will provide protection from projects breaking with a change to one base cookbook.

This also has the added benefit of version controlling any version bumps we have in our environments for a given projects node. Since the only version pins in an environment fall on the role cookbook, all other changes to versions should be controlled through the role cookbooks metadata and delivery cli commands. These commits can be tied back to individual users and version changes which will better stabilize the environments.

The leading measure in Workflow, if base cookbooks are not project specific, should sit with role cookbooks. These cookbooks should be used to provision servers, and version pin underlying cookbooks, when going through the Union, Rehearsal and Delivered stages of the Chef Automate Workflow to separate project version pinning.