General discussion about Chef

[chef] Re: Re: Re: Re: Re: Environment Inheritence


Chronological Thread 
  • From: Ranjib Dey < >
  • To: " " < >
  • Subject: [chef] Re: Re: Re: Re: Re: Environment Inheritence
  • Date: Thu, 18 Jun 2015 13:44:06 -0700
yeah exactly. i dont follow those pattern, in fact i cant recall reading many of them, after sometime there were too many i could not connect the dots. I try to use the original chef style.,. which is single repo for the org, with berks integration so that we can churn out community cookbooks (both ways, consume and publish), as well as if any service /app team wants to take over their cookbooks, they are more than welcome. roles are more like aggregation units, that assemble community/core stuff along with service ..and attribute driven customization mostly uses default precedence, if they are service specific, they go to roles (like nginx connection limit, db memory settings), if the customizations are global (like dns, ldap) they go to environment. some of these cross environments settings are common hence the yaml trick, else we would have something like base env. But till now i never felt like we'll need deeper nesting (not sure if its good as well),, general topology of chef domain objects (cookbook, role, environments) is similar to standard OOP strategy.. have no more than 3 (shallow ) nesting (roles, envs).. with lot of mixins (cookbooks). Some of the top level mixins (wrapper or applications cookbooks) needs to be bit more intelligent hold more logic,, they distribute that logic between hwrps,lwrps, modules, gems etc.
hth

On Thu, Jun 18, 2015 at 1:34 PM, Douglas Garstang < " target="_blank"> > wrote:
Yoshi,

So, you basically have a role called common-env (or whatever), set common attributes there, and then include the common-env in your run list as well as the functional (ie web-server, apache-server etc) role?

Douglas.

On Thu, Jun 18, 2015 at 12:52 PM, Yoshi Spendiff < " target="_blank"> > wrote:
Roles and Environments have two attribute levels available, default and override, so you can do overrides either way.

https://docs.chef.io/attributes.html#attribute-precedence

In the setup here we use common or default attributes in a role cookbook and then set any environment specific overrides in an environment. That way there are no duplicated values in environments.

On Thu, Jun 18, 2015 at 11:24 AM, Douglas Garstang < " target="_blank"> > wrote:
Drew,

In our case, an environment is pinned to a physical location. For example, our 'dev' and 'qa' environment is located wholly with Amazon AWS us-east-1.

If I use the chef-client cookbook as an example, it needs to have the address of the chef server set. If I set that in a role, the 'chef-client' role, then the address of the chef server is not consistent across all locations within that role. Adding a role of 'chef-client' to a node would not adequately capture the fact that in the dev environment it needs to be one thing, while in the prod environment it needs to be something else.

If a role has a higher precedence than an environment, it sounds like creating a base role with attributes, and then setting attributes in environments would not work at all.

Doug.

On Thu, Jun 18, 2015 at 11:04 AM, Drew Blessing < " target="_blank"> > wrote:
You can create a base role with attributes that apply to all environments. Then set specific attributes in environments. Note that roles have a higher precedence than environments, though.

When you say you're heavily using environments are you overloading the definition of an environment to include locations/datacenter or something? If so, you might be abusing environments :) Roles/role cookbooks or something else might be more appropriate. Something to think about.
On Thu, Jun 18, 2015 at 12:48 PM Douglas Garstang < " target="_blank"> > wrote:
All,

I'm making pretty heavy use of environments. There's quite a fair bit of duplication and I'd like to implement a 'base' environment, with common attributes that apply to all environments. How would I do this?

What happens if the same attribute is defined in multiple environments? Are they merged together or does the 'inherited' one override the 'base' one?

Thanks,
Doug





--



--



--


Archive powered by MHonArc 2.6.16.

§