DevOps Zone is brought to you in partnership with:

Ranjib is a system administrator at Google. Prior to Google, Ranjib was a senior consultant with ThoughtWorks. He works on private cloud implementation strategies, cloud adoption, system automation etc. He has worked on both application development as well as system administration, for past 6 years. Prior to ThoughtWorks, Ranjib was working with Persistent Systems . Ranjib has done his gradation in lifescience and masters in Bioinformatics. Ranjib is a staunch FOSS supporter. Ranjib is a DZone MVB and is not an employee of DZone and has posted 13 posts at DZone. You can read more from them at their website. View Full User Profile

7 Tips for Keeping Chef in Shape

  • submit to reddit

These are the things I'm trying out to keep their Chef codebases (and the infrastructure they control) in shape:

  1. Lint stuffs: Syntax checking (rb,irb, conf files etc), style checks, some best practices check (like check for Chef solo), mostly using foodcritic wrapped in rake running it under the Go engine (this setup was done by nikhil initally)
  2. Check for context level best practices (check for defined environments, nodes with an empty runlist, number of updated resources after two consecutive runs [to check idempotency], direct asignment of recipes [always via role] etc) using rspec/Chef API and rake. This is more like integration test.
  3. Infrastructure test: triggering nrpe based tests or minitest report handlers to acknowledge the service provisioning has taken  place correctly.
  4. Versioning cookbooks, version freezing cookbooks per environment and above all enforcing conventions like (app_project_environment) . The rest of the checks handle the tooling by exploiting these conventions. Anything that does not adhere to these are bound to become a work of art.
  5. Measuring most of the stuff using defined states and quantifiiable metrics (if possible), and then graph it (nagios/nrpe and graphite)
  6. Having a common understanding of what goes where (definition? library? lwrp? mulitple recipes?) inside a Chef codebase.
  7. And right now, I'm in the process of setting up a CI server to test the whole community+our own cookbooks against Ubuntu/CentOS containers using openvz against our own build pipelines.

Lastly, if you are building SaaS or PaaS, you are bound to hit the volume of Chef/Puppet/Cfengine scripts that will need their own CI.

Published at DZone with permission of Ranjib Dey, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)