Ten Quick Tips to Improve your Chef Workflow

#1 - Chef Windows Workstation

Contributor: Adam Edwards

1. Install chocolatey – http://chocolatey.org
2. Install PSReadline to give PowerShell readline power – use the –emacs mode in your PowerShell profile so you have history search and other keyboard behavior like bash: https://github.com/lzybkr/PSReadLine
3. Use chocolatey to install ConEmu, a terminal replacement that supports ANSI colors, dynamic resizing, “normal” text selection and cut and paste, and lots of other customizations: cinst conemu. And set the startup shell for ConEmu to PowerShell (not cmd.exe)
4. Use chocolatey to install an editor – if you’re not already an emacs or vim person, use it to install Atom or Sublime, or Notepad++
5. Always use PowerShell – do not use cmd.exe
6. Install ChefDK and use chef shell-init powershell to get at your Chef Ruby environment.
7. Use Pantry – it can automate #1, 3, 4, and 6 and will probably have support for #2. https://github.com/chef/pantry-chef-repo
8. If you get stuck on a box where you don’t an editor or chocolatey and need to edit text, don’t use notepad, use powershell_ise.exe. It understands Unix line endings and has line numbers, the minimum needed to edit some Ruby files and fix syntax / runtime errors.
9. Did I mention always use PowerShell and never use cmd.exe?

#2 - ServerSpec Helper Files

Contributor:  Joshua Timberman
URL:  http://jtimberman.housepub.org/blog/2014/12/31/quick-tip-serverspec-spec-helper-in-test-kitchen/

Quick Tip: Serverspec Spec_helper in Test Kitchen
DEC 31ST, 2014
Recently, I’ve started refactoring some old cookbooks I wrote ages ago. I’m adding Serverspec coverage that can be run with kitchen verify. In this quicktip, I’ll describe how to create a spec_helper that can be used in all the specs. This is a convention used by many in the Ruby community to add configuration for RSpec.

For Chef, we can run integration tests after convergence using Test Kitchen using Serverspec. To do that, we need to require Serverspec, and then set its backend. In some cookbooks, the author/developer may have written spec_helper files in the various test/integration/SUITE/serverspec/ directories, but this will use a single shared file for them all. Let’s get started.

In the .kitchen.yml, add the data_path configuration directive in the provisioner.

 provisioner:
   name: chef_zero
   data_path: test/shared
  
Then, create the test/shared directory in the cookbook, and create the spec_helper.rb in it.

 mkdir test/shared
 $EDITOR test/shared/spec_helper.rb

Minimally, it should look like this:

 require 'serverspec'
 set :backend, :exec

Then in your specs, for example test/integration/default/serverspec/default_spec.rb, require the spec_helper. On the instances under test, the file will be copied to /tmp/kitchen/data/spec_helper.rb.

 require_relative '../../../kitchen/data/spec_helper'

That’s it, now when running kitchen test, or kitchen verify on a converged instance, the helper will be used.

#3 - Use MixLib::ShellOut

Contributor:  Julian Dunn
URL:  https://docs.chef.io/dsl_recipe.html#shell-out

shell_out
The shell_out method can be used to run a command against the node, and then display the output to the console when the log level is set to debug.

The syntax for the shell_out method is as follows:

shell_out(command_args)
where command_args is the command that is run against the node.

shell_out!
The shell_out! method can be used to run a command against the node, display the output to the console when the log level is set to debug, and then raise an error when the method returns false.

The syntax for the shell_out! method is as follows:

shell_out!(command_args)
where command_args is the command that is run against the node. This method will return true or false.

#4 - Record While You Learn

Contributor:  Nell Shamrell-Harrington

Looking over someone's shoulder while they teach you their Chef workflow?  Ask them to record their screen - screen recording software is either available on your OS or should be easily available.  This allows you to keep a record of exactly HOW they accomplished - command for command - rather than just trying to remember multi-step processes.  This has been better for my Chef workflow than any other tip.

#5 - Pre-baked VMs or Containers to Speed Up CD-CI Pipeline

Contributor:  Ann Marie Fred
Spinning up a virtual machine or container and configuring it from scratch is expensive. 
Pre-install large packages and files in your images so that your CI/CD pipeline can quickly spin up VMs for testing.
Leave smaller configuration details for Chef to take care of.

#6 - Use binding.pry for Troubleshooting

Contributor:  Claire McQuin

Ever wish you could stop a Chef run in the middle of execution so you could inspect it closer?  You can use the Ruby 'pry' gem to do exactly this.  

Add this line at the top of your recipe:
 require 'pry'

And then you can add this line where you want the interactive Pry session to start:
 binding.pry

#7 - Use run_state to store temporary data

Contributor: Michael Goetz
Sometimes we need to temporarily store data during a Chef run, but do not wish to store it in the node object.
The run_state is a perfect place to store temporary data and make it available to other resources in your Chef run.

#8 - Coerce all the things

Contributor:  Franklin Webber
Coerce everything instead of checking for nil

Pimp My Text Editor

Contributor:  Matt Stratton
When writing Chef code, use a good text editor with a project drawer or file browser.
Many text editors have plugins available for syntax highlighting, auto-completion, and improving your Ruby style.
Sublime text is a good choice if you don’t already have a favorite text editor.