Skip to end of metadata
Go to start of metadata

Overview

The knife exec subcommand allows you to write Ruby scripts that are executed in the context of a fully configured Chef API Client using the knife configuration file. Knife exec scripts also share the same DSL as Shef's main mode - any commands available in the top-level of shef help output are available.


The purpose of Knife Exec is slightly different than Knife Plugins. This sub-command is often used for scripts that should access the Chef Server API for one-off type operations and don't warrant full blown Knife sub-command usage.

Note the Context

As you are writing Ruby scripts that are executed in the context of a fully configured Chef API Client using the knife configuration file, the following are some details of note:

  • The script lives on your management workstation, not the nodes. (i.e. on the system from which you are invoking knife, not on the systems that you are managing with chef)
    • The context of shell commands issued will therefore be your management workstation.
    • Something like %x[ls -lash /opt/only-on-a-node] would give you the directory listing for your /opt/only-on-a-node directory, or the error "no such file exists" if the directory does not exist locally.
  • While the Shef's DSL is available, the chef-client DSL is not
    • Unless your management workstation is also a chef-client being managed by the chef-server.
    • Without the chef-client DSL, you cannot use a bash block to run bash commands.

Invocation

Invoke knife exec in one of three ways to write scripts.

Examples

Some one-line examples

List the search indexes available.

Show all the nodes and their free memory available.



Tutorials from the Community


  • Knife Exec to Search for Systems Needing Updates

Opscode team member Bryan McLellan wrote a blog post on Knife Reporting: apt + updates, using a Knife exec script to search for and describe systems needing updates.

This blog is helpful for knowing how to issue shell commands in the context of your managed nodes.

  • Knife Exec + Fog to Reconcile EC2 Instances

Community member James Sulinski has a most excellent blog post on using Knife Exec and Fog and Highline gems to reconcile the EC2 and Chef API’s and output it in a way which provides a beneficial overview. (Code - knife.reconcile)

  • Command-line Cookbook Dependency Solving with Knife Exec

Need to replicate a node setup elsewhere, and aren't sure of all the cookbook dependencies? Or, just want to validate that you've uploaded all the cookbooks that are stated as being required?

Community member Stephen Nelson-Smith has a blog post on Dependency Solving using Knife Exec.

More detailed examples

A slightly different take on the knife status command.
scripts/status.rb
Post some status information to a google spreadsheet.

Requires that you install the google-spreadsheet-ruby gem and configure GOOGLE_EMAIL and GOOGLE_PASSWORD as environment variables with the appropriate values in your shell.

scripts/google_status.rb

(Thanks, Darrin Eden, for the Google Spreadsheet code!)


Query a node for multiple attributes.

This is a ruby script executed in the context of a fully configured Chef client that can talk to the API.

scripts/search_attributes.rb

Example usage and output:


Using Chef Knife to Delete Node Attributes

There are a number of items that must be determined initially, and apply against the script settings

  1. Determine the type of attribute that needs to be set
  2. Determine the name of the attribute
  3. Determine the set of nodes that it needs to be set on
    • organization?
    • environment?
    • role?

Note: Because of the way node attributes work, you need to use override_attrs.delete instead of override.delete

Example of changing a 'normal' attribute using set for all nodes with a certain role via knife exec:

Passing Arguments to Knife Scripts

Command-line arguments can be passed into a Knife script and read in using Ruby's global ARGV array. To ensure command line arguments are not later treated as additional files to be executed by knife, end your script with exit 0 (see CHEF-1973).

scripts/stale_nodes.knife

Use Case Scenario

Is there a reason why deleting a cloud instance using knife does not delete the instance in the management console? We spin instances up and down constantly, and while we do not have more than 5 instances at any given time there are now 40 instances in the dashboard. Managing them manually using a dashboard seems counterintuitive.

The reason the node is left behind is because there are cases in which one would want to preserve the node data beyond the life of the specific cloud instance. There is an active discussion about best practices, and a number of people have requested the behavior you desire (instance and node deleted together) as well. While best practices are in discussion and an automated solution that addresses both needs is considered, in the current scenario, there are various approaches that can be undertaken. Some use a small shell function that runs `knife ec2 server delete`, `knife node delete`, and `knife client delete` in sequence. You could also construct a small `knife exec` script that does all three operations.

Here is an example:

This `knife-exec` script could be used by saving it as server-delete.rb and running it as follows:







Knife Windows Bootstrap


Launch Cloud Instances with Knife



Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.