The Chef Server acts as a hub for configuration data. The Chef Server stores cookbooks, the policies that are applied to cookbooks, and metadata that describes each registered node in the infrastructure. Nodes use the chef-client to ask the Chef Server for configuration details, such as recipes, templates, and file distributions. The chef-client then does as much of the configuration work as possible on the nodes themselves (and not on the Chef Server). This scalable approach distributes the configuration effort throughout the organization.
There are three types of Chef servers:
| Flavor | Description |
|---|---|
| Hosted Chef | Hosted Chef is a version of a Chef Server that is hosted by Opscode. Hosted Chef is cloud-based, scalable, and available (24x7/365), with resource-based access control. Hosted Chef has all of the automation capabilities of Chef, but without requiring it to be set up and managed from behind the firewall. Hosted Chef is based on the idea that an infrastructure management tool should be built around a collection of API primitives. By using an API to talk to a cloud provider (such as Amazon Virtual Private Cloud, Windows Azure, or Rackspace), it allows the freedom to think of those primitives as building blocks. Chef only needs to know about the desired state, how it should get there, and what the proper functionality of that desired state should be. |
| Private Chef | Private Chef is a version of a Chef Server that is designed to provide all of the infrastructure automation capabilities of Chef, set up and managed from within the organization. Private Chef evolved out of a need for customers to have the same functionality provided by Hosted Chef, but located behind the firewall. Private Chef is the same as Hosted Chef in every other way. Hosted Chef is the largest Private Chef deployment in the world. |
| Open Source Chef Server | The open source Chef Server is a free version of the Chef Server that contains much of the same functionality as Hosted Chef, but requires that each instance be configured and managed locally, including performing data migrations, applying updates to the open source Chef Server, and ensuring that the open source Chef Server scales as the local infrastructure it is supporting grows. The open source Chef Server includes support from the Chef community, but does not include support directly from Opscode. |
Starting with the release of Chef 11.x, the front-end for the Chef Server is written using Erlang, which is a programming language that first appeared in 1986, was open sourced in 1998, and is excellent with critical enterprise concerns like concurrency, fault-tolerance, and distributed environments. This version of Chef can scale to the size of any enterprise and is often referred to as Erchef.
The following diagram shows the various components that are part of a Chef Server deployment and how they relate to one another.
| Component | Description |
|---|---|
| Bookshelf | Bookshelf is used to store cookbook content—files, templates, and so on—that have been uploaded to the Chef Server as part of a cookbook version. Cookbook content is stored by content checksum. If two different cookbooks or different versions of the same cookbook include the same file or template, Bookshelf will store that file only once. The cookbook content managed by Bookshelf is stored in flat files and is separated from the Chef Server and search index repositories. All cookbooks are stored in a dedicated repository. |
| WebUI | chef-server-webui is a Ruby on Rails 3.0 application that hosts the web interface for the Chef Server. |
| Erchef | Erchef is a complete rewrite of the core API for the Chef Server, which allows it to be faster and more scalable than previous versions. The API itself is still compatible with the original Ruby-based Chef Server, which means that cookbooks and recipes that were authored for the Ruby-based Chef Server will continue to work on the Erlang-based Chef Server. The chef-client is still written in Ruby. Note Even though Chef 11.x is authored in Erlang, writing code in Erlang is NOT a requirement for using Chef 11.x. |
| Message Queues | Messages are sent to the Search Index using the following components:
All messages are added to a dedicated search index repository. |
| Nginx | Nginx is an open-source HTTP and reverse proxy server that is used as the front-end load balancer for the Chef Server. All requests to the Chef Server API are routed through Nginx. |
| PostgreSQL | PostgreSQL is the data storage repository for the Chef Server. |
For Hosted Chef, these components are mostly transparent because of the hosted interface for the Chef Server. For Private Chef and the open source Chef Server, these relationships can be more complex, depending on how the machines on which the Chef Server will run need to be deployed.
Each type of Chef Server provides the following features:
| Feature | Description |
|---|---|
| Chef Server API | The Chef Server API is used to provide access to objects on the Chef Server. |
| Data Bags | A data bag is a global variable that is stored as JSON data and is accessible from a Chef Server. |
| Environments | An environment is a way to map an organization’s real-life workflow to what can be configured and managed when using Chef Server. |
| Node Objects | The node object consists of the run-list and node attributes, which is a JSON file that is stored on the Chef Server. The chef-client gets a copy of the node object from the Chef Server during each Chef run and places an updated copy on the Chef Server at the end of each Chef run. |
| Roles | A role is a way to define certain patterns and processes that exist across nodes in a Chef organization as belonging to a single job function. |
| Search | Search indexes allow queries to be made for any type of data that is indexed by the Chef Server, including data bags (and data bag items), environments, nodes, and roles. |
