Role driven recipes

Chef Infra (archive)
1

Ohai Chefs!

We have a cookbook that deploys applications and has a number of recipes some of which set up preliminary things like firewall settings and http proxy. We are considering using roles to drive the different roles of a node and there are two approaches we are considering:

  1. Apply roles that pull in all the relevant recipes

  2. Apply roles and one controlling recipe and then have that recipe determine the other dependencies based on the roles that have been applied.

It seems to me that the second approach means that updating that cookbook will change the way any role operates without needing to update individual roles. And any pre and post recipe action can be managed without needing to add them to every role.

Any thoughts as to the pros and cons?

Regards,
Wazza

http://ninefold.com
+61 414 867 559
@thoughtcoft

2

Hi,

On Fri, Mar 22, 2013 at 4:58 PM, Warren Bain Warren@ninefold.com wrote:

We have a cookbook that deploys applications and has a number of recipes some of which set up preliminary things like firewall settings and http proxy. We are considering using roles to drive the different roles of a node and there are two approaches we are considering:

  1. Apply roles that pull in all the relevant recipes

  2. Apply roles and one controlling recipe and then have that recipe determine the other dependencies based on the roles that have been applied.

It seems to me that the second approach means that updating that cookbook will change the way any role operates without needing to update individual roles. And any pre and post recipe action can be managed without needing to add them to every role.

Any thoughts as to the pros and cons?

My recommendation is actually to do something different. Any time you
find yourself wanting version-able logic for a role you should create
a cookbook to represent that role. See [1] for a description of this.

In our environment we have a need very similar to yours. Many of our
applications are deployed in an application server, GlassFish. Some of
the applications require custom activity before/after they are
deployed.

So what we have done is create a cookbook "fisg-server" that has
dependencies on all the system level configuration/services we need
and includes them in the right order. (i.e. ntp/firewalls/host
configs/network configs/ etc). We also have a "fisg-glassfish"
cookbook that includes a recipes from the "glassfish" cookbook and
some attribute customizations of the "glassfish" cookbook specific to
our environment.

We then have a final role cookbook "fisg-mydomain" that sets up
parameters specific to the domain. It may also include recipes for
application specific pre/post deployment customizations. Typically we
get our application deployment data out of data bags. Inside the data
bag items we include directives and that triggers include_recipe for
application customizations in the "fisg-mydomain".

All in all, we really like how easy it is to release and promote
versions of the application through different environments

[1] Role Cookbooks and Wrapper Cookbooks

--
Cheers,

Peter Donald

3

Thanks Peter, interesting how many ways this approach can be tweaked. Will think this through a bit more ...

From: peter.j.donald@gmail.com [peter.j.donald@gmail.com] On Behalf Of Peter Donald [peter@realityforge.org]
Sent: Friday, 22 March 2013 6:21 PM
To: chef@lists.opscode.com
Subject: [chef] Re: Role driven recipes

Hi,

On Fri, Mar 22, 2013 at 4:58 PM, Warren Bain Warren@ninefold.com wrote:

We have a cookbook that deploys applications and has a number of recipes some of which set up preliminary things like firewall settings and http proxy. We are considering using roles to drive the different roles of a node and there are two approaches we are considering:

  1. Apply roles that pull in all the relevant recipes

  2. Apply roles and one controlling recipe and then have that recipe determine the other dependencies based on the roles that have been applied.

It seems to me that the second approach means that updating that cookbook will change the way any role operates without needing to update individual roles. And any pre and post recipe action can be managed without needing to add them to every role.

Any thoughts as to the pros and cons?

My recommendation is actually to do something different. Any time you
find yourself wanting version-able logic for a role you should create
a cookbook to represent that role. See [1] for a description of this.

In our environment we have a need very similar to yours. Many of our
applications are deployed in an application server, GlassFish. Some of
the applications require custom activity before/after they are
deployed.

So what we have done is create a cookbook "fisg-server" that has
dependencies on all the system level configuration/services we need
and includes them in the right order. (i.e. ntp/firewalls/host
configs/network configs/ etc). We also have a "fisg-glassfish"
cookbook that includes a recipes from the "glassfish" cookbook and
some attribute customizations of the "glassfish" cookbook specific to
our environment.

We then have a final role cookbook "fisg-mydomain" that sets up
parameters specific to the domain. It may also include recipes for
application specific pre/post deployment customizations. Typically we
get our application deployment data out of data bags. Inside the data
bag items we include directives and that triggers include_recipe for
application customizations in the "fisg-mydomain".

All in all, we really like how easy it is to release and promote
versions of the application through different environments

[1] http://realityforge.org/code/2012/11/19/role-cookbooks-and-wrapper-cookbooks.html

--
Cheers,

Peter Donald