A small introduction to Chef

Chef Logo

If you know what Chef is, you may skip this one or actually stay for a (hopefully) interesting read. Either way, Chef is a tool that one may use for automating the node configurations – e.g. installed software, their configuration files, system configuration files, NFS mounts and so on.

When interacting with chef, one may realize that there are 3 main components involved:

  • The Chef Server, which is actually just a big data repository.
  • The Chef Client, which is installed and runs on endpoints and does all the “dirty work” such as changing files and installing packages. The client authenticates itself to the server by a public/private key mechanism.
  • The Knife: this is the tool used by the sysadmins to actually do work with Chef.

What is stored in the repository known as Chef Server?

  • Cookbooks;
  • Data Bags;
  • Environment and Node data.

A Cookbook is a small project written in Ruby. This project contains files for:

  • Recipes – these are individual files that contain rules to be aplied on clients (e.g. install a rpm package, deploy a config file from a template). The file contents is plain Ruby code using constructs (calls to libraries) provided by Chef.
  • Attributes – or, better phrased, default attributes (e.g. port numbers, sizes, paths etc).
  • Templates – templatized configuration files with attributes replaced with template variables that are to be initialized in the recipe from default or user provided values.

These small projects are versioned and usually are also maintained – for development purposes – in an external repository (most likely git based). There is a system of includes and dependencies; starting some recipe installation will maybe trigger the installation of a full environment.

The “data bag” is an interesting concept: these are json data pieces stored inside the Chef Server. They can be encrypted, making them suitable for sensitive data such as passwords or private keys.

What is a (Chef) Environment? One may see it as a form of grouping nodes (servers). This allows for having shared, common data for all the nodes within a certain environment and also for running commands to groups of nodes identified by the environment they belong to. The (Chef) Node also has a data record associated with it that may override the inherited settings from the environment. Such data record (also json encoded) contains overrides for the default attributes described before and, on individual nodes, the recipe list to be applied (also called the “run list”).

As I have mentioned before, the effective work is performed with knife. The entire documentation is available on the Chef website:

From a DevOps perspective, the most frequent operations are:

  • Modifying environment and node data;
  • Uploading and downloading cookbooks without dependency checking; for dependencies there is another tool, berks;
  • Running the same shell command on a group of nodes (query based).

Is it a fun tool? It sure is. But you know the saying, “don’t drink and drive”; in this context, due to the impact of individual commands, one must be extra careful (and most likely sober).

That’s it for a small introduction on Chef concepts. Thank you for the read and have a nice day!

2 thoughts on “A small introduction to Chef

  1. Pingback: What is DevOps?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.