Beginning Chef Organization

Chef Infra (archive)
1

I'm new to Chef. Currently looking into possibly migrating our very dated and buggy Ansible devops automations to Chef to increase compatibility with other teams.

We've got a service that runs across a large number of machines, many with the same "base" configuration and then a dozen or so different additional configurations based on the specific class of those machines.

Currently my strategy is to write an inspec test for the basic configuration, use that to verify the existing servers (if I can figure out how to do that), and also to build a cookbook for the 'basic' config which I could then run on any machines that aren't fully and properly configured. Then I was going to write additional separate inspec tests to cover the various specialized needs of the various classes of machines and do the same as with the base (verify existing and write new cookbooks, which I could then use to update misconfigured machines.

First question: This strategy makes sense, correct? Appreciate the sanity check since it's new ground for me.

Second question: What's the best/most idiomatic way to organize these tests/cookbooks logically? A single cookbooks/servicename folder with a spec subfolder containing all the tests for both the base and the various classes? Or should it be broken into separate cookbooks for the base and for each class? Will it still be easy to call cookbooks/recipes/tests in sequence that way? (e.g. run "base" then "special-class" then "super-special-features"?)

Thanks for any help!

2

Welcome @stevec !

With Chef, you typically will run chef-client on an interval on every machine to prevent configuration drift. That mean's there is not really a need to see which machines need to run chef-client using inspec first. The idea is that a cookbook is idempotent and running chef-client on machines that are already properly configured will have no effect since they are in the desired state already.

Inspec can be leveraged to run compliance checks on each node every time chef-client runs using the audit cookbook. Writing tests to verify the machines are properly configured is a best-practice.

As far as cookbook and test organization, I would create a chef-repo and within the cookbooks directory write a cookbook for base and any other components in separate cookbooks.

data_bags/
cookbooks/
  my_company_audit/
  my_company_base/
  my_company_nginx/
  my_company_postgresql/
policyfiles/

Then in the policyfiles directory, define a policyfile for each subclass of server. The policyfile will depend on "base", "audit" and any other cookbooks it needs to configure itself.

data_bags/
cookbooks/
  my_company_audit/
  my_company_base/
  my_company_nginx/
  my_company_postgresql/
policyfiles/
  my_web_app.rb

Inspec tests can be stored in their own repository and uploaded to automate, supermarket or just referenced from GitHub. The audit cookbook will be configured to pull the inspec test from one of the sources, run the tests and then report the results to automate.

Hope this helps.