[chef] Re: Environment/org usage

[Edward Morbius < >]

Could you give some more concrete examples of the environments you've
got and/or how they relate to one another?

Are your environments and roles scoped rationally?  Or is there a poor
mapping of your domain space onto the classification?

We're just getting started ourselves, but I'd be interested in seeing
more discussions of how people organize things.

One approach a team member is advocating (I've got reservations) is
spinning up distinct chef servers for what amount to "role"
designations, given my limited understanding of what we're doing and
what Chef can do.

This leaves central coordination of management in the Chef git
repository itself.  Though depending on what's been knifed to various
servers, could result in discrepancies among them, again, as I
understand things.

On Wed, Jul 18, 2012 at 5:25 AM, Brian Akins 
<
 >
 wrote:
> In chatting with people and reading the lists, I think we are doing
> something wrong at $DAYJOB.  Most people seem to have very few
> environments - single digit.  I just looked and we have 110!
>
> Also, it seems most people really only support a relatively few number
> of "products/projects." These production/projects may have a number of
> components (cookbooks) but mainly support a single "business."
>
> One of the reasons we have so many environments is we support 15 or so
> distinct customers/business units and we have a handful of
> environments (your typically dev/ref/prod/testing) for each.  We also
> support our base infrastructure (DNS, "Cloud", etc) from the same chef
> organization.
>
> FWIW, we have 787 roles! I'm pretty sure only about half of them have
> no nodes in them.  We support a few to several thousand nodes. We are
> the "shared services" and operations for all these customers/business
> units. Several of these business units have their own distinct
> development staffs as well.
>
> So, lots of the best practices that seem to have emerged around
> environments, etc, have been difficult for us to do just from the
> shear number of distinct "units" we have.
>
> We used to run open-source chef server, so a single "org" was all that
> was possible. We now are running private chef. Our current thinking is
> that we should split each of these business units into their own chef
> organization. We loose the "single unified CMDB" but I think the trade
> off is worth it.  We hacked together a little tool that allows us to
> do cross org searches. We hope that we can begin to develop and apply
> best practices across these orgs, while being able to handle the
> idiosyncrasies of each business unit. Currently everyone gets the same
> level of "meh"
>
> I really like librarian-chef for managing cookbooks.  We've been
> creating each cookbook in its own git repo recently. This works well
> for shared things like nginx, mysql, etc.  We are wondering should the
> business unit specific cookbooks like in the site-cookbooks of each
> org -- each org would be its own git repo -- or should we they be
> treated the same as the "base" cookbooks.
>
> This was scattered I know, but wanted to get people's thoughts.
>
> --Brian



-- 
Dr. Ed Morbius
Chief Scientist / Philologist / Robot Wrangler / Powerplant Operator
Krell Power Systems Unlimited