[chef] RE: Re: Role driven recipes

[Warren Bain < >]

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

 
 

 
 On Behalf Of Peter Donald 

 
Sent: Friday, 22 March 2013 6:21 PM
To: 

 
Subject: [chef] Re: Role driven recipes

Hi,

On Fri, Mar 22, 2013 at 4:58 PM, Warren Bain 
<
 >
 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