Thanks Phil, I’m doing this NOW, and yes, I’m disciplined enough to update my metadata.rb files, and to pick up the correct version in my environments. However,
one flaw of Chef (IMO) is that environments and roles are not versioned, so someone can upload an environment with a bad cookbook version to the Chef server. IOW, there is no built-in Chef mechanism to catch this “easy to screw up” process.
Chris
From: Fabien Delpierre [mailto:
Sent: Thursday, October 23, 2014 9:16 AM
To:
Subject: [chef] Re: RE: Re: Single chef server vs. multiple chef servers - pros and cons?
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:
">
[
">
]
Sent: Wednesday, October 22, 2014 6:19 PM
To:
">
;
">
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:
">
Reply To:
">
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
|