How do I set up this infrastructure?


#1

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.


#2

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 <
Matthew.Bellinger@saabsensis.com> 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. *