The Master/Agent Architecture

How Chef and Puppet Actually Work

Think of the Master/Agent model like a franchise operation. The Master is corporate headquarters — it holds the official rulebook. The Agents are individual franchise locations — they periodically call headquarters to get their latest instructions and then implement them locally.

In technical terms:

1. The Master (Server): The central source of truth. It stores all configuration code (called Recipes in Chef, Manifests in Puppet), node-specific data (hostnames, passwords, environment variables), and compiled instructions for each node.
2. The Agent (Client): A software daemon installed and running on every managed server. It is responsible for contacting the Master, receiving instructions, and enforcing them locally.

The Pull Workflow

The default model is pull-based: agents initiate contact with the Master on a schedule.

Step 1 — Check-in: Every 30 minutes (by default), the Agent wakes up and contacts the Master: "I am web-01. What should my configuration look like?"

Step 2 — Catalog Compilation: The Master looks up web-01 in its node database, evaluates the relevant Recipes or Manifests, and compiles a Catalog — a concrete list of resources and their desired states specific to that node.

Step 3 — Enforcement (Convergence): The Agent compares the Catalog against the actual state of the local system:
- Is Nginx installed? Yes. → Do nothing.
- Is /etc/nginx/nginx.conf correct? No, someone edited it manually. → Overwrite it with the correct version.
- Is the nginx service running? No. → Start it.

Step 4 — Report: The Agent sends a report back to the Master: "I corrected 1 resource out of 47. Here is what changed."

This cycle repeats every 30 minutes indefinitely. Any manual change made to the server will be detected and reverted at the next check-in. This is the core value proposition: automatic drift correction.

Puppet DSL vs. Chef Ruby

The two tools differ in how you write configuration code:

Puppet uses a custom declarative DSL (Domain-Specific Language). You describe what you want, not how to get it:

# Puppet Manifest: ensure Nginx is installed and running
package { 'nginx':
  ensure => installed,
}

service { 'nginx':
  ensure  => running,
  enable  => true,
  require => Package['nginx'],
}

file { '/etc/nginx/nginx.conf':
  ensure  => file,
  content => template('nginx/nginx.conf.erb'),
  notify  => Service['nginx'],
}

Chef uses Ruby DSL — it looks more like a programming language, which gives more flexibility but also more rope to hang yourself with:

# Chef Recipe: ensure Nginx is installed and running
package 'nginx' do
  action :install
end

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

template '/etc/nginx/nginx.conf' do
  source 'nginx.conf.erb'
  notifies :restart, 'service[nginx]'
end

Both examples accomplish the same thing. The Puppet version is more readable for non-developers; the Chef version is more powerful for complex logic.

Key Point: The Master/Agent pull model provides continuous drift correction, which is its primary advantage over manual management. Its primary liability is operational complexity: the Master is a single point of failure, agents must be installed and kept updated across every managed node, and the 30-minute convergence window means changes are never instantaneous.