For the second quarter in a row we’ve launched a Chef certification course, this latest time we launched Extending Chef Badge. If you’re on the hunt for Chef related certifications, then this Extending Chef Badge course is something that you’ll obviously want to look into. But what if you simply want to expand your knowledge of Chef? What will you learn? How can Chef be extended?
Avenues for Extending Chef
For the Extending Chef Badge, you’ll need to know how to get the most out of Chef by adding and/or customize functionality in these areas:
- Custom Resources
- Chef Server API
As you’ve been using Chef, you’ve undoubtedly interacted with most of these aspects at one time or another without knowing that you can customize or add features to them. Let’s take a look at what each of these aspects of Chef is responsible for.
Ohai is the data collection library that executes early in a Chef client run, and it populates the node’s “automatic” attributes. Every time you’ve ever interacted with
node['platform_family'], you’ve been accessing a value that is populated by Ohai. There’s a limitless number of things that can be done to a node, and occasionally we’ll want to provide more information as part of the node’s automatic attributes. In this situation, we’d want to write an Ohai plugin. Once loaded, our Ohai plugin could collect data about a specific application or files on the system, and provide it as an attribute on the
node in the Chef client run.
Chef does a wonderful job of allowing us to codify our ideas and ensure that we can have confidence in our infrastructure. But while the Chef client is running, it can seem like a black box. Visibility is very powerful, and can allow us to react to situations as they arise. Is there a way to run code when certain events happen during a Chef client run? Yes, and that’s where Chef handlers come into play. By writing and deploying custom handlers, you can run custom Ruby code when an error occurs (like something that sends a Slack notification if there is a problem) or send some custom instrumentation data to a remote server when a resource gets skipped.
Custom Resources, Libraries, and Definitions
Recipes are where the magic happens in the world of Chef, but sometimes they can get messy. One of the best and easiest ways to keep our recipes healthy is to remove clutter, and to keep from repeating ourselves. Chef provides us with the ability to create custom resources (and definitions) to encapsulate resource related logic, and custom libraries to handle pure Ruby logic (which extends Chef’s own classes). As you’ve used Chef, you’ve likely felt the pain of a messy recipe and maybe discovered the benefits of libraries and custom resources on your own.
As someone working with Chef, you’ve probably come to love Knife. It’s a wonderful tool for interacting with the Chef Server’s information, and orchestrating actions on your infrastructure. But did you know that you can create your own subcommands? Custom Knife plugins allow you to add functionality to Knife, while already having access to Chef Server authentication. This way you can focus entirely on what you’d like to be able to do with the information from your server.
The Chef Server API
The Chef Server is at the core of the Chef workflow, and holds onto a lot of important information regarding your infrastructure. But can you use it outside of a cookbook? You bet you can. And to make it even better, you can use it from any language! The Chef Server API is what Knife uses when you run any of the commands that fetch, create, or modify data in the Chef Server. You can imagine the sorts of things that you could do with this flexible API.
Level Up Your Chef Skills
If any of these features sound like they would be useful to you, or if you’re simply looking for a challenge that will help you level up your skills, then I encourage you to dive into our new Extending Chef Badge course.