Introducing Knife

Knife is a command-line tool that comes bundled with the Chef installation. Depending upon how Chef was installed, you may find the binary at any particular location on your workstation. Since I have installed Chef using rvm and gem packaging, it is found at ~/.rvm/gems/ruby-2.1.0/gems/chef-11.8.2/bin/knife.

Depending upon your setup, you may find it at some other location. Whatever the location, ensure that it is in your PATH variable.

Knife is used for almost every aspect of managing your interactions with chef-server. It helps us manage:

• Cookbooks
• Environments
• Roles
• Data bags
• Nodes
• API clients
• Bootstrapping of instances
• Searching for nodes

Let's see what the knife command has to offer to us. Just fire up the terminal and enter the command:

$knife
ERROR: You need to pass a sub-command (e.g., knife SUB-COMMAND)
Usage: knife sub-command (options)
 -s, --server-url URL Chef Server URL
 --chef-zero-port PORT Port to start chef-zero on
 -k, --key KEY API Client Key
 --[no-]color Use colored output, defaults to false on Windows, true otherwise
 -c, --config CONFIG The configuration file to use
 --defaults Accept default values for all questions
 -d, --disable-editing Do not open EDITOR, just accept the data as is
 -e, --editor EDITOR Set the editor to use for interactive commands
 -E, --environment ENVIRONMENT Set the Chef environment
 -F, --format FORMAT Which format to use for output
 -z, --local-mode Point knife commands at local repository instead of server
 -u, --user USER API Client Username
 --print-after Show the data after a destructive operation
 -V, --verbose More verbose output. Use twice for max verbosity
 -v, --version Show chef version
 -y, --yes Say yes to all prompts for confirmation
 -h, --help Show this message

Available subcommands: (for details, knife SUB-COMMAND --help)

** BOOTSTRAP COMMANDS **
. . .

** CLIENT COMMANDS **
. . .

. . .

Whoa! That was some output. So that's the power of Knife, and it tells you that you need to make use of subcommands such as cookbook, node, client, role, databag, and so on. We will look at each of these in detail later.

Before we start using Knife, we need to configure it. During this configuration, we'll specify where Knife can contact our chef-server, where cookbooks are residing on our machine, and so on.

The configuration file for Knife is called knife.rb and is typically found in the ~/.chef folder. This is a Ruby file, as is visible from its extension; you guessed right, it can contain actual Ruby code along with some configuration settings that are required for the working of Knife.

The following are the configuration settings that we'll specify in our knife.rb file:

Here is a sample ~/.chef/knife.rb file:

log_level                :info
log_location             STDOUT
node_name                'maxc0d3r'
client_key               '~/keys/chef/maxc0d3r.pem'
validation_client_name   'chef-validator'
validation_key           '~/keys/chef/validation.pem'
chef_server_url          'http://chef-server.sychonet.com:4000'
cache_type               'BasicFile'
cache_options            ( :path => '~/.chef/checksums' )
cookbook_path            [ '~/code/chef-repo/cookbooks' ]

Just to verify that Knife has been set up properly, run the following command:

$knife client list
chef-validator
chef-webui
maxc0d3r

So, we queried chef-server about all the API clients and it duly responded back with the list of 3 clients. As you can see, the API client that I'll be using to communicate with chef-server is also available there.

With Knife configured, let's see what we can do with it.

Managing cookbooks

Knife is the tool that we'll be using to do all sorts of operations on cookbooks residing on our development workstation or on a remote chef server. Operations for a cookbook can be the following:

• Creating a new cookbook
• Uploading a cookbook to chef-server
• Deleting a cookbook from chef-server
• Downloading a cookbook from chef-server
• Deleting multiple cookbooks from chef-server
• Listing all cookbooks on chef-server

Creating a new cookbook

In order to create a new cookbook, issue the following command:

$knife cookbook create new-cookbook
** Creating cookbook new-cookbook
** Creating README for cookbook: new-cookbook
** Creating CHANGELOG for cookbook: new-cookbook
** Creating metadata for cookbook: new-cookbook

