Developing cookbooks and making sure your nodes converge to the desired state is a complex endeavor. You need transparency about what is really happening. This chapter will cover a lot of ways to see what's going on and make sure that everything is working as it should. From running basic checks on your cookbooks to a fully test driven development approach, we'll see what the Chef ecosystem has to offer.

You know how annoying this is: you tweak a cookbook, upload it to your Chef server, start a Chef run on your node and, boom! It fails. What's even more annoying is that it fails not because a black hole absorbed your node and the whole data center that node lives in, but because you missed a mundane comma in the default recipe of the cookbook you just tweaked. Fortunately, there's a very quick and easy way to find such simple glitches before you go all in and try to run your cookbooks on real nodes.

mma@laptop:~/chef-repo $ knife cookbook site install ntp

Installing ntp to /Users/mma/work/chef-repo/cookbooks
…TRUNCATED OUTPUT…
Cookbook ntp version 1.7.0 successfully installed

Writing solid Chef recipes can be quite challenging. There are a couple of pitfalls, which you can easily overlook. Also, writing cookbooks in a consistent style is even harder. You might wonder what the proven ways to write cookbooks are. Foodcritic tries to identify possible issues with the logic and style of your cookbooks.

In this section, you'll learn how to use Foodcritic on some existing cookbooks.

mma@laptop:~/chef-repo $ knife cookbook site install mysql 6.0.0

Installing mysql to /Users/mma/work/chef-repo/cookbooks
…TRUNCATED OUTPUT…
Cookbook mysql version 6.0.0 successfully installed

Test-driven development (TDD) is a way to write unit tests before writing any recipe code. By writing the test first, you design what your recipe should do and ensure that your test is for real because it should fail, as long as you haven't written your recipe code.

As soon as you've completed your recipe, your unit tests should pass.

ChefSpec is built on the popular RSpec framework and offers a tailored syntax to test Chef recipes.

Let's develop a very simple recipe using the TDD approach with ChefSpec.

Verifying that your cookbooks really work when converging a node is essential. Only if you can trust your cookbooks, you are ready to run them anytime on your production servers.

Test Kitchen is Chef's integration testing framework. It enables you to write tests, which run after a VM is instantiated and converged, using your cookbook. Your tests run in that VM and can verify that everything works as expected.

This is in contrast to ChefSpec, which only simulates a Chef run. Test Kitchen boots up a real node and runs Chef on it. Your tests see the real thing.

Let's see how you can write such integration tests for your cookbooks.

You know how it goes. You tweak a cookbook to support your new server and upload it to your Chef server. Your new node converges just fine and you're happy. Well, until your older production server picks up your modified cookbook during an automated Chef client run and spits its guts at you. Obviously, you forgot that your old production server was still using the cookbook you tweaked. Luckily, there is the knife preflight command, which can show you all the nodes using a certain cookbook before you upload it to your Chef server.

mma@laptop:~/chef-repo $ chef gem install knife-preflight

Fetching gem metadata from https://rubygems.org/
...TRUNCATED OUTPUT...
Installing knife-preflight...

We all have those snowflake environments that are built using Chef, but we're not comfortable with running the Chef client anymore. We know that some cookbooks have been enhanced but never tested against this specific environment. The risk of bringing it down by a Chef client run is pretty high.

However, even though we do not dare do a full Chef client run, we might need to run, for example, the users cookbook, in order to add a new colleague to our snowflake environment. This is where Chef client's feature to override a run list to execute a single recipe comes in very handy.

why-run mode lets each resource tell you what it would do during a Chef client run, assuming certain prerequisites. This is great because it gives you a glimpse about what might really happen on your node when you run your recipe for real.

However, because Chef converges a lot of resources to a desired state, why-run will never be accurate for a complete run. Nevertheless, it might help you during development while you're adding resources step-by-step to build the final recipe.

In this section, we'll try out why-run mode to see what it tells us about our Chef client runs.