Customizing Chef

Chapter 3. Chef Internals

In Chapter 1, we examined why we might want to customize our Chef setup. Before we can dive into the meat of the book and start actually creating our own Chef customizations, it’s important to ensure that we are able to make an informed decision about what to customize. Chef is designed to be extensible in a wide variety of ways, each suited to different types of tasks.

One of the most powerful tools in your toolbox to help you make this sort of decision is a comprehensive understanding of how Chef works under the hood and how the different components interact. To use an analogy from AwesomeInc’s line of work, before we can customize a particular component of a car we need to have an overall picture of how the car functions, and the effects that a change to one component will have on other components.

In this chapter, we’ll look at:

• An overview of the architecture behind a Chef server—we won’t be customizing the Chef server in this book, but it’s useful to be aware of its components and structure nonetheless.
• The anatomy of a Chef run.
• How Chef’s design methodology allows us to examine what a run would do to a node if executed.
• A quick tour of Chef’s source code to become familiar you with how the classes that make up Chef are organized.
• Tracing the execution path of a chef-client run through the Chef codebase, using our Ruby knowledge from Chapter 2.

Tip

The material in this chapter is based on (and compatible with) the latest stable release of Chef at ...