Single chef server vs. multiple chef servers - pros and cons?

Chris_F · October 22, 2014, 8:51pm

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

Philoliva8 · October 22, 2014, 10:19pm

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, ChrisSent: Wednesday, October 22, 2014 4:51 PMTo: chef@lists.opscode.comReply To: chef@lists.opscode.comSubject: [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

Chris_F · October 23, 2014, 12:12am

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: philoliva8@gmail.com [philoliva8@gmail.com]
Sent: Wednesday, October 22, 2014 6:19 PM
To: chef@lists.opscode.com; chef@lists.opscode.com
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: chef@lists.opscode.com
Reply To: chef@lists.opscode.com
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

Shubby · October 23, 2014, 1:15pm

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 Chris.Fouts@sensus.com
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: philoliva8@gmail.com [philoliva8@gmail.com]
Sent: Wednesday, October 22, 2014 6:19 PM
To: chef@lists.opscode.com; chef@lists.opscode.com
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: chef@lists.opscode.com
Reply To: chef@lists.opscode.com
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

tknerr · October 23, 2014, 3:10pm

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" fabien.delpierre@gmail.com:

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 Chris.Fouts@sensus.com
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: philoliva8@gmail.com [philoliva8@gmail.com]
Sent: Wednesday, October 22, 2014 6:19 PM
To: chef@lists.opscode.com; chef@lists.opscode.com
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: chef@lists.opscode.com
Reply To: chef@lists.opscode.com
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

Mathieu_Martin · October 23, 2014, 4:03pm

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 mail@tknerr.de 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:
chef - [chef] Re: What to pin in environments?

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" <fabien.delpierre@gmail.com

:

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 Chris.Fouts@sensus.com
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: philoliva8@gmail.com [philoliva8@gmail.com]
Sent: Wednesday, October 22, 2014 6:19 PM
To: chef@lists.opscode.com; chef@lists.opscode.com
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: chef@lists.opscode.com
Reply To: chef@lists.opscode.com
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 http://www.devopsmtl.com. @webmat
http://twitter.com/webmat, LinkedIn
http://ca.linkedin.com/in/mathieumartin/, blog
http://www.programblings.com?utm_source=email+signature.

Chris_F · October 23, 2014, 5:38pm

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:fabien.delpierre@gmail.com]
Sent: Thursday, October 23, 2014 9:16 AM
To: chef@lists.opscode.com
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 <Chris.Fouts@sensus.com mailto:Chris.Fouts@sensus.com> 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: philoliva8@gmail.com mailto:philoliva8@gmail.com [philoliva8@gmail.commailto:philoliva8@gmail.com]
Sent: Wednesday, October 22, 2014 6:19 PM
To: chef@lists.opscode.com mailto:chef@lists.opscode.com; chef@lists.opscode.com mailto:chef@lists.opscode.com
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: chef@lists.opscode.com mailto:chef@lists.opscode.com
Reply To: chef@lists.opscode.com mailto:chef@lists.opscode.com
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

Shubby · October 23, 2014, 5:41pm

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 Chris.Fouts@sensus.com
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:fabien.delpierre@gmail.com]
Sent: Thursday, October 23, 2014 9:16 AM
To: chef@lists.opscode.com
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 Chris.Fouts@sensus.com
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: philoliva8@gmail.com [philoliva8@gmail.com]
Sent: Wednesday, October 22, 2014 6:19 PM
To: chef@lists.opscode.com; chef@lists.opscode.com
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: chef@lists.opscode.com
Reply To: chef@lists.opscode.com
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

AJ_Christensen2 · October 23, 2014, 5:45pm

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
fabien.delpierre@gmail.com 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 Chris.Fouts@sensus.com
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:fabien.delpierre@gmail.com]
Sent: Thursday, October 23, 2014 9:16 AM
To: chef@lists.opscode.com
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 Chris.Fouts@sensus.com
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: philoliva8@gmail.com [philoliva8@gmail.com]
Sent: Wednesday, October 22, 2014 6:19 PM
To: chef@lists.opscode.com; chef@lists.opscode.com
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: chef@lists.opscode.com
Reply To: chef@lists.opscode.com
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

kallistec · October 23, 2014, 5:47pm

On Thursday, October 23, 2014 at 10:38 AM, 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

This isn’t viable in the short term, but we’re working on some features to address these problems (the “Policyfile” feature mentioned earlier in this thread). There’s a lot of information in the release announcement for ChefDK 0.3.0: ChefDK 0.3.0 Released! Introducing Policyfiles - Chef Blog | Chef

I can’t give you a timeline for when we expect this to be production ready, but it’s something you might wish to consider if you’re considering making drastic changes to your workflow.

--
Daniel DeLeo

Chris_F · October 23, 2014, 6:13pm

Yes, I'll look into the PolicyFile feature. Thanks!

Chris

