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

[Torben Knerr < >]

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" < "> >:

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