/knife-solo

Concepts from spatula and littlechef implemented as a knife plugin

Primary LanguageRubyMIT LicenseMIT

knife-solo ↑

<img src=“https://secure.travis-ci.org/matschaffer/knife-solo.png” alt=“Build Status” /> <img src=“https://codeclimate.com/badge.png” />

DESCRIPTION: ↑

Knife-solo is a gem plugin for Chef’s knife utility. It currently adds 4 subcommands to knife: kitchen, prepare, cook and wash_up

The kitchen command is used to create a new directory structure that fits with chef’s standard structure and can be used to build and store recipes.

The prepare command installs Ruby, RubyGems and Chef on a given host. It’s structured to auto-detect the target OS and change the installation process accordingly.

The cook command uploads the current kitchen (chef repo) to the target host and runs chef-solo on that host.

The wash_up command removes the uploaded kitchen from the target host.

Preliminary Windows support for cook is available (see below).

USAGE: ↑

Installation is a normal gem installation.

gem install knife-solo

If you need to install from git run:

rake install

Kitchen command ↑

The kitchen command simply takes a name of the directory to store the kitchen structure.

knife kitchen mychefrepo

Currently the directory structure looks like this, but could change as development continues.

mykitchen/
├── cookbooks
├── data_bags
├── nodes
├── roles
├── site-cookbooks
└── solo.rb

Prepare command ↑

The prepare command takes an ssh-style host argument as follows:

knife prepare ubuntu@10.0.0.201

It will look up SSH information from ~/.ssh/config or in the file specified by -F. You can also pass port information (-p), identity information (-i), or a password (-P). It will use sudo to run some of these commands and will prompt you for the password if it’s not supplied on the command line.

This command will make a best-effort to detect and install Chef-solo on your target operating system. We use the Opscode Installer wherever possible.

If you need specific behavior you can fallback to a knife bootstrap command with an empty runlist using the following:

knife bootstrap --template-file bootstrap.centos.erb -u root 172.16.144.132
echo '{"run_list":[]}' > nodes/172.16.144.132.json

Bootstrap templates are quite simple, as shown in this gist for bootstrap.centos.erb.

Or if your modifications provide some general benefit, consider sending a pull request to this project or the omnibus installer.

Cook command ↑

The cook command also takes an ssh-style host argument:

knife cook ubuntu@10.0.0.201

The cook command uploads the current kitchen to the server and runs chef-solo on that server. If you only specify one argument it will look for a node config in nodes/<hostname>.json. Or if you want to specify a node config you can pass the path to the file as the second argument.

This uploads all of your cookbooks in addition to a patch that allows you to use data_bags in a read-only fashion from the data_bags folder.

This also supports encrypted data bags. To use them, place your key in data_bag_key in the root of your kitchen (or if you move it make sure to update solo.rb to reflect the new path).

The knife command for creating encrypted data bags doesn’t work well without a Chef server, so use this gist as an example on how to create encrypted data bag items on your local file system.

WashUp command ↑

The wash_up command takes the same arguments like prepare and cook:

knife wash_up ubuntu@10.0.0.201

The wash_up command removes an uploaded kitchen completely from the target host. This improves security because passwords etc. are not left behind on that host.

Windows support ↑

The cook command will work on Windows node if you meet the following howto:

Kitchen then tweak ↑

Prepare the node manually ↑

Cook ↑

  • cook should work as expected automatically, if you use cygwin rsync

DEVELOPMENT ↑

Get set up by running ./script/newb this will do some of the steps and guide you through the rest. If it doesn’t run for you, feel free to file an issue.

When running integration tests all output is sent to the log directory into a file that matches matches the test case name. The EC2Runner log is the main runner log that contains information about instance provisioning.

Note that instances will remain running until your tests pass. This aids in speeding up the test cycle. Upon succesfful test completion you’ll be given 10 seconds to cancel the process before the instances are cleaned up. Note that any instance tagged with knife_solo_integration_user == $USER will be cleaned up. Or if you want to leave your instances running regardless, specify SKIP_DESTROY=true as an environment variable.

To make an integration test, create a file in the test/integration directory and a test class that inherits from IntegrationTest and includes a module from test/integration/cases. You can override methods as necessary, but generally you only need to override user and image_id to specify the user name and AMI ID.

If you’re interested in contributing, contact me via GitHub or have a look at the GitHub issues page.