This command will create the following directory structure along with some default files in the path you've specified in the cookbook_path variable in the knife.rb file:

$ tree new-cookbook/
new-cookbook/
├── CHANGELOG.md
├── README.md
├── attributes
├── definitions
├── files
│ └── default
├── libraries
├── metadata.rb
├── providers
├── recipes
│ └── default.rb
├── resources
└── templates
 └── default

We'll look at this structure in detail later while finding out more about cookbooks. For now, it's sufficient for us to know that the new cookbook called new-cookbook has been created.

Uploading a cookbook to chef-server

Now we went on to modify this cookbook as per our requirements; once done, we want to upload this cookbook to chef-server. The following command will help us get this job done:

$ knife cookbook upload new-cookbook
Uploading new-cookbook [0.1.0]
Uploaded 1 cookbook.

Cool, so our cookbook was uploaded, but what's this 0.1.0? Well, as we'll see in Chapter 6, Cookbooks and LWRPs, chef-server allows us to maintain different versions of a cookbook. The version is defined in the file called metadata.rb and, if you look at new-cookbook/metadata.rb, you will see that the version defined for the cookbook is 0.1.0. You can maintain different versions of the same cookbook on chef-server and use any particular version you want while bootstrapping the instances.

Getting the list of all the cookbooks on chef-server

There are times when we'd like to get a list of all the cookbooks residing on a remote chef-server, and this is all the more important when you are working in teams. The following command will get you a list of all cookbooks on chef-server:

$ knife cookbook list
new-cookbook 0.1.0

Let's modify the version of our cookbook and upload it once more. To do this, edit the new-cookbook/metadata.rb file and change the version to 0.1.1:

$sed -i .bak 's/0.1.0/0.1.1/g' new-cookbook/metadata.rb

Note

You can ignore the .bak extension, but on some platforms it's kind of necessary (such as Mac OS X).

Let's upload the cookbook once more:

$ knife cookbook upload new-cookbook
Uploading new-cookbook [0.1.1]
Uploaded 1 cookbook.

Now let's see what cookbooks are on chef-server:

$ knife cookbook list
new-cookbook 0.1.1

So we see that our newly uploaded cookbook is there. However, where has my previous version gone? Well, it's not gone anywhere, it's just that by default Knife is reporting back the latest version of the cookbook. If you want to see all the versions of cookbooks, use the same command with the –a argument:

$ knife cookbook list –a
new-cookbook 0.1.1 0.1.0

Deleting cookbooks

There are times when you'd like to delete a cookbook or some version of your cookbook, as you know that it's not going to be in use now. The following command helps us accomplish this task:

$ knife cookbook delete new-cookbook
Which version(s) do you want to delete?
1. new-cookbook 0.1.1
2. new-cookbook 0.1.0
3. All versions

2
Deleted cookbook[new-cookbook][0.1.0]

If we don't specify any version, Knife will list all available versions of cookbooks and ask us to choose one of them for deletion. If you know which version to delete, you can just specify the version:

$ knife cookbook delete new-cookbook 0.1.0
Deleted cookbook[new-cookbook][0.1.0]

If you wish to delete all versions of a cookbook, use the command with the –a argument as follows:

$ knife cookbook delete new-cookbook -a
Do you really want to delete all versions of new-cookbook? (Y/N) y
Deleted cookbook[new-cookbook][0.1.1]
Deleted cookbook[new-cookbook][0.1.0]

To avoid confirmation, append –y to the last command or add knife[:yes] to your knife.rb file.

The delete command doesn't purge the entire cookbook or concerned version from chef-server, and keeps one copy of files. If you wish to completely delete the concerned cookbook or a version of it, append the delete command with –purge.

Downloading a cookbook

