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

[AJ Christensen < >]

Another way to manage this is to use a continuous delivery process and
only allow the CD system to upload cookbooks to cookbook storage
systems.

I like to use the golang Chef Server in-memory/journal-to-disk mode
for each phase in cookbook pipeline; add creds for CD to push
cookbooks into the system, have humans go through
review/ci/cd/.../upload procedure. You can also "fan in" all of the
latest stable jobs and assemble a cookbook asset artifact for
distribution, using the Chef Server as a staging area (again, with
limited access).

cheers,

--aj

On Thu, Oct 23, 2014 at 10:41 AM, Fabien Delpierre
<
 >
 wrote:
> Not ideal, but perhaps you can grant permissions to modify environments only
> to certain people to mitigate that risk.
>
> On Thu, Oct 23, 2014 at 1:38 PM, Fouts, Chris 
> <
 >
> wrote:
>>
>> 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 
>> <
 >
>> 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
>>
>>
>
>