What Chef is & the pull model

Client/server, agent-based convergence.

Chef is a configuration-management platform that describes infrastructure as code in a Ruby DSL and enforces it with an agent. Its defining architecture is the pull model: every managed node runs a chef-client agent that, on a schedule, contacts a central Chef Infra Server, downloads the cookbooks and data assigned to it, and converges the machine to the declared state. Nodes maintain themselves continuously rather than waiting for someone to push.

This is the opposite of Ansible’s agentless push. The trade-offs mirror that: Chef’s agent means every node keeps itself converged without a control node reaching out, which scales to very large, long-lived fleets and survives network partitions gracefully — at the cost of installing and running an agent everywhere, and operating a Chef server. Chef suits big, stable estates that value continuous self-correction; the pull model is the thing to understand first.

Cookbooks and recipes

The unit of Chef code is the cookbook — a versioned bundle of recipes, templates, files, and attributes. A recipe is a Ruby file that declares resources (a package to install, a service to run, a file to manage). Because recipes are real Ruby, you have loops, conditionals, and logic when you need them — powerful, but a double-edged sword, since a recipe can do more than declare state if you let it.