Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We have > 20 individual apps that we support. Most do not see changes more than a couple times a year. We think chef will help us down the line.

I am trying to find a happy medium between manual configuration and automation. I have two pretty good questions:

1) Is it smarter to setup one chef server with cookbooks and roles for each of our apps? Or should we isolate each project, and have a chef-server for each app?

2) (If we have multiple chef servers out there) How should I manage multiple chef-servers? With another chef server? chef-solo?

I see many articles documenting how to setup chef, or covering features, but I haven't seen a really good one documenting how somebody is actually using chef in a medium-large, production environment. Some tips in that direction could be nice.


share|improve this question
One chef server is good for many applications. You just need to backup it once, since it contains the configuration states. There is no problem with scaling chef in a way it supports multiple apps. – Andrew Smith Dec 31 '12 at 19:37
Thank you, do you have any tips on keeping it organized when there are potentially 100+ roles, even more cookbooks, multiple environments and different geographic locations (some standby)? If that's not clear, it might be worth separating it into a couple other questions. If you know of a good article dealing with multiple applications in one chef, I couldn't find one, it would be super helpful!! – Jeff V Jan 1 '13 at 0:20
up vote 3 down vote accepted

The main question is a bit tricky. The glib answer for how much abstraction is "not too much, but not too little". Only slightly more seriously, it's something that you really have to work out for yourself as it depends on a lot of factors.

A good first step would be to create a "basenode" configuration (a role and environment attributes) have all your nodes managed by Chef. This may include a bunch of existing community cookbooks such as:

At this stage your apps would be configured and installed by hand on top of the base nodes.

Now you should have a better idea of how Chef works so you can start to think about what more domain-specific cookbooks would look like. Continue working bottom up and write cookbooks to install the packages required for your apps and use attributes and data bags to configure them. There may be some commonality between the 20 apps you mention (they are mostly Rails apps, for example) that you can factor out into a common set of recipes.

You make a good point about finding a medium between manual configuration and automation. One of the traps that I fell in to when starting out with Chef was to try and automate as much as possible. This ends up turning into a nightmare of corner cases and weird bugs that are fixed by restarting a service by hand or rebooting the node. Not fun to maintain and debug. These days I try to stick to the package, file and template resources as much as possible.

Having 100 roles does sound a bit over the top, but I don't know any more details about your situation. I tend to work with more generic roles like "Apache-Server" or "RabbitMQ-Server" and then use various combinations of attributes, data bags and more specific roles to personalise each node.

share|improve this answer
Yes - we are still wading through things. I imagine we can collapse a lot of similarities. I appreciate your answer. I think just talking it out helps with the confusion. – Jeff V Jan 9 '13 at 20:11

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.