Cookbook structure & dependencies

Berkshelf, metadata, versioning.

Intermediate12 min · lesson 7 of 12

A cookbook is the versioned unit you author, upload, and share. It has a standard layout — recipes/, templates/, files/, attributes/, resources/ (custom resources), and metadata.rb, which declares the cookbook’s name, version, and its dependencies on other cookbooks. Version and dependency metadata is what lets the server resolve exactly which cookbooks (and versions) a node should run.

metadata.rb

name 'web'
version '1.2.0'
depends 'nginx', '~> 11.0'
depends 'firewall', '>= 3.0'
supports 'ubuntu'

Dependency management

Cookbooks build on other cookbooks (a community nginx or firewall cookbook), and Berkshelf (or Policyfiles, later) resolves and fetches the dependency graph from a source like Chef Supermarket, the public cookbook registry. You pin versions so a converge is reproducible — the same discipline as any package manager, and doubly important because a cookbook runs as root during convergence.

terminal

$ berks install          # resolve + fetch dependencies from the Berksfile
$ berks upload           # upload the cookbook and its resolved deps to the server
$ knife cookbook list    # what versions the server now holds

A community cookbook runs as root on your nodes

Cookbooks pulled from Supermarket execute with full privilege during convergence, so an unpinned or unvetted community cookbook is a supply-chain risk like any dependency. Pin versions in metadata/Berksfile, review what a cookbook does (especially execute blocks and remote downloads) before depending on it, and prefer well-maintained sources. The pull model means these run everywhere, automatically.

Templates & filesNodes, run-lists & roles