chake - serverless configuration with chef
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
over SSH on each host.
$ chake init
[ mkdir] nodes.d/
[ mkdir] config/roles
[ mkdir] cookbooks/basics/recipes/
A brief explanation of the created files:
•nodes.yaml: where you will list the
hosts you will be managing, and what recipes to apply to each of them.
•nodes.d: a directory with multiple
files in the same format as nodes.yaml. All files matching *.yaml in it will
be added to the list of nodes.
•config.rb: contains the chef-solo
configuration. You can modify it, but usually you won’t need to.
•config/roles: directory is where you
can put your role definitions.
•cookbooks: directory where you will
store your cookbooks. A sample cookbook called "basics" is created,
but feel free to remove it and add actual cookbooks.
•Rakefile: Contains just the require
'chake' line. You can augment it with other tasks specific to your
After the repository is created, you can call either chake or rake, as they are
Just after you created your repository, the contents of nodes.yaml is the
You can list your hosts with rake nodes:
$ rake nodes
To add more nodes, just append to nodes.yaml:
And chake now knows about your new node:
$ rake nodes
Nodes have very few initial requirements to be managed with chake:
•The node must be accessible via
•The user you connect to the node must
either be root, or be allowed to run sudo (in which case sudo must be
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.
To check whether hosts are correcly configured, you can use the check task:
That will run the the sudo true command on each host. If that pass without you
having to passwords, you are sure that
•you have SSH access to each host;
•the user you are connecting as has
password-less sudo correctly setup.
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
To apply the configuration to a single node, run
To apply a single recipe on all nodes, run
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
To run a shell command on all nodes, run
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
To check the existing tasks, run
Since chake is actually a wrapper for Chef Solo, you should read the [chef
documentation]( ⟨URL: https://docs.chef.io/ ⟩). In special, look
at the [Chef Solo Documentation]( ⟨URL:
When chake acts on a node for the first time, it has to bootstrap it. The
bootstrapping process includes doing the following:
•installing chef and rsync
•disabling the chef client daemon
•setting up the hostname
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: 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
•port: port number to connect to
•/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
task :bootstrap_common do
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.
To easily login to one of your host, just run rake login:$HOSTNAME. This will
automatically use the repository-local SSH configuration as above so you
don’t have to type -F .ssh_config all the time.
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
If you want to manage your local workstation with chake, you can declare a local
node like this in nodes.yaml:
To apply the configuration to the local host, you can use the conventional rake
converge:thunderbolt, or the special target rake local.
When converging all nodes, chake will skip nodes that are declared with the
local:// backend and whose hostname does not match the hostname in the
declaration. For example:
When you run rake converge on desktop, laptop will be skipped, and vice-versa.
•$CHAKE_SSH_CONFIG: Local SSH
configuration file. Defaults to .ssh_config.
•$CHAKE_SSH_PREFIX: Command to prefix
SSH (and rsync over SSH) calls with.
•$CHAKE_RSYNC_OPTIONS: extra options to
pass to rsync. Useful to e.g. exclude large files from being upload to each
•$CHAKE_NODES: File containing the list
of servers to be managed. Default: nodes.yaml.
•$CHAKE_NODES_D: Directory containing
node definition files servers to be managed. Default: nodes.d.
•$CHAKE_TMPDIR: Directory used to store
temporary cache files. Default: tmp/chake.
•$CHAKE_CHEF_CONFIG: Chef configuration
file, relative to the root of the repository. Default: config.rb.
•Chef documentation: ⟨URL: