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).
Installation is a normal gem installation.
gem install knife-solo
If you need to install from git run:
rake install
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
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.
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.
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.
The cook command will work on Windows node if you meet the following howto:
-
run ‘knife kitchen` then edit solo.rb to use Windows path-naming (see gist.github.com/1773854)
-
install a SSH server (eg: WinSSHd)
-
install rsync on the node (see github.com/thbar/rsync-windows)
-
add rsync to the user PATH
-
install www.opscode.com/chef/install.msi
-
add nodes/hostname.json and put ‘{ “run_list”: [] }` in it
-
cook should work as expected automatically, if you use cygwin rsync
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.