Chef Cookbooks require you to specify a small amount of meta-data. This information is used to provide hints to the Chef Server as to what cookbooks should be deployed to a given node, and in the future it will be integral to an automated system for discovering and installing cookbooks.
To get started, you need to create a
We never interpret the metadata file directly, we only ever use the compiled JSON file! Currently, the metadata JSON is generated for you when you upload the cookbook or run the
At the moment, we utilize the following fields in the metadata:
The following fields are used by the Chef Server, WebUI, or Opscode Community Site.
The name of the cookbook. Normally this is inferred, but you can override it here.
The current version of this cookbook. Version numbers follow the simple three-number version scheme:
Adds a dependency on another cookbook, with version checking strings. This will require that you have a cookbook with the proper name, and a version number that matches.
Whenever you include a recipe in a cookbook via "
Version constraints are fully documented on their own page. The syntax is summarized here.
In the actual recipe, the "
A short description of this cookbooks function. Ideally a single line.
A longer description of this cookbook. Ideally contains full instructions on the proper use of this cookbook, descriptions of definitions it contains, libraries, etc. Often rendered from README.rdoc at the top of the cookbook.
This is the name of the current maintainer - it should be either an individual or an organization.
This is the email address of the current maintainer.
This is the license the cookbook is distributed under.
The following fields are optional. The information in these fields is not used by the Chef server.
Adds an attribute that a user may need to configure for this cookbook. Takes a name (with the / notation for a nested attribute), followed by any of these options:
Adds a displayable title and description to a group of attributes within a namespace. Takes a name (with the / notation for a nested grouping), followed by any of these options:
Warns that this cookbook conflicts with another cookbook.
Adds a recipe, definition, or resource provided by this cookbook. We auto-populate the list of provided recipes, so it would be rare to need to specify them directly.
Recipes are specified as expected:
Definitions are defined by using the name of the definition, followed by parenthesis, and a symbol-style list that matches the definitions parameters.
Individual resources are specified with the normal stringified resource syntax:
Adds a description for a recipe - used mainly for aesthetics in the UI.
Adds a dependency on another cookbook that is not required (ie: we'll work without it) but is a good idea.
This cookbook replaces another - it can be used entirely in the place of it.
Adds a supported platform, with version checking logic. To specify multiple platforms, simply provide this command multiple times, once for each platform.
If no version is provided, any version of the platform will match.
Currently, the platform matching and version checking logic is not implemented - Chef will happily run any cookbook on any platform, regardless of the data provided here.
Adds a suggestion for another cookbook. The difference between recommends and suggests is that, should a system be constructed for automatically resolving cookbook dependencies, recommended cookbooks will be included by default, and suggested ones will not.