[chef] Re: Re: Re: Environment attributes in Cookbooks.

[Tensibai < >]

May you explain why you can't have multiple chef.add_recipe in your vagrant file ?

I really don't understand where you're stuck.

Le 2015-06-22 17:51, Douglas Garstang a écrit :

Torben,

We're definitely going along the path of using environments for dev, qa, stage, prod etc. What you posted above was really useful, except that it doesn't help with the testing issue which is kinda the blocker here. If I can't test it, well I can't really use it. :(

Doug.

On Sun, Jun 21, 2015 at 6:39 AM, Torben Knerr < "> > wrote:

Hey Doug,

 

I believe you first have to decide for what purpose you actually want to use Chef environments, and this decision then limits the options for technically implementing this.

 

For me the key decision is:

a) if you are going to use the berkflow / the environment cookbook pattern with `berks apply environment`, then this means you will end up with one environment per node

b) if you are going to use environments for dev / test / staging / prod stages, you probably want to share environmental attributes across many nodes 

 

 

Personally, I prefer b) and try to stick to the following principles:

- use environments only for supplying environment specific data

- don't use environment for composing a node's run list or other node specific internals 

- instead I use a single "top-level" wrapper cookbook per node, which 

   * glues together the run list

   * sets attributes for configuring the wrapped cookbooks

   * sometimes adds addional glue code

   * locks the whole cookbook dependency graph via metadata.rb (so I can do it per node here and not need to use an environment for that)

   * defines the interface for the user (i.e. README, attributes, etc..)

- the environments should contain only environment specific attribute overrides + the versions of the "top-level" cookbooks 

 

 

Since I'm wrapping other cookbooks and setting their attributes in (the "top-level" cookbook's) recipe, I'm sometimes faced with the "computed attributes problem". I tackle that by reloading the wrapped attributes file between setting the attributes and including the recipe, e.g. here:

https://docs.chef.io/chef/essentials_cookbook_recipes.html#reload-attributes

 

Also, my environments often share the same data, i.e. common attributes that are environmental data but still the same for many or even all of my environments. Ranjib recently posted a nice way on how to deal with that:

https://gist.github.com/ranjib/2f7e1482a3ac8f6e5bfc

 

Hope that helps or at least gives you some more ideas. There are many ways and even more opinions ;-)

 

Cheers,

Torben

 

 

 

On Fri, Jun 19, 2015 at 4:22 PM, Douglas Garstang < "> > wrote:

If I was going to put move my environmental attributes into cookbooks...

When deployed to an instance, the top level run list would need to include the environmental run list. That's ok.

However, when testing, this would mean that each cookbook would need to either include the environment cookbook (ie #include_recipe "env-dev") and refer to it in the metadata.rb and Berksfile files, OR I'd have to specifically put each attribute into the Vagrantfile's json data.

This might work for simple cookbooks, but it would mean the cookbook is not being effectively tested. The attributes I'm testing against aren't what really gets deployed to an instance. I also have to maintain two copies of the attributes and the worst case scenario is where the attribute is set in both places but the value in the Vagranrfile is incorrect and therefore leads to the incorrect assumption that the cookbook is working correctly.

For my base cookbook it gets even worse. It would need to have every single attribute from every cookbook it includes put into the Vagrantfile's json data. This just does not scale.

It doesn't seem like the benefits of gaining some revision control outweigh the maintenance disadvantages here. For all those that espouse the use of putting environment attributes into a cookbook how do you get around this?

Doug

--

Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: ">
Cell: +1-805-340-5627