A node can be defined as a server that is managed by chef. It can be either a virtual or a physical server. “Managed by chef” means that the server has a chef client installed on it and that it is able to communicate with the chef server.

In this chapter, we try to cover all aspects related to a node. We also cover the installation and configuration of a node.

Types of Nodes

Nodes can be of different types. They can be virtual, physical, or cloud based. We consider two types of nodes here: cloud based and physical or virtual servers.

Cloud-based nodes refer to the nodes that are hosted on any of the cloud providers, such as AWS (Amazon Web Services), Microsoft Windows Azure, or any other cloud provider. We can provision these types of nodes using knife. Once the nodes are created chef can easily manage them.

A physical server can be a virtual machine or a server or any device that can send, receive, and forward information. In simpler terms, it is a device that can communicate with the chef server and has chef client installed and configured.

Node Names

The node_name is used as a part of the authentication process of the chef server.

The node name can be anything, but should be unique within a chef organization.

We can provide the node name in the client configuration file (client.rb). By default, chef uses Ohai to get the node name and it is the FQDN (fully qualified domain name) of the server.

Using the FQDN as the node name, and then allowing Ohai to collect this information during each chef run is the recommended approach and the easiest way to ensure that the names of all nodes across the chef organization are unique.

Manage Nodes

Nodes can be managed in chef using various approaches. They can be managed using knife or using the management console that chef provides.

• We can use knife to manage the nodes. Managing covers creating, editing, tagging, listing, and so on.
• We can use knife plug-ins to provision nodes.
• We can also manage nodes using the management console.

Chef Client

Chef client is an agent installed on the node, and with its help, the nodes communicate with the chef server. Whenever chef client is run on a node, it follows certain steps.

The Chef Run

Chef run basically defines the steps that take place whenever chef client is invoked. Figure 5-1 shows the various steps that occur during a typical chef run.

We discuss each step in detail.

Whenever chef client is run, the following steps occur:

1. Get configuration details
2. Authenticate with chef server
3. Rebuild on the node object
4. Expand the run list
5. Download the cookbooks on the node
6. Reset node attributes
7. Identify resources
8. Configure the node
9. Update the node object

We cover each step in detail in the following sections.

Get Configuration Details

The client configuration file (Client.rb) is used to store the configuration details. The configuration includes the node name with which the node (client) is registered with the chef server. We can provide the node name in the client configuration file if we want the node to be registered with some specific name. If we don’t provide anything in the client configuration file, then the node is registered with the FQDN.

Authenticate with Chef Server

To make sure that requests received by chef server are from a known source, it uses an RSA encryption mechanism. The node name is taken into consideration while generating the certificate. Whenever the chef client runs for the first time on the node, it takes the identity of chef validator to generate the RSA key for the node. When we configure a node, a public and a private key are generated for each node and the server keeps the public key while the node keeps the private key. Each request that comes from a node to the server comes in encrypted HTTP headers form which is decrypted using the public key.

Rebuild on the Node Object

The chef client downloads the node object from the chef server to the node. The node object is a JSON (JavaScript Object Notation) file which contains details like run list, node-specific attributes (if any), and some other information about that node.

Expand the Run List

The run list in the node object containing the details about every role/recipe that will be applied to the node is expanded and then placed in the order in which it will be applied to the node. The recipe that occurs first in the run list will be applied first, and so on.

Download the Cookbooks on the Node

In chef, the processing takes place at the client. So whenever the chef client runs, it downloads all the cookbooks in the run list of the node to the local cache of the node and then compiles them. If any file has changed, chef client downloads the new version of the file and deletes the previous version. The files include recipes, resources, libraries, and so on.

Reset Node Attributes

The next step in the chef run is to reset all the node attributes. The attributes are loaded from roles, environments, recipes, Ohai, and attribute files according to their precedence level and are updated on the node object. Chef has various types of precedence levels. Attributes are applied in chef in the following order, 1 being the lowest precedence and 16 the highest. Table 5-1 also describes the same thing in a different way, where 1 is the lowest precedence level and 15 is the highest.

