Provided by: chake_0.20-1_all 
NAME
chake - serverless configuration with chef
INTRODUCTION
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.
CREATING THE REPOSITORY
$ chake init
[create] nodes.yaml
[ mkdir] nodes.d/
[create] config.rb
[ mkdir] config/roles
[ mkdir] cookbooks/basics/recipes/
[create] cookbooks/basics/recipes/default.rb
[create] Rakefile
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 intrastructure.
After the repository is created, you can call either chake or rake, as they are completely
equivalent.
MANAGING NODES
Just after you created your repository, the contents of nodes.yaml is the following:
host1.mycompany.com:
run_list:
- recipe[basics]
You can list your hosts with rake nodes:
$ rake nodes
host1.mycompany.com ssh
To add more nodes, just append to nodes.yaml:
host1.mycompany.com:
run_list:
- recipe[basics]
host2.mycompany.com:
run_list:
- recipes[basics]
And chake now knows about your new node:
$ rake nodes
host1.mycompany.com ssh
host2.mycompany.com ssh
PREPARINGS NODES TO BE MANAGED
Nodes have very few initial requirements to be managed with chake:
• The node must be accessible via SSH.
• 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.
CHECKING CONNECTIVITY AND INITIAL HOST SETUP
To check whether hosts are correcly configured, you can use the check task:
$ rake check
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; and
• the user you are connecting as has password-less sudo correctly setup.
$ rake check
APPLYING COOKBOOKS
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.
To check the existing tasks, run
$ rake -T
WRITING COOKBOOKS
Since chake is actually a wrapper for Chef Solo, you should read the [chef
documentation](https://docs.chef.io/). In special, look at the [Chef Solo
Documentation](https://docs.chef.io/chef_solo.html).
THE NODE BOOTSTRAPPING PROCESS
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
NODE URLS
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)
EXTRA FEATURES
HOOKS
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.
Example:
task :bootstrap_common do
sh './scripts/pre-bootstrap-checks'
end
ENCRYPTED 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.
REPOSITORY-LOCAL SSH 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.
LOGGING IN TO A HOST
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.
RUNNING ALL SSH INVOCATIONS WITH SOME PREFIX COMMAND
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 [...]
CONVERGING LOCAL HOST
If you want to manage your local workstation with chake, you can declare a local node like
this in nodes.yaml:
local://thunderbolt:
run_list:
- role[workstation]
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:
local://desktop:
run_list:
- role[workstation]
local://laptop:
run_list:
- role[workstation]
When you run rake converge on desktop, laptop will be skipped, and vice-versa.
ACCESSING NODE DATA FROM YOUR OWN TASKS
It’s often useful to be able to run arbitrary commands against the data you have about
nodes. You can use the Chake.nodes for that. For example, if you want to geolocate each of
yours hosts:
task :geolocate do
Chake.nodes.each do |node|
puts "#{node.hostname}: %s" % `geoiplookup #{node.hostname}`.strip
end
end
ENVIRONMENT VARIABLES
• $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 server.
• $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.
SEE ALSO
• rake(1), chef-solo(1)
• Chef documentation: https://docs.chef.io/
2019-11-27 CHAKE(1)