I should’ve read your question more carefully… You want to actually host Chef like Opscode Platform for various outside companies (as in “clients”). Yeah, if that’s the case, the simplest option would be to maintain separate repos/servers, etc for each client. You can’t really use the same chef server for different clients, because you might run into namespace collisions, where different clients might have “apache” cookbooks that do different things. Unless Opscode open-sources the code to Opscode Platform, you’ll need to maintain separate servers, or somehow figure out a way to extend Chef on your own to support multiple clients. -Paul From: Alex Soto [mailto:
Sent: Tuesday, October 19, 2010 11:12 AM
To:
Subject: [chef] Re: Re: Re: Organizing multiple "clients" and cookbooks If I were you I would maintain separate chef repo's/servers/platform orgs per Client. On Oct 19, 2010, at 8:04 AM, Brian Akins wrote:
On Tue, Oct 19, 2010 at 9:10 AM, Seth Chisamore <
">
> wrote: The DRYest approach would be common cookbooks with individual roles per client. The roles could override unique client attributes, things like apache, tomcat and mysql tuning parameters...or ports that apache runs on. Since each role also has it's own run_list it would allow you to account for the different groupings of software each client may also have (ie some clients use apache only, no tomcat).
Unfortunately, I'm not sure that will work. Each of our "clients" is probably larger than the average chef user's complete infrastructure in size and complexity. Imagine several large web companies with a single operations group... For example, client "A" may have 4 different application "stacks": - apache -> tomcat -> mysql - varnish -> apache -> NFS mounts - apache + wsgi python app -> memcache + mysql - varnish -> proprietary app server -> who knows what and also have development, reference, and productions environments for each of those. Clients B and C may have some of the same components, but in a completely different layout. Granted, we have been standardizing more, but this is the unfortunate place we find ourselves in now. Our first deployments will be for some of the more "standardized stacks" we have, so we have some time to figure it out, I hope. |