CSC/ECE 517 Spring 2015/ch1a 2 WA

Knife

Knife is the command line tool for managing Chef nodes. Simply, Chef allows the distribution of server environments between many different servers (called nodes). Any changes to the primary chef server (called the chef repo are distributed throughout all the other nodes, while different nodes can have other recipes and send them back to the chef repo. Knife, then, handles the communication between nodes and the chef repo. For example, let's say that there is an object on the chef repo that a node desires. Knife provides the tools to download that object to the node. Knife also allows setting up a node, installing necessary packages, management of users, and much more.

Background

Chef streamlines the task of configuring and maintaining a company's servers, and can integrate with cloud-based platforms. If you are unfamiliar with Chef and how it works, check out the comparison between Chef and Puppet here: [1] or take a look at the official Chef website here: <ref>Chef</ref>. There, a deeper understanding of Chef can be attained.

Chef includes two important command-line tools.

• Knife command-line tool
• Chef command-line tool

knife is the command-line tool that provides an interface between a local chef-repo and the Chef server. Whereas, Chef command-line tool is used while working with the chef repo.

Examples

Using Knife is fairly straightforward, with usage following this syntax:

 knife [verb] [object] [options] 

The different verbs, or subcommands, for Knife are as follows, from the Using Knife page<ref> Knife Documents</ref>: bootstrap, client, configure, cookbook, cookbook site, data bag, delete, deps, diff, download, edit, environment, exec, index rebuild, list, node, recipe list, role, search, show, ssh, status, tag, upload, user, and xargs.

Warning: Before you run many of these commands, you should have the knife editor set correctly. In the chef-repo, there are multiple ruby files that set the configuration of the environment. Inside of knife.rb, you need to add or set the following line.

<syntaxhighlight lang="ruby">
knife[:editor] = "/usr/bin/vim"
</syntaxhighlight>

The path can be set to the text editor of choice, the above command sets the editor to vim.

The example we will use is also one that is useful for setting up nodes, and that is the usage of the bootstrap command. To set up a node, go to the command line on the chef repo and execute the following command:

knife bootstrap ip_address_of_node -x username -P password --sudo 

First, the verb used is bootstrap. Bootstrap is the subcommand that allows the installation of a chef client on to a targeted node. Second, the object is the ip_address_of_node. Every subcommand takes an object, and since chef operates on many ruby principles and scripts, the object can be most anything. For boostrap, this object is the ip of the server address. For other commands, this might be something different. Third, we have the options for the bootstrap command and the object. For bootstrap, this includes the username and password for the node, and the option --sudo, to make sure all commands are executed correctly.

Before we do the next example, let's cover an important part of object strings and how they are treated by knife and the chef repo.

Wildcards A wildcard search can be used similar to standard regex commands, with one notable difference. The wildcard character itself must be escaped using the \ character. Here is an example from the "Using Knife" page on the chef website. Let's say the following was used to search for an object:

data_bags/a\*

Will return all of the objects that start with data_bags\a on the chef-node. However, if we were to run the following:

data_bags/a*

Will only search for objects on the chef repo corresponding to objects starting with data_bags/a on the node. Therefore, the * was applied before being sent to the chef repo, instead of after. So, as an example, let us list all of the data bags that are on the server that start with 'a'. Our object, then, is the string above, data_bags/a\*. The verb that lists different objects on the chef repo is called list. Our command we would run would be this:

knife list data_bags/a\*

Which would print to the console all of the objects in the data_bags directory that started with a.

Bootstrapping A Node

One of the key uses of knife is doing something called "bootstrapping" a node. This key tool allows someone using the Chef server to set up a remote node, or client. Not only does knife set up all of the relevant recipes, environments, and other such things related with the chef repo itself, it also installs all of the tools necessary for interacting with the chef server and configuring the chef client. Because of this, a basic understanding in how to bootstrap a node, and some knowledge on the available options for bootstrapping a node, is important.

Luckily, bootstrapping a node is very simple. To bootstrap a node, the general command would look like this. Be aware, this is being run from the chef server.

knife bootstrap ip_address_of_node -x username -P password --sudo --node-name name_of_node

This process will create a chef client at the designated IP adress. The username and the password is the username and password of a root access user on the remote node. The name of the node can be set here as well, instead of automatically using other settings. The option is shown here, to make the rest of the example easier to understand. Luckily, the knife bootstrap command uses an omnibus installer that automatically detects the OS of the target machine and will install all of the necessary command line tools and internal installations, like ruby, for the chef client to function. Once the bootstrap command is complete, the following message will be displayed.

INFO: Report handlers complete

However, before continuing, confirmation of the remote node is necessary. To confirm that the remote node was installed correctly and is running, run the following command.

knife client show name_of_node

Here, the name_of_node is the name of the node either set in other options and commands, such as the --node-name used above. When this is run, the node's information should be displayed, such as if the node is an admin, the name of the node, and the JSON type it was created from.

admin:       false
chef_type:   client
json_class:  Chef::ApiClient
name:        name_of_node
public_key:

References

<references/>