Nodes

Components of a Node

A node is made up of two prime components: a Run List and Attributes.
The Run List is an ordered list of Recipes or Roles to run. Recipes are the fundamental building block of Chef - they define the resources you want managed, in the order you want them managed. Roles are ordered lists of other Roles and Recipes, expanded at run time. Attributes are data about your node - things like the network interfaces, file systems, or how many clients your Apache server can accept.

Lifecycle of a Node

When you start Chef Client or Chef Solo, the first thing we do is create a Node object. We then:

1. load up Ohai, which detects information about the operating system ("Ohai speaks for the operating system"). This also gives us access to this hosts fully qualified domain name and hostname, which we use to
2. grab the last known state of the Node from the Chef Server (assuming we are using Chef Client). Once there,
3. we update all the Ohai attributes to their latest value, and add any extra attributes specified via JSON on the command line.
4. Finally, we will run all of the Attribute files in all of the cookbooks in your Chef repository.

At runtime, the Node is available within Recipes, Definitions, and Resources as they are being evaluated.

Authentication

Chef uses Signed Header Authentication for each request. Node data is separate from the identity used to authenticate requests to the Chef Server, which is managed by an API client. Each API client has a public/private key pair. The public half of the key is stored in the database on the server, and the private half is kept locally by the client. On a node running the Chef Client, the private key is generally stored in /etc/chef/client.pem. Each request to the Chef server includes a request signature in the HTTP headers. The request signature is computed from the hash of the request content and encrypted with the client's private key to verify the identity of the user or machine making the request and prevent attempts to tamper with the content.

When a node runs chef-client for the first time, it generally does not yet have an API client identity, and so cannot make authenticated requests to the server. This is where the validation client—named "chef-validator" by default comes in. When the chef-client runs, it checks if it has a client key. If the client key does not exist, it then attempts to "borrow" the validation client's identity to register itself with the server. In order to do that, the validation client's private key needs to be copied to the host and placed in /etc/chef/validation.pem. Once the client machine has registered itself with the chef server, it no longer uses the validation client for anything. It is recommended that you delete the validation client's private key from the host after the host has registered.

Authentication and Authorization provides additional detail on the Chef model for these actions.

Managing Nodes

The recipes list and attributes of nodes may be managed through multiple means.

Managing Nodes via Knife

Knife is Chef's command line tool, and can be used to create, edit, view, list, tag and delete nodes. Refer to the Knife documentation for additional details on knife.

• Managing Nodes With Knife provides information on how this powerful command line tool can be used to manage the chef-client nodes in your infrastructure.

Managing Nodes via the Management Console

The Management Console is Chef's web interface. Nodes can be managed in the Management Console.

• Managing Nodes through the Management Console provides documentation on Open Source Chef users.
• Hosted and Private Chef customers should refer to Managing Nodes with the Hosted Chef Management Console.

Managing Nodes through JSON at the command line

Both Chef Client and Chef Solo allow you to write JSON to a file and read it in through the command line. The file should contain a hash, the elements of which will be added as attributes on your Node.

We have two special entries that can be used to set which cookbooks/recipes will be applied during run-time.

• run_list - specify roles and/or recipes to add to the node.
• recipes - add only recipes to the node. This should not be used, please always use run_list in this purpose.

For all you AWS users This is an awesome way to use per-instance metadata. You can just stick some JSON in, and have it written to a file on disk, which you read with the Chef Client or Chef Solo to configure your nodes. Easy peasy!

Managing Nodes via a Cookbooks Attribute or Recipe file

You can also ensure that an attribute or is set via an Attribute or Recipe file.

Use Case Questions

How do I run more than one node on a system or change a node name?

You can use the -N option to chef-client or chef-solo to set the node name manually.

Can you name a node anything you choose?

The only restriction Chef places on node names is that they match this regular expression:

Lightweight Resources and Providers (LWRP)

Setting the run_list in JSON during run time