Identify Resources

The next step is to identify the resources that would be required for successful compilation of the recipes. All the definitions and libraries are loaded so that the Ruby classes and the pseudo resources are available at the time of compilation. The recipe/recipes are loaded and the blocks within these recipes are evaluated. The recipes are evaluated in a top-down approach.

Configure the Node

The next step is to configure the node using the information that has been collected in the aforementioned steps. The resources that were identified in the previous steps are now mapped to a provider that will perform the desired action. The provider is responsible for completing the necessary action.

Update the Node Object

The final step is for the chef run to update the node object on the chef server. This action takes place when all the other actions have been completed. The chef client updates the node object that was built during the chef run on the chef server. This object would be used during the next chef run. Thus, the latest version information on a node is available in the chef server after every configuration of the node.

Install and Configure the Node

In order to configure a node properly, several steps are necessary. We demonstrate the configuration of a node on an Enterprise Linux-based operating system. The same steps can be used to configure it on any other operating system:

1. Identify the operating system
2. Install the chef client package
3. Copy the key files from the chef server

Identify the Operating System

This step mainly includes identifying the operating system (OS) which will help us in installing the relevant package on the system.

The OSs listed in Table 5-2 currently support chef client.

Install the Chef Client Package

There are two options to install the chef client package:

1. We can directly use the script provided by chef, which will install the latest version available.
2. We can download the relevant version and install it using a suitable method.

Go to www.getchef.com/chef/install/.

Visit the chef client tab and select your OS and its architecture.

You can use any of the methods just described to install the chef client.

Figure 5-2 demonstrates installation using the second method. Select the chef version and download it to the machine on which we will configure the node.

After downloading the installer, run it using a relevant method based upon your OS. For Windows, double-click and install (see Figure 5-3). For Enterprise Linux, download the rpm and install it.

Verify the installation by typing chef-client –v at the command line. It should return something like what we see in Figure 5-4.

Copy the Key Files from the Chef Server

The node needs some keys and configuration files to connect and authenticate with the chef server. The following items are required:

• Client configuration file (Client.rb): You can create it using the knife configure command.
• Chef validator key: This is a private key that is generated by the chef server when we configure it for the first time. We need to manually copy this file to the workstation.

Bootstrap

Bootstrapping is a process whereby when a new node gets into the environment. It gets configured based on the policies and configuration required for that role.

As explained in earlier chapters, the chef server is the centralized location where all data is stored. The data stored includes the node object and the cookbooks that define the configuration and policies.

Thus, the client node uses the chef client to connect to the chef server and download the configuration details from the chef server. The chef client does the heavy lifting and processing to do the configuration changes required on the node. Thus, at the end of configuration, the chef node has the desired configuration based on the policies and role. The chef client only makes the required changes to the node and does not make any changes if nothing is required to be changed on the node.

The steps required to bootstrap a node are as follows:

1. Identify the FQDN or IP address for the node.
2. Run the knife bootstrap command.
3. Verify the node on the chef server.

The first step in bootstrapping is to identify the configured FQDN or IP address assigned to a node.

The knife bootstrap command requires the FQDN or the IP address of the node in order to complete the bootstrap operation.

After you identify the IP address and FQDN, the administrator has to run the knife bootstrap command.

knife bootstrap IP –x username –P password –sudo.

The command installs chef on the end client and runs chef client on the node.

The last step in this exercise is to verify that the client is now configured and available in the chef server for further management (see Figure 5-5). The following command is used to verify the installation of chef-client and its configuration in the chef-server.

knife client show name_of_node.

The chef server will return something as shown in Figure 5-5.

If something similar to what is shown in Figure 5-5 is returned, then chef has successfully been installed on your node.

Configuring

Chef client uses a configuration file (Client.rb) to store the configuration. This file is loaded every time we run chef client. If we are working on a Linux-based box, this file is normally stored at /etc/chef/client.rb and on a Windows-based server the location is c:/chef/client.rb.

Various settings can be done via this file. Table 5-3 discusses some of the important options available in the configuration file.