An Introduction to Chef

Q: Does Chef require a central server?

No. Chef Infra Client supports local mode with --local-mode, so you can apply locally available recipes and cookbooks without deploying Chef Infra Server. You still need to supply the configuration and its dependencies.

Sam Erickson
Updated 20 hours ago
0

Key Takeaways

Chef Infra manages system configuration as code using Ruby-based recipes and resources that describe desired state.
Recipes belong to cookbooks; Chef Infra Client evaluates them and converges a node toward the declared configuration.
Server-based workflows distribute cookbooks and policy through Chef Infra Server, but Chef Infra Client can also run locally without a central server.
Policyfiles lock a cookbook set for controlled rollout. Test changes before applying them across your fleet.

Chef configuration management turns repeatable system setup into reusable code. You describe how packages, files, and services should be configured, and Chef Infra Client applies the changes needed to reach that state. This is Infrastructure as Code (IaC): configuration you can review, test, and maintain rather than repeat manually.

What Is Chef?

Chef is a product family. For configuration management, the important names are Chef Infra Client, which applies configuration, and Chef Infra Server, which centrally stores and distributes cookbooks and policy in server-based operation. Chef Workstation supplies the development and administration tools.

A Chef recipe uses a Ruby-based domain-specific language, or DSL: Ruby syntax with configuration-specific building blocks. Those building blocks are resources, such as package, service, and template. A resource declares the configuration you want; its implementation handles the work needed to produce it, including platform-specific behavior.

That distinction matters. A shell script might say “run this installation command.” A Chef resource says “this package must be installed.” Chef checks the relevant state instead of treating every run as a fresh installation.

The Problem Chef Solves

Imagine configuring a group of web servers manually: install Apache, enable its service, copy configuration files, and repeat. Later, someone changes a setting on one machine. Your setup instructions may still be correct, but the machines no longer match.

That mismatch is configuration drift. Chef lets you reuse the same configuration across nodes and reapply it on subsequent client runs. If a managed service has stopped or a managed file differs from its declared content, the corresponding resource can restore the intended state. Chef only manages what your resources describe, and correction happens when a client run executes—not continuously between runs.

The trade-off is that configuration code becomes software you must maintain. Put it under version control, review changes using a shared Git workflow, and test it against the operating systems you actually run. Centralizing a bad configuration makes it easier to distribute, too.

The Main Chef Components

Workstation

Your workstation is where you author and test configuration. Chef Workstation includes the chef command for development workflows and knife for interacting with Chef Infra Server objects, including nodes and cookbooks.

Recipe

A recipe groups related resources into a configuration, such as installing a web server and enabling its service. Recipes are Ruby code, but resource declarations—not arbitrary shell commands—should do most of the configuration work.

Cookbook

A cookbook packages recipes with supporting material: attributes, files, templates, custom resources, and metadata. Its metadata.rb file describes the cookbook and its dependencies. A cookbook is therefore more than a folder of installation scripts.

Node, Attributes, and Ohai

A node is a managed system, such as a physical server or virtual machine. Attributes supply configuration values and system facts. Ohai collects facts such as operating-system and network information during a client run; recipes can access facts such as node['platform'].

Chef Infra Client

In the traditional agent-based workflow, Chef Infra Client runs on each node, evaluates recipes, and applies resource actions locally. Chef also supports an agentless mode for supported remote resources, but the workflow explained here uses the node-side agent.

Chef Infra Server

Chef Infra Server stores cookbooks, policy, and node metadata. The client authenticates, retrieves its assigned configuration and required cookbook files, and performs the configuration work on the node. The server is a distribution and coordination service, not the process that installs packages on every machine.

Reporting Is a Separate Concern

Chef Automate can display client-run history and compliance results. Those reporting capabilities are separate from Chef Infra Server’s cookbook, policy, and node data; a central configuration server is not automatically a deployment-analytics system.

How Chef Configuration Management Works

The standard server-based lifecycle connects development, distribution, and execution. Uploading code alone does not configure a node: the node needs an assigned policy or run list, and Chef Infra Client must execute it.

Workstation: author cookbook -> test -> lock policy
                                      |
                                      | upload cookbooks and policy
                                      v
                                Chef Infra Server
                                      ^
                                      | client retrieves assigned configuration
                                      |
                              Chef Infra Client on node
                                      |
                                      v
                            Converge packages, files, services

Author: Write recipes and package them in a cookbook.
Test: Check the cookbook before distributing it.
Publish: Upload the cookbook set and policy to Chef Infra Server.
Assign: Associate the node with a policy or configure its run list—the ordered recipes and, in traditional workflows, roles it should apply.
Converge: Run Chef Infra Client. It gathers facts, authenticates, synchronizes required cookbooks, builds a resource collection, and applies resource actions.
Repeat: Subsequent runs reevaluate managed configuration. After a successful server-based run, the client updates the server’s node object.

