Environment/org usage

Chef Infra (archive)
1

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

2

FWIW, the thread that got us thinking about multiple orgs:

http://lists.opscode.com/sympa/arc/chef/2010-10/msg00089.html

Almost two years ago! How times flies…

3

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 brian@akins.org 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