-----Original Message-----
From: Daniel DeLeo [mailto:ddeleo@kallistec.com] On Behalf Of Daniel DeLeo
Sent: Thursday, October 23, 2014 1:47 PM
To: chef@lists.opscode.com
Subject: [chef] Re: RE: Re: RE: Re: Single chef server vs. multiple chef servers - pros and cons?

On Thursday, October 23, 2014 at 10:38 AM, 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

This isn’t viable in the short term, but we’re working on some features to address these problems (the “Policyfile” feature mentioned earlier in this thread). There’s a lot of information in the release announcement for ChefDK 0.3.0: ChefDK 0.3.0 Released! Introducing Policyfiles - Chef Blog | Chef

I can’t give you a timeline for when we expect this to be production ready, but it’s something you might wish to consider if you’re considering making drastic changes to your workflow.

--
Daniel DeLeo

Yauhen_Artsiukhou · October 24, 2014, 10:00am

After first read, policy file looks very complicated. Especially if I have
many cookbooks with its own policyfiles. How it would be merged?

To solve environment-cookbook pattern with berkshelf I've decided to remove
cookbook itself and leave only Berksfile with list of top-level cookbooks.
This Berkfile has two sources:

Berkshelf API (proxy to my Chef Server, hope berkshelf will work with
chef server api directly in next releases)
Community Site

Now you can do something like 'berks install', 'berks upload' for updating
cookbook information.
Then, stage by stage you can do:

berks apply dev
knife ssh "chef_environment:dev" "sudo chef-client # force global
reconfiguration
berks apply qa
knife ssh "chef_environment:qa" "sudo chef-client # force global
reconfiguration
Test all
berks apply production

2014-10-23 21:13 GMT+03:00 Fouts, Chris Chris.Fouts@sensus.com:

Yes, I'll look into the PolicyFile feature. Thanks!

Chris

-----Original Message-----
From: Daniel DeLeo [mailto:ddeleo@kallistec.com] On Behalf Of Daniel DeLeo
Sent: Thursday, October 23, 2014 1:47 PM
To: chef@lists.opscode.com
Subject: [chef] Re: RE: Re: RE: Re: Single chef server vs. multiple chef
servers - pros and cons?

On Thursday, October 23, 2014 at 10:38 AM, 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

This isn’t viable in the short term, but we’re working on some features to
address these problems (the “Policyfile” feature mentioned earlier in this
thread). There’s a lot of information in the release announcement for
ChefDK 0.3.0:
ChefDK 0.3.0 Released! Introducing Policyfiles - Chef Blog | Chef

I can’t give you a timeline for when we expect this to be production
ready, but it’s something you might wish to consider if you’re considering
making drastic changes to your workflow.

--
Daniel DeLeo

kallistec · October 24, 2014, 3:58pm

Forked this to a new topic.

On Friday, October 24, 2014 at 3:00 AM, Yauhen Artsiukhou wrote:

After first read, policy file looks very complicated. Especially if I have many cookbooks with its own policyfiles. How it would be merged?

You only have one Policyfile per functional server role, e.g., a specific web application, front-end LB, etc. Maybe you could have them for individual cookbooks as part of your testing flow, but you wouldn’t ever send those to your Chef Server, you’d just use them to get dependencies for local tests.

Also, you don’t merge Policyfile.lock.json documents, these describe the full set of cookbooks you’ll use to configure a host to fulfill a given role in your infrastructure. This gives you a guarantee that the exact code you test locally is the exact code that you test in staging/qa/etc is the exact code that you run in production.

To solve environment-cookbook pattern with berkshelf I've decided to remove cookbook itself and leave only Berksfile with list of top-level cookbooks.
The Policyfile is like the environment cookbook pattern but without the environment cookbook.

This Berkfile has two sources:

Berkshelf API (proxy to my Chef Server, hope berkshelf will work with chef server api directly in next releases)

That is up to the Chef team, not the Berks team. But a ‘universe’ endpoint is planned for the server, see this accepted RFC: https://github.com/opscode/chef-rfc/blob/master/rfc014-universe-endpoint.md

When that’s added, Policyfiles will also support using your Chef Server as an artifact storage location.

Community Site

Now you can do something like 'berks install', 'berks upload' for updating cookbook information.
Then, stage by stage you can do:

berks apply dev

knife ssh "chef_environment:dev" "sudo chef-client # force global reconfiguration

berks apply qa

knife ssh "chef_environment:qa" "sudo chef-client # force global reconfiguration

Test all

berks apply production

Policyfiles work the same way, you use chef push instead of berks apply.

HTH, and happy to chat more,

--
Daniel DeLeo

Topic		Replies	Views
Chef Infrastructure Layout Chef Infra (archive)	2	590	January 4, 2016
Chef Solo experience / best practices? Chef Infra (archive)	6	582	November 7, 2012
Apply cookbooks on multiple nodes at same time Chef Infra (archive)	2	904	October 29, 2014
Environment/org usage Chef Infra (archive)	2	264	July 26, 2012
RE: Correct use of Chef Chef Infra (archive)	1	302	November 11, 2014

Single chef server vs. multiple chef servers - pros and cons?

Related topics