API Service

The API service is what clients use to interact with the server to manage node configuration in Chef. By default, the service is started on port 4000 as a Merb application slice running with the thin server adapter.

The two methods of interaction with the API for humans are the command-line tool Knife and the Management Console. The Chef Client library is used for interacting with the API for client nodes.

Management Console

The Management Console is an optional component that provides a nice way for humans to work with the Chef Server. By default, the service is started on port 4040 also as a Merb application slice running with thin. The Management Console has Users that represent human logins and use password-based authentication. Optionally, OpenIDs can be associated with Management Console users.

The Management Console itself is an API client, and the private key is located in /etc/chef/webui.pem, and the default name is chef-webui. Within the Management Console are users and the default Management Console user is admin with password p@ssw0rd1. When using the RubyGems bootstrap cookbook, the password is randomly generated by Chef, or can be specified by a JSON attribute.

AMQP Server

*rabbitmq-server package name varies by distribution.

The Chef Server runs RabbitMQ as an AMQP server. Whenever data is stored in CouchDB that needs to be indexed by SOLR, the server sends a message and the data payload to the queue, and the indexer picks it up.

Search Indexes

The search indexer, chef-solr-indexer listens to AMQP for messages about what to index, and then passes the results to chef-solr. Read more about the Chef Indexer or Search.

Data Store

Chef Server utilizes CouchDB for storing JSON data about Nodes, Roles, and Data Bags. The server requires CouchDB 0.9.1 or above for API compatibility reasons. For more information about CouchDB, please see CouchDB's project page.

CouchDB Administration CouchDB Administration for Chef Server

Information Stored

The Chef Server stores several bits of information about the configured objects in the infrastructure.

API Clients

Clients are entities that access the API. They are stored as JSON objects in CouchDB, are indexed and searchable. Each client has a public key stored on the server, and a private key that should be copied to the client. Clients come in two flavors for accessing the API.

• Humans
• Non-humans

Humans interact with the API through Knife or the Management Console. In the Management Console, they have users, and the Management Console itself is a non-human API client whose name is chef-webui. Non-humans are Nodes running the chef-client command/daemon, or services that otherwise access the API programatically.

Cookbooks

The Chef Server distributes Cookbooks to Chef Clients - specifically, it distributes:

• Libraries
• Attributes
• Definitions
• Recipes

Directly to each node based on the dependencies specified in the cookbook Metadata.

The Server also serves up Files and Templates on an as-needed basis.

Nodes

The Chef Server provides for the management and authentication of Nodes via pre-shared RSA keys. Node data is indexed and searchable. See the Nodes section for more details on how to manage Nodes. See the Authentication page to learn how the Authentication model works.

OpenID Deprecated! As of Chef version 0.8, OpenID is deprecated!

Roles

The Chef Server stores JSON objects about Roles configured. Roles are indexed and searchable. Learn more about Roles and how to manage them on the Roles page.

Data Bags

The server can optionally store arbitrary JSON data known as data bags. Data bags are indexed and searchable. See the Data Bags page for more information on how to use this feature.

Configuration

Startup Configuration

Since the Chef Server is a Merb application, there's a variety of ways to configure it. To learn more, read about Chef Server Configuration Stacks.

Debian Packaging For installations using the 0.8 Debian/Ubuntu packaging, the init script configuration is in /etc/default/chef-*.