Policyfiles and Traditional Roles and Environments

A Policyfile describes a policy’s recipes, cookbooks, and attributes. Resolving it produces Policyfile.lock.json, which records the selected cookbook revisions. A policy group lets you associate nodes with a published policy revision and promote a tested configuration through rollout stages.

Existing installations may instead use node run lists, roles, and environments. Roles group configuration by function; environments can supply attributes and constrain cookbook versions. Policyfiles provide an alternative policy workflow, so don’t assume every Chef deployment uses environments—or that changing an environment is the same as promoting a locked policy.

A First Chef Recipe: Install and Start Apache

Use a disposable Ubuntu VM with systemd, working package repositories, and no conflicting web server. Install and configure Chef Workstation first, including licensing for your user and the privileged client run. Then generate a cookbook:

mkdir -p chef-intro/cookbooks
cd chef-intro
chef generate cookbook cookbooks/web_baseline

Replace cookbooks/web_baseline/recipes/default.rb with this complete recipe:

# cookbooks/web_baseline/recipes/default.rb
package 'apache2' do
  action :install
end

service 'apache2' do
  action [:enable, :start]
end

The package resource ensures Apache is installed. The service actions enable it at boot and start it. Package and service names depend on the operating system; this example targets Ubuntu rather than claiming to work unchanged everywhere.

From the chef-intro directory, run the cookbook locally:

sudo chef-client --local-mode --runlist 'recipe[web_baseline::default]'

--local-mode runs against local configuration rather than a separately deployed Chef Infra Server. Here, --runlist selects the cookbook’s default recipe. This command changes the VM; it is not a preview.

Idempotence and Convergence

Convergence is the process of bringing actual configuration toward desired configuration. Idempotence means that applying the same configuration again does not keep introducing changes once the desired state is satisfied. For these resources, a later run should not reinstall an already-installed package or restart an already-running service merely because the recipe ran again.

Chef does not make arbitrary commands idempotent. An execute resource needs an appropriate state check, such as not_if, only_if, or creates, when repeating its command would be incorrect. Prefer a purpose-built resource when one exists.

Applying the Cookbook Through an Existing Server

For an existing server-based installation, create Policyfile.rb in chef-intro:

name 'web_baseline'
run_list 'web_baseline::default'
cookbook 'web_baseline', path: './cookbooks/web_baseline'

This declares a policy using the local cookbook. The Policyfile reference documents the name, run_list, and cookbook settings.

The following assumes your workstation has authenticated server access and a registered test node named test-node already has Chef Infra Client and server connectivity configured:

# On the workstation, inside chef-intro:
chef install Policyfile.rb
chef push staging Policyfile.rb
knife node policy set test-node staging web_baseline

# On test-node:
sudo chef-client

chef install generates the lock file; chef push uploads the locked policy and cookbooks to the staging policy group. knife node policy set assigns the node’s policy group and policy name. The final command applies that configuration on the node.

Testing and Safe Rollout

Lint: Cookstyle checks Ruby and Chef cookbook code for style and correctness issues.
Unit-test: ChefSpec tests recipes in a simulated client run. It complements, rather than replaces, tests on real systems. The same unit-testing principles apply to infrastructure code.
Integration-test: Test Kitchen provisions test instances and converges cookbooks; InSpec checks can verify the resulting system. Test the operating-system and client combinations you intend to deploy.
Stage changes: Review both cookbook changes and the policy lock, test on a small group, and promote the same tested revision.
Protect access: Keep private keys and secrets out of cookbook source, and preserve certificate verification when connecting to the server.

Finally, don’t confuse repeatable configuration with automatic rollback. Define how you will recover from a failed change, especially when recipes touch application data or perform one-way migrations.

FAQ

What is Chef configuration management?

Chef configuration management uses Ruby-based recipes and resources to define desired system configuration. Chef Infra Client evaluates that code and applies changes to managed packages, files, services, and other resources.

What is the difference between a Chef recipe and a cookbook?

A recipe groups resources that configure part of a system. A cookbook packages recipes together with supporting files, templates, attributes, and dependency metadata.

What do Chef Infra Client and Chef Infra Server do?

Chef Infra Server centrally stores cookbooks, policy, and node metadata. In an agent-based server workflow, Chef Infra Client retrieves the assigned configuration and applies it on the node.

Does Chef require a central server?

No. Chef Infra Client supports local mode with --local-mode, so you can apply locally available recipes and cookbooks without deploying Chef Infra Server. You still need to supply the configuration and its dependencies.

How does Chef make configuration changes idempotent?

State-aware resources check whether their desired configuration is already satisfied before changing it. Arbitrary commands are not automatically idempotent; use suitable guards or a purpose-built resource to prevent unwanted repeated changes.