Chef is a systems and cloud infrastructure automation framework that makes it easy to deploy servers and applications to any physical, virtual, or cloud location, no matter the size of the infrastructure. The chef-client relies on abstract definitions (known as cookbooks and recipes) that are written in Ruby and are managed like source code. Each definition describes how a specific part of your infrastructure should be built and managed. The chef-client then applies those definitions to servers and applications, as specified, resulting in a fully automated infrastructure. When a new node is brought online, the only thing the chef-client needs to know is which cookbooks and recipes to apply.
The following diagram shows the relationships between the various elements of a very simple organization, including the hosted Enterprise Chef server, a workstations, the chef-repo, and some simple nodes that exist either in VirtualBox or Amazon Web Services.
The following sections discuss these elements in a bit more detail.
A node is any physical, virtual, or cloud machine that is configured to be maintained by a chef-client.
A workstation is a computer that is configured to run Knife, to synchronize with the chef-repo, and interact with a single server. The workstation is the location from which most users will do most of their work, including:
- Developing cookbooks and recipes (and authoring them using Ruby)
- Keeping the chef-repo synchronized with version source control
- Using Knife to upload items from the chef-repo to the server
- Configuring organizational policy, including defining roles and environments and ensuring that critical data is stored in data bags
- Interacting with nodes, as (or when) required, such as performing a bootstrap operation
Knife is a command-line tool that provides an interface between a local chef-repo and the server. Knife helps users to manage:
- Cookbooks and recipes
- Stores of JSON data (data bags), including encrypted data
- Cloud resources, including provisioning
- The installation of the chef-client on management workstations
- Searching of indexed data on the server
The chef-repo is the location in which the following data objects are stored:
- Cookbooks (including recipes, versions, cookbook attributes, resources, providers, libraries, and templates)
- Data bags
- Configuration files (for clients, workstations, and servers)
The chef-repo is located on a workstation and should be synchronized with a version control system, such as git. All of the data in the chef-repo should be treated like source code.
Knife is used to upload data to the server from the chef-repo. Once uploaded, that data is used by the chef-client to manage all of the nodes that are registered with the server and to ensure that the correct cookbooks, environments, roles, and other settings are applied to nodes correctly.
git is the most commonly-used location to store a chef-repo that is used with a hosted Enterprise Chef account, but git is not required.
The Hosted Server
The server acts as a hub for configuration data. The 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 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 server). This scalable approach distributes the configuration effort throughout the organization.
Hosted Enterprise Chef is a version of the server that is hosted by Chef. Hosted Enterprise Chef is cloud-based, scalable, and available (24×7/365), with resource-based access control. Hosted Enterprise Chef has the same automation capabilities of any server, but without requiring it to be set up and managed from behind the firewall.
A cookbook is the fundamental unit of configuration and policy distribution. Each cookbook defines a scenario, such as everything needed to install and configure MySQL, and then it contains all of the components that are required to support that scenario, including:
- Attribute values that are set on nodes
- Definitions that allow the creation of reusable collections of resources
- File distributions
- Libraries that extend the chef-client and/or provide helpers to Ruby code
- Recipes that specify which resources to manage and the order in which those resources will be applied
- Custom resources and providers
- Metadata about recipes (including dependencies), version constraints, supported platforms, and so on
The chef-client uses Ruby as its reference language for creating cookbooks and defining recipes, with an extended DSL for specific resources. The chef-client provides a reasonable set of resources, enough to support many of the most common infrastructure automation scenarios; however, this DSL can also be extended when additional resources and capabilities are required.
The key underlying principle of Chef is that you (the user) knows best about what your environment is, what it should do, and how it should be maintained. The chef-client is designed to not make assumptions about any of those things. Only the individuals on the ground—that’s you and your team—understand the technical problems and what is required to solve them. Only your team can understand the human problems (skill levels, audit trails, and other internal issues) that are unique to your organization and whether any single technical solution is viable.
The idea that you know best about what should happen in your organization goes hand-in-hand with the notion that you still need help keeping it all running. It is rare that a single individual knows everything about a very complex problem, let alone knows all of the steps that may be required to solve them. The same is true with tools. Chef provides help with infrastructure management. And Chef can help solve very complicated problems. Chef also has a large community of users who have a lot of experience solving a lot of very complex problems. That community can provide knowledge and support in areas that your organization may not have and (along with Chef) can help your organization solve any complex problem.
For more information …
For a history of Chef, where it came from and how it evolved, watch these two (short) videos:
- Part one: http://www.youtube.com/watch?v=Ia2ItmjRsw8
- Part two: http://www.youtube.com/watch?v=Ss6P92L_sCA
For more information about Chef, cookbooks, and the community: