chake man page

chake is a tool that helps you manage multiple hosts with, without the need for a chef server. Configuration is managed in a local directory, which should probably be under version control with git(1) or anything else. Configuration is usually deployed via rsync over SSH, and applied by invoking chef-solo(1) over SSH on each host.

The user you connect to the node must either be root, or be allowed to run sudo (in which case sudo must be installed).

A note on password prompts: every time chake calls ssh on a node, you may be required to type in your password; every time chake calls sudo on the node, you may be require to type in your password. For managing one or two nodes this is probably fine, but for larger numbers of nodes it is not practical. To avoid password prompts, you can:

Configure SSH key-based authentication. This is more secure than using passwords. While you are at it, you also probably want disable password authentication completely, and only allow key-based authentication

Configure passwordless sudo access for the user you use to connect to your nodes.

Note that by default all tasks that apply to all hosts will run in parallel, using rake’s support for multitasks. If for some reason you need to prevent that, you can pass -j1 (or --jobs=1`) in the rake invocation. Note that by default rake will only run N+4 tasks in parallel, where N is the number of cores on the machine you are running it. If you have more than N+4 hosts and want all of them to be handled in parallel, you might want o pass -j (or --jobs), without any number, as the last argument; with that rake will have no limit on the number of tasks to perform in parallel.

To apply the configuration to all nodes, run

$ rake converge

To apply the configuration to a single node, run

$ rake converge:$NODE

To apply a single recipe on all nodes, run

$ rake apply[myrecipe]

To apply a single recipe on a specific node, run

$ rake apply:$NODE[myrecipe]

If you don’t inform a recipe in the command line, you will be prompted for one.

To run a shell command on all nodes, run

$ rake run[command]

If the command you want to run contains spaces, or other characters that are special do the shell, you have to quote them.

To run a shell command on a specific node, run

$ rake run:$NODE[command]

If you don’t inform a command in the command line, you will be prompted for one.

The keys in the hash that is represented in nodes.yaml is a node URL. All components of the URL but the hostname are optional, so just listing hostnames is the simplest form of specifying your nodes. Here are all the components of the node URLs:

[backend://][username@]hostname[:port][/path]

backend: backend to use to connect to the host. ssh or local (default: ssh)

username: user name to connect with (default: the username on your local workstation)

hostname: the hostname to connect to (default: none)

port: port number to connect to (default: 22)

/path: where to store the cookbooks at the node (default: /var/tmp/chef.$USERNAME)

You can define rake tasks that will be executed before bootstrapping nodes, before uploading configuration management content to nodes, and before converging. To do this, you just need to enhance the corresponding tasks:

bootstrap_common: executed before bootstrapping nodes (even if nodes have already been bootstrapped)

upload_common: executed before uploading content to the node

converge_common: executed before converging (i.e. running chef)

connect_common: executed before doing any action that connects to any of the hosts. This can be used for example to generate a ssh configuration file based on the contents of the nodes definition files.

Any files ending matching .gpg and .asc will be decrypted with GnuPG before being sent to the node. You can use them to store passwords and other sensitive information (SSL keys, etc) in the repository together with the rest of the configuration.

If you need special SSH configuration parameters, you can create a file called .ssh_config (or whatever file name you have in the $CHAKE_SSH_CONFIG environment variable, see below for details) in at the root of your repository, and chake will use it when calling ssh.

Some times, you will also want or need to prefix your SSH invocations with some prefix command in order to e.g. tunnel it through some central exit node. You can do this by setting $CHAKE_SSH_PREFIX on your environment. Example:

CHAKE_SSH_PREFIX=tsocks rake converge

The above will make all SSH invocations to all hosts be called as tsocks ssh [...]