Let's say you and your friend are working on a cookbook together by collaborating using Git. It so happens that your friend uploaded a new version of the cookbook onto chef-server; however, he/she forgot to push the changes to Git. Now, he is on leave for a week and you want to carry on with the development on this cookbook, but you also want to know what all changes your friend made. This is one area where downloading a cookbook really helps. However, ensure that you aren't using downloaded cookbooks to override content within your SCM repository, or else it can cause issues when trying to merge changes later on, and will eventually corrupt your SCM repository.

You can download a cookbook using the following command:

$ knife cookbook download new-cookbook –d /tmp
Which version do you want to download?
1. new-cookbook 0.1.0
2. new-cookbook 0.1.1

1
Downloading new-cookbook cookbook version 0.1.0
Downloading resources
Downloading providers
Downloading recipes
Downloading definitions
Downloading libraries
Downloading attributes
Downloading files
Downloading templates
Downloading root_files
Cookbook downloaded to /tmp/new-cookbook-0.1.0

So again, if you've multiple versions of cookbooks, Knife will ask which version of cookbook to download. I've used the –d option to specify which directory to download the cookbook to. If it's not specified, the cookbook is downloaded to the current working directory. If you know which version of cookbook needs to be downloaded, you can specify that as follows:

$ knife cookbook download new-cookbook 0.1.1 -d /tmp
Downloading new-cookbook cookbook version 0.1.1
Downloading resources
Downloading providers
Downloading recipes
Downloading definitions
Downloading libraries
Downloading attributes
Downloading files
Downloading templates
Downloading root_files
Cookbook downloaded to /tmp/new-cookbook-0.1.1

Deleting multiple cookbooks

Knife also provides a bulk delete subcommand that allows you to delete cookbooks whose names match a regex pattern.

For example, the following command will delete all versions of all cookbooks starting with new:

$ knife cookbook bulk delete "^new"
All versions of the following cookbooks will be deleted:

new-cookbook

Do you really want to delete these cookbooks? (Y/N) y

Deleted cookbook new-cookbook [0.1.1]
Deleted cookbook new-cookbook [0.1.0]

Managing environments

Usually in any project, the infrastructure is split across different environments such as dev, staging, production, and so on. Chef allows us to maintain different configurations and settings across different environments through the concept of environments.

Creating an environment

To manage environments, create a directory named environments in the root of your Chef repository. Your directory structure will look something like the following:

.
├── README.md
├── cookbooks
├── data_bags
├── environments
└── roles

All the environment-related configs will be kept inside the environments directory. Let's presume that we've an environment called production and another one called staging. We like to live on the cutting edge in the staging environment and keep the latest version of our web server package there, whereas, in production environment, we are cautious and always keep a tested version of the web server. We'll create two files, namely staging.rb and production.rb, in the environments directory:

staging.rb:
name "staging"
description "Staging Environment"
override_attributes :webserver => { :version => "1.9.7" }

production.rb:

name "production"
description "Production Environment"
override_attributes :webserver => { :version => "1.8.0" }

Now, all we need to do is ensure that these configurations get pushed to chef-server. To do this, we run the following command:

$ knife environment from file staging.rb
Updated Environment staging

$ knife environment from file production.rb
Updated Environment production

When using the files in your SCM repository, to manage environments, ensure that you specify the full path of the .rb files when using the Knife environment from the file command.

One can also create environments directly by issuing the following command:

$ knife environment create <environment_name>

