Roles

Run lists

Each node has a run-list. When using Chef-Server, chef-client gets run-list from server on each run. Chef-cuisine is designed to use chef-solo (or chef client in local-mode) for many reasons, so we have to manage run-list in our repository and get it from resulting tarball from nodes directory.

For each node there must be a json file named after node's FQDN.

Example for nodes/ryoko.tanabata.dev.json

{
    "run_list": [ "role[tanabata-base]",
                  "role[solo-env-dev]",
                  "role[ryoko_tanabata_dev]"
                ]
}

Try not to include in run-list anything but roles. If you want to add specific recipe it should go to node's personal role. Otherwise it will create a mess hard to understand and debug by others. We will describe different role types later.

Role types

Roles in chef-cuisine are artificially divided into different types. They are all equal technically, but have logical difference. The reason is we want to combine roles and let Chef merge their run-lists and attributes. Run list get merged in the order of appearance. Attributes are a bit trickier.

Here is a picture on how chef does that for attributes. But you should read documentation for better understanding. In short, we use override level in roles and stack them to have predictable attributes merge starting from setting most general attributes in the start of run-list and leaving more specific at the end.

Basic role

The most generic role that should be applied to all nodes in infrastructure. It's the first role in run-list. It's a good place to add recipes configuring timezones, ntp, users, firewalls, etc.

Functional role

Roles to configure some piece of functionality like web frontend, database or package repository. Functional roles should be usable in all environments without any modifications. They might contain some safe attribute values to be overridden by roles next in run-list.

Environment role

Roles that emulate chef environments. Contain only attributes, no run-list items allowed.

You may ask why don't we use real Chef environments, as they are supported even in chef-solo? The answer is in attribute merge precedence. Let's look at following example for imaginary two node cluster.

{
"run_list": [ "role[tanabata-base]",
              "role[relay-cluster]",
              "role[solo-env-dc2]",
              "role[solo-env-relay-dc2]",
              "role[relay01_dc2_tanabata_tld]"
            ]
}

If we are using real environment for solo-env-dc2, then a base role's attribute will override attributed from environment. Ok, we could use default level for attributes in base and functional roles and use override in environment, but then we couldn't have node-specific roles. Ok, we could use force_override and set attributes in node's attribute file, not in role. But then how could we add sub-environment for relay-dc2 cluster? No way to do it, and we already get counter-intuitive system very hard to understand and maintain.

Environments could have been usable for us if steps 3-4 and 11-12 were switched. But they are not. OpsCode Chef Software Inc. says it's done this way for scenario when a role uses default level for attributes and Env may override it. But in such scenario we are unable to have specific attributes for groups of nodes or single nodes.

So the solution with emulating environments via roles is more flexible, predictable and easier to understand and maintain.

Node-specific role

Here goes everything related to one particular node only. Network configuration, ssh keys, password, local kludges.

Node roles are named afer node's FQDN, but with dots replased by underscore. Use undescrore instead of dots and dash instead of space to avoid problems with parsing role names.