Chef

Table Of Contents

chef-solo

Warning

The chef-client now includes an option called local mode (--local-mode or -z), which runs the chef-client against the chef-repo on the local machine as if it were running against a Chef server. Local mode was added to the chef-client in the 11.8 release. If you are running that version of the chef-client (or later), you should consider using local mode instead of using chef-solo.

chef-solo is an open source version of the chef-client that allows using cookbooks with nodes without requiring access to a Chef server. chef-solo runs locally and requires that a cookbook (and any of its dependencies) be on the same physical disk as the node. chef-solo is a limited-functionality version of the chef-client and does not support the following:

  • Node data storage
  • Search indexes
  • Centralized distribution of cookbooks
  • A centralized API that interacts with and integrates infrastructure components
  • Authentication or authorization
  • Persistent attributes

Note

chef-solo can be run as a daemon.

Note

chef-solo is configured using the chef-solo (executable).

Cookbooks

chef-solo supports two locations from which cookbooks can be run:

  • A local directory.
  • A URL at which a tar.gz archive is located.

Using a tar.gz archive is the more common approach, but requires that cookbooks be added to an archive. For example:

$ tar zcvf chef-solo.tar.gz ./cookbooks

If multiple cookbook directories are being used, chef-solo expects the tar.gz archive to have a directory structure similar to the following:

cookbooks/
  |---- cbname1/
    |--attributes/ ... etc
  ...
  |---- cbname2/
    |--attributes/

The cookbook_path variable in the solo.rb file must include both directories. For example:

$ tar zcvf chef-solo.tar.gz ./cookbooks ./site-cookbooks

When the tar.gz archive contains all of the cookbooks required by chef-solo, upload it to the web server from which chef-solo will access the archive.

Attributes

chef-solo does not interact with the Chef server. Consequently, node-specific attributes must be located in a JSON file on the target system, a remote location (such as Amazon S3), or a web server on the local network.

The JSON file must also specify the recipes that are part of the run-list. For example:

{
  "resolver": {
    "nameservers": [ "10.0.0.1" ],
    "search":"int.example.com"
  },
  "run_list": [ "recipe[resolver]" ]
}

Data Bags

A data bag is defined using JSON. chef-solo will look for data bags in /var/chef/data_bags, but this location can be modified by changing the setting in solo.rb For example, the following setting in solo.rb:

data_bag_path "/var/chef-solo/data_bags"

Create a data bag by creating folders. For example:

mkdir /var/chef-solo/data_bags

and:

mkdir /var/chef-solo/data_bags/admins

and then create a JSON file in that location:

{
  "id": "ITEM_NAME"
}

where the name of the file is the ITEM_NAME, for example:

/var/chef-solo/data_bags/admins/ITEM_NAME.json

Roles

A role is defined using JSON or the Ruby DSL. chef-solo will look for roles in /var/chef/roles, but this location can be modified by changing the setting for role_path in solo.rb. For example, the following setting in solo.rb:

role_path "/var/chef-solo/roles"

Role data looks like the following in JSON:

{
  "name": "test",
  "default_attributes": { },
  "override_attributes": { },
  "json_class": "Chef::Role",
  "description": "This is just a test role, no big deal.",
  "chef_type": "role",
  "run_list": [ "recipe[test]" ]
}

and like the following in the Ruby DSL:

name 'test'
description 'This is just a test role, no big deal.'
run_list 'recipe[test]'

and finally, JSON data passed to chef-solo:

{ "run_list": "role[test]" }

Environments

An environment is defined using JSON or the Ruby DSL. chef-solo will look for environments in /var/chef/environments, but this location can be modified by changing the setting for environment_path in solo.rb. For example, the following setting in solo.rb:

environment_path "/var/chef-solo/environments"

Environment data looks like the following in JSON:

{
  "name": "dev",
  "default_attributes": {
    "apache2": {
      "listen_ports": [
        "80",
        "443"
      ]
    }
  },
  "json_class": "Chef::Environment",
    "description": "",
    "cookbook_versions": {
    "couchdb": "= 11.0.0"
  },
  "chef_type": "environment"
  }

and like the following in the Ruby DSL:

