The Chef configuration and infrastructure management tool is gaining popularity in DevOps organizations that run workloads on private infrastructures and public clouds.
Chef automates how an IT team builds, deploys and manages infrastructure. Administrators no longer create a wide range of scripts in diverse languages and, instead, standardize on Chef as their common deployment framework. This allows a DevOps team to set configurations in a fast and highly standardized manner.
Primary Chef components
The basic Chef components for configuration management comprise a Chef server, a Chef workstation and the managed nodes. These components work on company-owned servers or private and public clouds.
On the workstation, an administrator creates configurations -- called cooking in Chef jargon -- via the knife command-line interface or the Chef web interface. These Chef components and configurations define the work to be done.
The Chef server stores all the parts of the Chef configuration, including the roles, recipes and configuration data, in a repository referred to as a cookbook. The cookbook defines a configuration and its distribution. Recipes contain a list of the resources to use and the order in which to provision them. The Chef server acts as the central point of contact for Chef clients.
The nodes communicate to the Chef server using an HTTP or HTTPS connection. Chef nodes use a chef-client script to download a run list containing the work required for that specific node. This list includes cookbooks, as well, which hold the recipes to be executed for the node's configuration.
Chef cookbooks and recipes
The cookbook is a Chef component that defines the desired state of its managed nodes. A Chef cookbook stores recipes to execute on nodes, along with all the required files and configuration templates to run the recipes. Recipes are written in the Chef domain-specific language, which is built on top of Ruby.
Resources are important additions to Chef components, such as the cookbook. Resources do the actual work of configuration: They compare the code in the recipe with the current state of the system and make all the changes to bring the system to its desired state.
Options to deploy Chef components
A common Chef setup uses a single central Chef server, but there are alternatives off premises. Consider a hosted Chef environment, run by the vendor Chef Software. Another option is to boot up an image from a cloud provider marketplace. Chef integrates well with cloud platforms such as Microsoft Azure and Amazon Web Services.
Chef has licensing options in the cloud for enterprises that choose this route. While deploying Chef in Azure, for example, there is a choice between the Chef Server BYOL -- which stands for bring your own license -- and Azure Chef cloud instances with licenses already included.
Chef has a learning curve, but it doesn't have to be impossible to get started. A complete environment consists of a server, the managed machines and the user workstation. Chef can even be set up and run on just one machine with the Development Kit -- and a little patience.
Users must bootstrap Chef clients by installing an agent. Chef supports many client platforms, including Windows, Mac OS X, all of the common Linux distributions and even some UNIX distros, such as AIX and Solaris.
Again, Chef client choices are dependent on the chosen deployment model. Full integration in Microsoft Azure Cloud is limited to Windows and Linux platforms, for example, and excludes UNIX and Mac OSes.
Evaluate configuration management factors such as existing tools and organizational needs
Decide whether to use open source technology
Determine the best fit among popular configuration management tools