[chef] Re: Re: Re: RE: Re: Single chef server vs. multiple chef servers - pros and cons?

[Mathieu Martin < >]

I'm also going through this thought process right now. Helping multiple independent teams manage their part of the infrastructure with Chef.

Per team environments or environment cookbooks can help each team manage their own dependencies their own way. This could look like product1_production, product1_staging, product2_production, etc. That can easily live in one Chef server.

But a single Chef server has one cookbook namespace. This can cause problems between teams with different philosophies or skill levels with Chef. E.g. if a team decides to create a custom "mysql" cookbook and upload that, this prevents all other teams from using the community "mysql" cookbook.

So right now, I'm leaning towards either a chef org per team in hosted chef, or one chef server per team, to get one "cookbook namespace" per team.

On the other hand, I'm still wondering how much work we'll have to do, to copy information between those distinct Chef environments (e.g. credentials shared between systems managed by different teams).

Cheers,

Mat

On Thu, Oct 23, 2014 at 11:10 AM, Torben Knerr < " target="_blank"> > wrote:

In this context you might also consider using a "top-level cookbooks" approach where you lock only the top-level (per node) cookbooks in the environment, not the whole dependency graph:
http://lists.opscode.com/sympa/arc/chef/2014-01/msg00419.html

The new Policyfile approach might be an alternative, but I haven't really digested that yet.

HTH, Torben

Am 23.10.2014 15:16 schrieb "Fabien Delpierre" < " target="_blank"> >:

I don't know how cumbersome it may become, but you could use Chef environments to control the cookbook versions for each of your deployments, say environment Dev1 dictates cookbook A must use version 1.1.0 (or <=1.1.0) and version 2.1.3 of cookbook B, while environment QA2 has cookbook A at version 1.2.0 and cookbook B at version 2.2.1. I feel like that's precisely what environments are made for. It just requires a good level of rigor because it's easy to screw up. Doing it that way shouldn't have to change anything to the way you're developing cookbooks, but like I mentioned, you'll just have to be mindful of updating the version in metadata.rb.

On Wed, Oct 22, 2014 at 8:12 PM, Fouts, Chris < " target="_blank"> > wrote:

Thanks /Phil.

We're leaning toward option 1 too since we likely will be using Chef 12.

With a single Chef server, how do developers upload their cookbooks without stepping all over each other? I understand that one approach is for each developer to be an organization, but I've read where this is discouraged.

Chris
________________________________________
From: " target="_blank"> [ " target="_blank"> ]
Sent: Wednesday, October 22, 2014 6:19 PM
To: " target="_blank"> ; " target="_blank">
Subject: [chef] Re: Single chef server vs. multiple chef servers - pros and cons?

Chris,

Chef 12 brings multi tendency out of the box. Option 1 likely is right choice if you plan on migrating from Chef 11 to Chef12 in near term.‎ Each of your product's would have its own organization sandbox on your chef server.

-Phil

From: Fouts, Chris
Sent: Wednesday, October 22, 2014 4:51 PM
To: " target="_blank">
Reply To: " target="_blank">
Subject: [chef] Single chef server vs. multiple chef servers - pros and cons?


We have a product comprised of 12-25 nodes with a combination of RHEL and Windows OS’s. Each node has its identity dictated by the set *.msi and *.rpms we install onto it. We can have several deployments of these products throughout our lab, say 5 in the dev lab, 9 in the QA lab, 4 in the Perf lab, etc.  So if at one time we have 20 deployed products, that makes 240-500 nodes we may configure at any given time.

We have been exploring two approaches to use Chef to configure our nodes

Option 1
We have a single Chef server that contains all our cookbooks that all nodes talk to. I understand the need to segregate cookbooks under development, vs. ones for test or production. I also understand that we may need provision to make this highly-available, etc., so if one server fails we have a standby server.

Option 2
Each product is configured with its own chef server, such that the deployment of the product involves first the creation of a chef server, and then the nodes on THIS product can be deployed via this chef server. IOW, if we had 20 products deployed currently, we’ll need 20 chef servers – 1 chef server per product

Currently we orchestrate our product deployment via Jenkins

Any pros/cons to each approach?

Chris

--

Organizer of DevOpsMtl. @webmat, LinkedIn, blog.