The Chef server acts as a hub for configuration data. The Chef server stores cookbooks, the policies that are applied to nodes, and metadata that describes each registered node that is being managed by the chef-client. 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 servers:
|Enterprise Chef||Enterprise Chef evolved out of a need for customers to have a highly scalable server with the same functionality as hosted Enterprise Chef, but located on-premises and managed from behind the firewall.|
|Hosted Enterprise Chef||Hosted Enterprise Chef is a version of the Chef server that is hosted by Chef. Hosted Enterprise Chef is cloud-based, scalable, and available (24x7/365), with resource-based access control. Hosted Enterprise Chef has the same automation capabilities of any Chef server, but without requiring it to be set up and managed from behind the firewall.|
|Open Source Chef||The Open Source Chef server is a free version of the Chef server. Each instance of the Open Source Chef server must be configured and managed locally, including data migrations, applying updates, and ensuring that the local infrastructure scales appropriately. The Open Source Chef server includes support from the community. Support from Chef is optional.|
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. Chef 11.x 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.
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 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.
Even though Chef 11.x is authored in Erlang, writing code in Erlang is NOT a requirement for using Chef 11.x.
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 Enterprise Chef, these components are mostly transparent because of the hosted interface for the Chef server. For Enterprise Chef and Open Source Chef, 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:
|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-client run and places an updated copy on the Chef server at the end of each chef-client run.|
|Roles||A role is a way to define certain patterns and processes that exist across nodes in an 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.|