It is a way to define certain patterns and processes that exist across nodes in a organization as belonging to single job function. Each role consists of a run list and zero (or more) attributes.
Advantages and Disadvantages:
- Roles can not be versioned.
- It is easier to search for Chef nodes in a role than Chef nodes that ran a recipe.
- They're intended to be a lightweight way to group servers that shouldn't contain much business logic.
Example:
I have a base role and it contains three recipes in its run list: recipe[ntp::client], recipe[chef-client::config], recipe[chef-client]. If I want to add a fourth recipe, recipe[openssh], I’m faced with adding that across all machines that run the base role and deploying it right away. I might break my entire infrastructure that way! This is terrible, right? Yes, it is, which is why folks invented the idea of the role cookbook with one or more recipes emulating the run list of that role using include_recipe:
include_recipe "ntp::client"
include_recipe "chef-client::config"
include_recipe "chef-client"
Now if I need to add recipe[openssh] to the run_list, I can modify this recipe, adding include_recipe openssh, bump the cookbook version, and deploy it across my environments in a controlled way.
Another reason why roles are still valuable: Chef Server has an index for roles, so you can dynamically discover other machines based on their role (function)
webservers = search(:roles, 'role:my_corporate_webservers')
A sample of a role cookbook
roles/sample-role.rb
name "sample-role"
description "httpd-server"
run_list("recipe[httpd-sample]")
cookbooks/httpd-sample/metadata.rb
name "httpd-sample"
description "Setup up httpd-server"
version "0.1.2"
...
depends "git"
cookbooks/httpd-sample/recipes/default.rb
include_recipe "git"
include_recipe "httpd"
Reference docs click here realityforge, chef