Chef is an automation and configuration management tool that provides Infrastructure-as-Code (IaC). It can handle very complex hybrid on-premises/multi-cloud environments. For instance, your environment could have a front end in Amazon Web Services (AWS), a disaster recovery (DR) front end in Azure, and a back end in your on-premises datacenter.

Asser Hassan

Asser Hassan is a Vancouver-based DevOps engineer with more than 12 years experience in IT. He is a *nix expert, CLI enthusiast, virtualization and cloud professional (focus on AWS & Azure) and works as a cloud consultant.

Latest posts by Asser Hassan (see all)

Chef enables you to handle the configuration, deployment, and management of all components. Chef is used to manage huge environments in companies such as Airbnb, Expedia, and Facebook.

Overview of the Chef Components ^

As shown in the figure below, the Chef architecture is fairly simple:

Chef architecture

Chef architecture 

Chef Node ^

A Chef node is any machine (physical, virtual, or cloud-based) that is managed by Chef.

Chef Client ^

A Chef client is a local agent on the Chef node that authenticates to the Chef server, pulls updated configuration, and takes the required actions to configure the node by interfacing with the local operating system.

Chef Server ^

A Chef server is the central source for data. Nodes connect to a Chef server with every run of the Chef client in order to obtain the most recent changes to applicable cookbooks, recipes, files, attributes, roles, and environments.

Chef Workstation ^

A Chef workstation is any computer (Windows or Linux) configured to authenticate with a Chef server. It synchronizes the Chef repositories (typically using git), configures and manages organizational structures (roles, environments), and authors and deploys cookbooks, recipes, attributes, files, and templates.

As a DevOps engineer, the workstation is where you’ll perform most of your Chef-related activities, such as:

  • Write cookbooks and recipes.
  • Configure your organizational policies, organize your nodes into roles and environments, and centralize important data in data bags.
  • Bootstrap or decommission nodes as needed.
  • Keep your Chef repo synchronized with your version control (e.g., git)
  • Use command-line tools, such as knife, to administer your environments.

Cookbooks ^

A cookbook is a grouping of configuration elements, such as recipes, files, attributes, and metadata, required to implement a certain scenario (e.g., a cookbook to install the Apache web server, update its document root, and create a virtual host on a custom port).


Following the culinary metaphor, a recipe is a Ruby program that defines the resource name and attributes.


An attribute can be defined in a cookbook, a role, or an environment. It can also be used to set the value for a configuration variable for any given package or application. The attribute in the next example sets the default port of the Apache web server to 80.


Cookbooks can distribute files by node, platform, or file version.

As seen in this example, this creates a home page for a web server from the source file, index.html, within a cookbook files subdirectory.

Roles ^

A role is the definition of certain run-lists (cookbooks/recipes) and attributes that are associated with a certain node type.

For example, a database node will require a MySQL recipe to install a MySQL package, along with associated attributes. A web server node will require an Apache or Nginx recipe, and so on.

The example below defines a role called web, specifies a user’s attribute (webadmin), and defines the run-list to include the Apache recipe.

Environments ^

An environment is a representation of an organizational policy and a grouping of nodes in the same workflow (e.g., testing, staging, or production environments). It contains default and override attributes that can override a cookbook or role attributes in order to enforce a rule.

For example, your web server may be lax on security, but if your environment override attributes are set, they will supersede the role and cookbook settings.

The example below is a definition of a production environment that will override the secuirty_groups attribute for Linux systems, change it to ‘restricted’, and override the allowed port value to port 80 only.

How it works

The basic workflow is as follows:

  1. A DevOps engineer creates a cookbook with a knife command from the Chef workstation.
  2. A new cookbook is synchronized with a repository.
  3. A Chef client runs on a given Chef node.
  4. A Chef client authenticates to a Chef server and pulls any changes (cookbooks, recipes, files, roles, environments, etc.).
  5. A Chef client expands the run-list and checks for any changes in the run-list cookbooks/recipes. The expanded run-list includes all of the recipes defined for the cookbooks, roles, or environments associated with the node.
  6. The node attributes are reset and rebuilt.
  7. Similarly, attributes are collated from the cookbooks, roles, and environments.
  8. A Chef client compiles the resources that need to be updated/rebuilt.
  9. A Chef client takes the actions in the cookbooks/recipes/attributes, thereby effectively building or changing a node configuration.
  10. A Chef client then stops and waits for the next run.

Chef workflow

Chef workflow

In a follow-up post I will explain how to create your first Chef server, environment, role, cookbook, and recipe—so you can bootstrap your first node.

Win the monthly 4sysops member prize for IT pros


Related Posts


Leave a reply

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



Please ask IT administration questions in the forum. Any other messages are welcome.

© 4sysops 2006 - 2018

Log in with your credentials


Forgot your details?

Create Account