Nodes, run-lists & roles

What a node should become.

Intermediate12 min · lesson 8 of 12

A node is a machine the Chef server knows about, and its run-list is the ordered list of what it should become — recipes and roles to apply, in sequence, on every chef-client run. The run-list is the contract: change it and the node converges to the new definition on its next run. This is how you assign “this box is a web server” — you give it recipe[web] (and whatever else).

terminal

$ knife node run-list set web1 'role[base],recipe[web]'
$ knife node show web1
Node Name:   web1
Run List:    role[base], recipe[web]
Roles:       base
Recipes:     base::default, web::default

Roles group run-lists

A role bundles a run-list and attributes under a name, so instead of assigning ten recipes to fifty nodes you assign role[web]. Roles are the classic way to express node types (base, web, db), though modern Chef increasingly prefers Policyfiles (later) for stronger version pinning. Either way, the goal is the same: a node’s identity is declarative data on the server, not something you configure by hand on the box.

roles/web.rb

name 'web'
description 'Web server nodes'
run_list 'recipe[base]', 'recipe[nginx]', 'recipe[web]'
default_attributes('nginx' => { 'worker_processes' => 4 })

Run-list order matters — and changes converge automatically

Chef applies a run-list in order, so a dependency must come before what needs it (base hardening before the app). And because nodes pull on a schedule, editing a run-list or role changes what those nodes become on their next run without any push — powerful, but it means a bad change to a shared role propagates fleet-wide automatically. Review role/run-list changes accordingly.

Cookbook structure & dependenciesData bags & encrypted secrets