name "environment_name"
description "environment_description"
cookbook OR cookbook_versions  "cookbook" OR "cookbook" => "cookbook_version"
default_attributes "node" => { "attribute" => [ "value", "value", "etc." ] }
override_attributes "node" => { "attribute" => [ "value", "value", "etc." ] }

chef-solo (executable)

The chef-solo executable is run as a command-line tool.

Options

This command has the following syntax:

chef-solo OPTION VALUE OPTION VALUE ...

This command has the following options:

-c CONFIG, --config CONFIG
The configuration file to use.
-d, --daemonize
Use to run the executable as a daemon. This option is only available on machines that run in UNIX or Linux environments. For machines that are running Microsoft Windows that require similar functionality, use the chef-client::service recipe in the chef-client cookbook: http://community.opscode.com/cookbooks/chef-client. This will install a chef-client service under Microsoft Windows using the Windows Service Wrapper.
-E ENVIRONMENT_NAME, --environment ENVIRONMENT_NAME
The name of the environment.
-f, --[no-]fork
Use to contain the chef-client run in a secondary process with dedicated RAM. When the chef-client run is complete the RAM will be returned to the master process. This option helps ensure that a chef-client will use a steady amount of RAM over time because the master process will not run recipes. This option will also help prevent memory leaks (such as those that can be introduced by the code contained within a poorly designed cookbook). Use --no-fork to disable running the chef-client in fork node. Default value: --fork.
-F FORMAT, --format FORMAT

The output format: doc (default) or min.

Use doc to print the progress of the chef-client run using full strings that display a summary of updates as they occur.

Use min to print the progress of the chef-client run using single characters. A summary of updates is printed at the end of the chef-client run. A dot (.) is printed for events that do not have meaningful status information, such as loading a file or synchronizing a cookbook. For resources, a dot (.) is printed when the resource is up to date, an S is printed when the resource is skipped by not_if or only_if, and a U is printed when the resource is updated.

Other formatting options are available when those formatters are configured in the client.rb file using the add_formatter option.

--force-formatter
Use to show formatter output instead of logger output.
--force-logger
Use to show logger output instead of formatter output.
-g GROUP, --group GROUP
The name of the group that owns a process. This is required when starting any executable as a daemon.
-h, --help
Shows help for the command.
-i SECONDS, --interval SECONDS
The frequency (in seconds) at which the chef-client runs.
-j PATH, --json-attributes PATH
The path to a file that contains JSON data. Use this option to override normal attributes set elsewhere.
-l LEVEL, --log_level LEVEL
The level of logging that will be stored in a log file.
-L LOGLOCATION, --logfile c
The location in which log file output files will be saved. If this location is set to something other than STDOUT, standard output logging will still be performed (otherwise there would be no output other than to a file). This is recommended when starting any executable as a daemon.
--[no-]color
Use to view colored output. Default setting: --color.
-N NODE_NAME, --node-name NODE_NAME
The name of the node.
-o RUN_LIST_ITEM, --override-runlist RUN_LIST_ITEM
Replace the current run list with the specified items.
-r RECIPE_URL, --recipe-url RECIPE_URL
The URL location from which a remote cookbook tar.gz will be downloaded.
-s SECONDS, --splay SECONDS
A number (in seconds) to add to the interval that is used to determine the frequency of chef-client runs. This number can help prevent server load when there are many clients running at the same time.
-u USER, --user USER
The user that owns a process. This is required when starting any executable as a daemon.
-v, --version
The version of the chef-client.
-W, --why-run
Use to run the executable in why-run mode, which is a type of chef-client run that does everything except modify the system. Use why-run mode to understand why the chef-client makes the decisions that it makes and to learn more about the current and proposed state of the system.

Examples

Run chef-solo using solo.rb settings

$ chef-solo -c ~/chef/solo.rb

Use a URL

$ chef-solo -c ~/solo.rb -j ~/node.json -r http://www.example.com/chef-solo.tar.gz

The tar.gz archived into the file_cache_path, and then extracted to cookbooks_path.

Use a directory

$ chef-solo -c ~/solo.rb -j ~/node.json

chef-solo will look in the solo.rb file to determine the directory in which cookbooks are located.

Use a URL for cookbook and JSON data

$ chef-solo -c ~/solo.rb -j http://www.example.com/node.json -r http://www.example.com/chef-solo.tar.gz