Until now, we have created cookbooks based on a particular technology. We created a cookbook for MariaDB, one for Apache HTTPd, and one for our app (including all the dependencies). What about the role of each of those infrastructure elements? A database role can include what is now running our database (MariaDB), but maybe tomorrow it can run something else (migrate back to MySQL, or switch to PostgreSQL). As roles in Chef have a dedicated run list, it's common to see a role include the product recipes, and everything related to it, think monitoring for example. Roles can do a lot more, like overriding attributes or have different run lists for each environment. Here, we'll create two generic database and webserver roles that might be simply reused later for another project that just need those services and a mysite role, that will include the two other roles. A role can include other roles as well as recipes. This way, the role for mysite will be enough to run our infrastructure, from a functional point of view.
To work through this recipe, you will need the following:
- A working Chef DK installation on the workstation
- A working Chef client configuration on the remote host
- The Chef code from the previous recipes
Follow these steps for creating functional roles:
- We can write roles in plain JSON or in Ruby. Let's try Ruby for our
webserverrole inroles/webserver.rb. It requires a name, a description, and a run list. That's the bare minimum:name "webserver" description "An HTTP server for our application" run_list "recipe[apache]"
- Let's do the same for our
databaserole; we currently want to use ourmariadbcookbook. So let's write it inroles/database.rb:name "database" description "A database server for our application" run_list "recipe[mariadb]"
- Finally, let's write the
mysiterole, that will include a webserver, a database, as well as its own cookbook, inroles/mysite.rb:name "mysite" description "MySite role" run_list( "role[webserver]", "role[database]", "recipe[mysite]" )
- Send the roles to the Chef server using the
knifecommand:$ knife role from file database.rb Updated Role database $ knife role from file webserver.rb Updated Role webserver $ knife role from file mysite.rb Updated Role mysite
- Now, either edit your current node's run list (if you have one) to use only this role (
role[mysite]), or if you're about to bootstrap the server; adding the-r "role[mysite]"option will bootstrap Chef on the node as well as execute Chef with this run list:$ knife bootstrap 192.168.146.129 -N vagrant -x vagrant --sudo -r "role[mysite]"
We'll now be free to add more complex features to our role in the future!
Puppet does not provide a role feature. However, this can be done by adding a level of abstraction using the role and profile design pattern. In this pattern:
- A role is a class defining a behavior (For example, a web server). This class needs to include all needed profiles to create the role.
- A profile is a class used to manage the underlying technology (For example, by installing Apache)
- In the main manifest, nodes are only using roles.
Using this pattern, it is easier to refactor only profiles classes when the technology needs to be changed.
- The Chef documentation on roles: https://docs.chef.io/roles.html