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.
The topic writeup for this page can be found here.
Background
Chef streamlines the task of configuring and maintaining a company's servers, and can integrate with cloud-based platforms. Chef is an IT and environment distribution system, built to be robust and scalable. Imagine a large scale internet based company. Depending on the demands of the company, they may have a need for development workstations, servers for purchasing products, servers for hosting games, even clients for games or accessing databases. All of these different environments are called chef client nodes, with each different setup as different environments. For example, you might have ten chef client nodes set up with the development environment, and one hundred chef client nodes set up with the server environment. The chef server contains all of the recipes, reusable code that may be needed both for use and setup of different chef client nodes, to set up all of the different environments that have been defined. In addition, the chef server works like other versioning software. This means you can roll out updates conveniently to all of the different chef client nodes with ease. This allows the entire collection of chef, the recipes, environments, and nodes, called the infrastructure, to be managed simply and in defined, scalable versions. Chef is more complex and allows other little tricks and nuances. If you want to learn more about Chef itself, beyond the description found here, check out the comparison between Chef and Puppet here: [1] or take a look at the official Chef website here: <ref>Chef</ref>, which are the sources for the information in this background. This description just serves to introduce the concept of chef, so that knife's purpose can be understood. These other pages cover the ideas of Chef and how to use it effectively in more detail. In fact, the main site for Chef has an interactive tutorial in setting up a Chef server, without even having to use a personal server or computer. However, the rest of this article will be describing and covering knife.
What is Knife?
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 client node and the Chef server. Where the Chef command-line tool is used while working with the chef server and repo, Knife helps us to manage the following:
- Nodes
- JSON data Stores
- Environments
- chef-clients installations on management workstations
Basically, the chef command tool deals with the actual chef installation wherever it is, either a local installation and on the server. It deals only with itself. Knife, however, deals with the setup of all the communication and objects between the chef server and a chef client node. In the figure, we can see that how knife provides an interface between local repository's and Chef server at the workstation.
Using Knife
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 <ref>Install Bootstrap</ref>. 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:
Bootstrap Options and Knife Settings
As one of the most powerful tools knife has to offer, the bootstrap function has many different options available to it. The "Installing Bootstrap" section covered three such options (-x, -P, and --node-name), but there are many more available that are useful. Here are a few that stand out as being useful to someone using knife bootstrap for the first time, or for people who are dealing with something outside of the normal conditions for installing and using knife bootstrap. In addition, adding different settings to the knife.rb file will be covered, for people looking to expand the usage of knife and knife bootstrap. Most of this information is covered in higher detail in the main knife bootstrap page, as well as all the other options. You can check that page out using the reference here.<ref>Knife Boostrap</ref>
--bootstrap-curl-options OPTIONS, --bootstrap-install-command COMMAND, --bootstrap-install-sh URL
These commands allow customization of the installation bootstrap performs. They are all mutually exclusive, but allow different ways to perform this customization. The first, bootstap-curl-options, which allows additional cURL options to be performed alongside the bootstrap installation. To learn more about cURL, check out their main web page here: (cURL Home Page). The second, bootstrap-install-command, allows the execution of another install command on the target node alongside the bootstrap function. The final one, bootstrap-install-sh, allows a custom install script located at the designated URL to be run, following the bootstrap command.
--environment ENVIRONMENT, --boostrap-template TEMPLATE
The --environment and --bootstrap-template commands are similar, in that they allow customization of the target node. One allows the node to be set up against a target environment, which is useful if your chef server has multiple environments available. The next allows different node setups to be saved as templates. These can be used to quickly and efficiently set up additional similar nodes, especially if the additional installation options in bootstrap are long.
-V
A small option for bootstrap, the -V option forces the initial chief-client setup to be run on the target node at the debug log level, following the bootstrap installation. This allows almost complete remote setup of new nodes, assuring that the node is ready to be used and the chef-client is fully operational and doesn't need further setup. In addition, the debug log will allow any errors in the chef client to be saved, in the case of something wrong occurring with the node. The exact command run is shown below:
chef-client -l debug
Custom settings and adding them to the knife.rb file
For some settings, including settings related to bootstrap, the options will need to be added to the knife.rb file. This file contains all of the commands for knife, and all of the different options available to these commands. For example, to use the --bootstrap-template and the --sudo options, the following commands need to be executed:
knife[:template_file] knife[:use_sudo]
These commands add the template_file and use_sudo options to the knife.rb file, which will enable those options to be used in the bootstrap command. There are more options that can be added using the knife.rb file, the full knife documentation for commands are here: (Knife Reference).
References
<references/>