This will open up an editor (ensure that either you've an environment variable called EDITOR set up or the path to your favorite editor specified in knife.rb). You can modify the content of the file opened up by the last command and save it.

Deleting an environment

You may delete an environment using the following command:

$ knife environment delete <environment_name>

For example, the following command will delete the environment named staging from chef-server:

$ knife environment delete staging
Do you really want to delete staging? (Y/N) y
Deleted staging

If you wish to override the confirmation, either append the command with –y, or specify knife[:yes] in your knife.rb file.

Editing an environment

You can edit an environment by modifying the files inside the environments folder and rerunning the following command:

$ knife environment from file <filename>

Alternatively, you can directly modify the environment by issuing the following command:

$ knife environment edit <environment_name>

Listing all environments

You can see the list of all environments configured on chef-server through the following command:

$ knife environment list
_default
staging

As you can see, the command listed two environments, namely _default and staging. The _default environment comes along as the default with chef-server, and any node that doesn't have an environment associated with it (more on this later) will have the _default environment associated to it.

Displaying information about an environment

You can view information about an environment through the following command:

$ knife environment show <environment_name>

Consider the following as an example:

$ knife environment show staging
chef_type: environment
cookbook_versions:
default_attributes:
description: Staging Environment
json_class: Chef::Environment
name: staging
override_attributes:
 webserver:
 version: 1.9.7

Managing roles

Roles are used to group together cookbooks under a single roof and apply them on the node that is to be bootstrapped. Roles in Chef comprise of a run_list and a set of attributes. As with environments, you can manage roles through Knife.

Creating a new role

You can create a new role using the following command:

$ knife role create <role_name>

This will open your editor with a template, and all you need is to fill that template to your liking and save.

Alternatively, you can create a role separately in a file inside the roles directory and, once you are satisfied with the content of that file, just issue the following command:

$ knife role from file <filename>

I prefer the second option as it allows me to maintain revisions of code inside a version control system.

Let's create the role named webserver. To do this, we'll create the file called webserver.rb inside the roles folder:

#Role to manage webservers

name "webserver"
description "Webserver Role"

run_list  "recipe[webserver]","recipe[logstash]"

As you can see, I've specified two recipes in the run_list, namely webserver and logstash. We'll use the webserver recipe to install and configure a web server, while the logstash recipe is used to push logs from a web server to a central log server running Graylog.

We'll now push this newly created role onto our chef-server:

$ knife role from file webserver.rb
Updated Role webserver!

Deleting a role

You can delete a role by issuing the following command:

$ knife role delete <rolename>

Consider the following as an example:

$ knife role delete webserver
Do you really want to delete webserver? (Y/N) y
Deleted role[webserver]

Editing a role

You may edit an existing role by using the following command:

$ knife role edit <rolename>

Alternatively, you can edit the corresponding role file in your local Chef repository, and then use the following command:

$ knife role from file <role_file>

Listing all available roles

You can get a list of all available roles using the following command:

$ knife role list
webserver

Displaying information about a role

You can use the following command to see what the role is supposedly doing:

$ knife role show <rolename>

For example

$ knife role show webserver
chef_type: role
default_attributes:
description: Role to manage webserver
env_run_lists:
json_class: Chef::Role
name: webserver
override_attributes:
run_list:
 recipe[webserver]
 recipe[logstash]

Managing nodes

Nodes are the machines that we'll be configuring using Chef. Chef stores information about nodes in node objects, which can be viewed in the JSON format. We can manage details like creating a node, editing a node, listing all available nodes, modifying run_list applicable to nodes, overriding some attributes corresponding to a node, deleting a node, and so on, using Knife.

Creating a node

One can create a new node using the following command:

$ knife node create <node_name>

Alternatively, you can use the following command:

$ knife node from file <filename.rb>

Nodes need to be created explicitly by you as a chef-client run automatically takes care of creating a new node object for you. However, let's see this command in action:

$ knife node create webserver01

This command will open up your favorite text editor with the following template:

{
  "name": "webserver01",
  "chef_environment": "_default",
  "json_class": "Chef::Node",
  "automatic": {
  },
  "normal": {
  },
  "chef_type": "node",
  "default": {
  },
  "override": {
  },
  "run_list": [

  ]
}

Modify the values for chef_environment by replacing _default with staging, and add recipe[webserver], recipe[logstash], or role[webserver] to the run_list:

{
  "name": "webserver01",
  "chef_environment": "staging",
  "json_class": "Chef::Node",
  "automatic": {
  },
  "normal": {
  },
  "chef_type": "node",
  "default": {
  },
  "override": {
  },
  "run_list": [
    "recipe[webserver]",
    "recipe[logstash]"
  ]
}

Save the file and voilà, you get a response from Knife saying that your new node was created:

Created node[webserver01]

You could've easily created that JSON file yourself and used the following command:

$knife node from file <filename>

This would've had the same effect.

Listing all available nodes

Okay, so we've our newly created node on chef-server. Let's see if it's actually there. You can get a list of all available nodes on chef-server using the following command:

$knife node list
webserver01

Displaying information about a node

If you want to see what all configurations are associated with a particular node, you can do this by using the following command:

$knife node show webserver01
Node Name: webserver01
Environment: staging
FQDN:
IP:
Run List: recipe[webserver], recipe[logstash]
Roles:
Recipes:
Platform:
Tags:

You might be wondering why few fields are empty in the preceding output. If you remember, in Chapter 1, Introduction to the Chef Ecosystem, while understanding the anatomy of a chef-client run, we saw that, as the first step in a chef-client run, Ohai is executed that profiles the underlying system and tries to fetch system-related information. This information is finally used to build the node object. When building the node object directly using Knife, the system-related information is not yet collected, and hence the corresponding fields are blank.

Editing a node

You can edit a node object using the following command:

$knife node edit <node_name>

Alternatively, edit the file containing JSON data for the concerned node and issue the following command:

$knife node from file <filename>

Adding stuff to the run_list associated with a node

Let's say you've created a brand new cookbook that will add some monitoring stuff to your web server, and you want to add that recipe to a particular node. Now, you can go on and edit a node and modify the run_list, but since it's just a run_list that needs to be modified, you can use the following command:

$ knife node run_list add <node_name> [ENTRY]

For example, let's presume our monitoring cookbook is called monitoring. Let's add it to our newly created node—webserver01:

$ knife node run_list add webserver01 recipe[monitoring]
webserver01:
 run_list:
 recipe[webserver]
 recipe[logstash]
 recipe[monitoring]

Cool! So now, our node object has three recipes associated with it.

Deleting stuff from the run_list associated with a node

You can use the following command to delete stuff from a node's run_list:

$ knife node run_list remove <node_name> [ENTRY]

For example, let's delete recipe[logstash] from the run_list associated with node webserver01:

$knife node run_list remove webserver01 recipe[logstash]
webserver01:
 run_list:
 recipe[webserver]
 recipe[monitoring]

You can also specify multiple entries while deleting elements from the run_list as follows:

$ knife node run_list remove webserver01 'recipe[logstash]','recipe[monitoring]'
webserver01:
 run_list: recipe[webserver]

Deleting a node object

This is especially necessary for instances running on cloud platforms such as AWS, Rackspace, Azure, and so on. Cloud platform providers have made it very easy for people to provision infrastructure on demand. However, as easy as it is to scale up the infrastructure, it's as hard to maintain it—especially when you've instances going up and down like crazy due to provisions for elasticity. If we are managing instances in cloud, it's very essential to find some way to clean up node objects from chef-server that aren't up-and-running anymore. You can delete a node object using the following command:

$knife node delete <node_name>

For example, let's presume our node webserver01 no longer exists in the physical world. Let's get rid of this node object then:

$ knife node delete webserver01 -y
Deleted node[webserver01]

Note

With AWS, you can make use of SNS and SQS to build a system where, if an instance goes down, a SNS notification is issued that writes a message to SQS. This message contains the name of the instance (which is a tag). You can then write a daemon that runs on one machine and polls SQS for any message; if there is any message, it pops it out, reads the name of the instance, and issues a command to delete the node from chef-server.

Managing an API client

As with node objects, every instance that communicates with chef-server registers itself as an API client. This client is authenticated with chef-server through a public/private key pair, and every communication with the chef-server REST API is authenticated through this. In general, the node name and client name are usually the same; however, they can be different too. You can create, delete, edit, reregister, and list clients using Knife.

Creating a new client

You can create a new client using the following command:

$ knife client create maxc0d3r

This will open up your favorite text editor with the following JSON template:

{
  "name": "maxc0d3r",
  "public_key": null,
  "validator": false,
  "admin": false,
  "json_class": "Chef::ApiClient",
  "chef_type": "client"
}

Note

If you want to make your client admin, change the value of false to true. As you'll see in later chapters, the admin privilege is something that can be very useful in certain cases. Usually, whenever a new instance registers itself with chef-server, it's registered as a non-admin client. However, a non-admin client doesn't have certain privileges, such as modifying data bag elements, and so on. If you are running the Chef setup in a private network, I would suggest modifying the Chef code so that every client is registered automatically as an admin.

Save this file and exit your editor, and the command will return your private key:

$ knife client create maxc0d3r
Created client[maxc0d3r]
-----BEGIN RSA PRIVATE KEY-----
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
-----END RSA PRIVATE KEY-------

Save this private key in a safe place, and now you can communicate with chef-server as maxc0d3r using the private key we just downloaded.

Listing all available API clients

You can find a list of all available clients using the following command:

$ knife client list
chef-validator
chef-webui
maxc0d3r

The chef-validator and chef-webui clients come by default along with "chef-server.

Displaying information about a client

You can use the following command to get the required information about an API client from chef-server:

$ knife client show maxc0d3r
admin: true
chef_type: client
json_class: Chef::ApiClient
name: maxc0d3r
public_key: -----BEGIN RSA PUBLIC KEY-----
XXXXXXXXXXXXXXXXXXXX
-----END RSA PUBLIC KEY-----
validator: false

Deleting an existing client

You can delete an existing client using the following command:

$ knife client delete maxc0d3r -y
Deleted client[maxc0d3r]

Reregistering a client

It might so happen that on one really bad day, you lost your private key that you'd received while registering the client with chef-server. Well, not everything is lost here. You can reregister your client with chef-server by issuing the following command:

$ knife client reregister maxc0d3r
-----BEGIN RSA PRIVATE KEY-----
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
-----END RSA PRIVATE KEY-------

Reregistration of a client will invalidate the previous public/private key pair, and chef-server will return you a new private key that you can use now to communicate with chef-server using the existing client.

The search command

Perhaps one of the most useful use of Chef, while managing large-scale infrastructures, is through the search facility. The Chef server maintains an index using Solr, and this index can be queried for a wide range of stuff such as data bags, environments, nodes, and roles. One can specify exact, wild card, or fuzzy search patterns to search through this index.

You can use the search command as follows:

$knife search INDEX QUERY

Here, INDEX in the command can either be the client, environment, role, node, or data bag name. QUERY is the query string that will be executed. The default INDEX value is node; if it's not specified, it's implied as a node by default.

Consider the following as an example:

$ knife search '*:*'
Node Name: webserver01
Environment: staging
FQDN:
IP:
Run List: recipe[webserver], recipe[logstash]
Roles:
Recipes:
Platform:
Tags:

If the search query pattern doesn't contain a colon (:), the default query is: tags:*#{@query}*, roles:*#{@query}*, fqdn:*#{@query}*, or addresses:*#{@query}*.

Let's see some examples of a Knife search in action:

• To find all nodes having the environment as production and the platform as Ubuntu, the command will be as follows:

  $ knife search node 'chef_environment:production AND platform:ubuntu'
  

• To find all nodes having the environment as production and the platform as Ubuntu, and to show the users configured on these machines, the command will be as follows:

  $knife search node 'chef_environment:production AND platform:ubuntu' –a users
  

  The -a option is used to restrict the output to attributes that have been specified. This is especially useful if we want to write a script around the output from a Knife search.

• To find all nodes having the environment as production and the role as webserver, the command will be as follows:

  $ knife search node 'chef_environment:production AND role:webserver'
  

• To find all nodes having the environment as production and recipes as logstash, the command will be as follows:

  $ knife search node 'chef_environment:production AND recipes:logstash'
  

Bootstrapping a node

Knife can also be put to effective use to bootstrap a machine. Let's presume you've got a brand-new machine that you want to set up as a web server. For the sake of this example, I'll presume that it's a Ubuntu 12.04 machine. The service provider has given you the hardware and has installed the operating system for you. However, now, in order to configure it with Chef, you need to install the chef-client on the machine. One way to go about doing this is to manually go to the machine and install Chef using the gems or omnibus installer.

However, there is a more easy way. You can use your good old friend Knife to set up chef-client on a newly created instance.

Use the following command to bootstrap your instance:

$ knife bootstrap webserver01 –x user01 –i user01.key --sudo

This command will use user01.key as the SSH key, and try to use SSH to connect to the remote machine (webserver01) as user (user01). Once it's able to establish SSH connection, this command will then set up Chef using the omnibus installer using sudo. Finally, the command will register the node with the chef-server and trigger a chef-client run.

We'll see more ways to accomplish this job in later chapters.

Some useful Knife plugins

Knife is a wonderful tool on its own. However, there are plenty of plugins available that help extend the functionality of Knife. We'll be writing some such plugins in later chapters. Let's take a sneak peak at a few really useful plugins that will help ease your job of administering a large-scale infrastructure.

The knife-ssh plugin

Say you had around 10 web servers in your infrastructure, with the environment as production and the role as webserver. Now, one day you realize that you want to clean up a directory, say /var/log/nginx, as you've forgotten to clean up logs that have been accumulating over a period of time due to a misconfigured log rotation script.

No worries, the knife-ssh plugin is just meant to handle this situation. Here is how we can use it:

$ knife ssh –i <path to ssh key> 'chef_environment:production AND role:webserver' –x user 'sudo –i rm –f /var/log/nginx/*.gz'

This command is presuming that a user named user has sudo privileges on all the machines that have chef_environment as production and webserver as role.

The knife-ec2 plugin

AWS is one of the most popular public cloud service provider, and one of its offerings is called EC2. This service allows you to create machines that can then be used for a different purpose.

This plugin provides the ability to create, bootstrap, and manage EC2 instances. You'll need to install this plugin before being able to use it. To install this plugin, issue the following command:

$gem install knife-ec2

Once the plugin is installed, you'll need to add these two additional configuration values to your knife.rb file:

knife[:aws_access_key_id] = "AWS_ACCESS_KEY"
knife[:aws_secret_access_key] = "AWS_SECRET_KEY"

If you aren't in the US-EAST-1 region, you'll also need to specify one other configuration parameter:

knife[:region]

You could've also provided these values as arguments to the knife ec2 command, but keeping them in knife.rb is perhaps the easiest way.

Once you've the plugin set up correctly, you can list all your EC2 instances using the following command:

$ knife ec2 server list

You can create a new instance using the following subcommand:

$ knife ec2 server create

You'll need to supply some information such as the AMI ID, SSH key pair name, and so on, for this purpose. You can find more details about the options that this command accepts using the following command:

$ knife ec2 server create –help

The knife-azure plugin

This is a plugin very similar to the knife-ec2 plugin, and provides capabilities to manage instances on the Microsoft Azure cloud platform.

The knife-google plugin

This is a plugin on the lines of the knife-ec2 plugin, and provides capabilities to manage instances on Google Compute Engine.

The knife-push plugin

If you are using Enterprise Chef, you might want to try using the push job facility. It's an add-on that allows jobs to be executed on a machine independent of chef-client. A job is a command that has to be executed and the machine on which it needs to be executed is defined by a search query.

Push jobs have three main components: jobs (managed by the push jobs server), a client (which is installed on each machine), and one (or more) workstations.

These components communicate with each other as follows:

• A heartbeat message between the push job server (usually chef-server) and each node.
• The knife-push plugin that provides four commands: job list, job start, job status, and node status.
• Various job messages are sent from the workstation to job server.
• A single job message is sent from the push job server to one or more nodes for execution.

You can find more details about push jobs at http://docs.opscode.com/push_jobs.html.

Other than these plugins, there are many other plugins available for use. You can find some of them at https://github.com/chef?query=knife.