[chef] Re: How do I set up this infrastructure?

[Ranjib Dey < >]

as you have already mentioned per site environment is one way to solve this, and if you are using ruby, you can reuse the common bits (like all prod_x, prod_y etc can read prod.jb/json and just adds their own customization), which will greatly reduce maintenance headaches.

if feasible, explore alternate ways of addressing customization instead of versioning. If a cookbook is reused across multiple environments/roles, identify the differentiating code bits, and drive them via attributes, which can be overridden per role or per environment. This way you can group similar stuff in roles and override those specific attributes. Avoid using override or set attributes, in practice i have found chef's default attribute precedence level is more than enough for role and environment specific overrides (you need the other only if some intermediate role or wrapper cookbook is using other precedence level), you wont hit any attribute precedence related surprise or complexity if you stick the limited and known use of attribute precedence. Also modeling similar nodes with same roles will allow you to group them easily,

hope this help,

ranjib

On Thu, Aug 7, 2014 at 10:24 AM, Bellinger, Matthew < " target="_blank"> > wrote:

Hello Chefs,

 

The project I am working on has a server infrastructure that does not seem to fit the ‘norm’ that I would infer from chef documentation where all servers in an environment share the same version of a cookbook.  So I am looking for help on how I would set up my cookbooks, environments, etc in order to fit our infrastructure.  Our typical server has a bunch of software on it that we have cookbooks for, all pretty normal stuff.  The weird part comes in when we need to update different environments and sites.  By site, I mean a different configuration for that location, such that the cookbook versions for that site may be different than another site in that same environment.

 

For example, we have production, test, and development environments.  Attributes and cookbook versions may be different in those environments depending on what stage of the process we are on in those environments.  Each environment has a bunch of ‘sites’ that we deploy our software to.  So what we are trying to do is have development with sites A, B, C, and D, with versions 1.1, 1.2, 1.3, and 1.5 of a cookbook respectively.  Test may have sites A, B, C, and D with versions 1.2, 1.2, 1.4, and 1.5 of that same cookbook. While prod has sites A, B, C, and D with versions 1.1, 1.1, 1.2, and 1.3 respectively.

 

The problem that I am trying to avoid is updating the environment for production to say ‘use version 1.5 of cookbook’ for when I want to update site D, but have all of the rest of the sites also update to that because they use the same environment.  Is the only solution to this problem to have a chef environment “per-site-per-environment”?  Having ~20 sites and 2-4 environments would seem to be a nightmare for making sure things are properly configured when moving between environments for a site, but so far it looks like the only solution.  What do you think?

 

Thanks,

~Matt Bellinger

 

This message is intended only for the addressee and may contain information that is company confidential or privileged. Any technical data in this message may be exported only in accordance with the U.S. International Traffic in Arms Regulations (22 CFR Parts 120-130) or the Export Administration Regulations (15 CFR Parts 730-774). Unauthorized use is strictly prohibited and may be unlawful. If you are not the intended recipient, or the person responsible for delivering to the intended recipient, you should not read, copy, disclose or otherwise use this message. If you have received this email in error, please delete it, and advise the sender immediately.