[chef] Re: Using chef for our own applications/services' configuration?


Chronological Thread 
  • From: Dan Nemec < >
  • To:
  • Subject: [chef] Re: Using chef for our own applications/services' configuration?
  • Date: Fri, 25 Feb 2011 10:26:30 -0500
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=nemecfamily.com; s=snocky; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=UvWpC6vghcaW2NCAVNMoIicv2tKfv3+eWsvn3fsnrXyWgc1C/GDIKz35Suyy2thPoU qTTFYSHtKuhlxSoi16xE1h8Vqa1soBu4dDgv3nrW4s6TPY5VCFu7iZM35kfn68w5CyOd 2Srk9nMxKdc5zqSt9DYVe5k2GB6ggOi/TkrRY=

Dennis,

Welcome to my world. We started that project in earnest last fall. We have a number of environments and instances of application suites in those environments and needed desperately to simplify our application configuration. We, too, came to the conclusion that Chef looked like a good tool because of it's hierarchy of configuration and flexibility.

We spent months (literally) wrapping our heads around the problem. That was the most painful part of the process. What we came out with was a model of our environments and our data that we could plug into Chef. Do not skimp on the modelling part. I've written some about the process here http://blog.geeksgonemad.com/2011/01/chef-is-my-documentation.html. And inside that post is a link to a presentation I've made public that discusses some of our modeling in detail.

I still don't have anything posted giving examples of our choices of when we decided to use roles vs. databags, vs other Cheffy things. I'll post that to my blog soon-ish as we are in the thick of rolling out our solution right now. Once I do some demo presentations internally I'll have some material to post. We're using it to manage java properties and logging files, tomcat server.xml, apache vhosts, any configuration file that any piece of our application needs. We are even using Chef to create our Control Tier project xml files.

I will warn you that one constraint of Chef may or may not be a significant impact to how you manage and deploy configurations. Because Chef is purely a convergence tool, you cannot manage configuration files individually. There is only one giant runlist that will have to make every configuration file every run. (see my thread earlier on this mailing list about ad-hock runlists http://lists.opscode.com/sympa/arc/chef/2011-01/msg00130.html). I am conspiring with DTO Solutions (Control Tier and Rundeck) to work out ways of getting Chef to behave more like direct control than convergence. Our compromise is that we have built a process where Chef will create all configuration files but not in a live location and we will have some other piece of orchestration software deploy the necessary configuration files when the time is right.

John's post came in as I'm writing this. I agree that some of the greatest benefit we are seeing is that our configuration is now data-driven and as much as possible derivable. Having system and application configuration in one place is a really great thing.

Dan

On Fri, Feb 25, 2011 at 8:51 AM, Denis Haskin < "> > wrote:
(apologies if this has been previously asked & answered; the mailing list archives are sort of hard to use.)

We're investigating using chef, among other purposes to better manage cross-system "application" configuration.  Specifically, we have services from multiple projects running on multiple servers, and at the moment each project has their own configuration file, despite the fact that there is configuration that would be best shared among them.

I'm quite sure this could be helped by chef but I'm having a little trouble completely wrapping my head around how we would do this with chef.  Seems like all of the chef docs & tutorials are focused on provisioning and configuring services like apache, mysql, etc.  (And, as I've read elsewhere, a lot of the chef doc seems somewhat abstract and doesn't always relate these abstract concepts to concrete usage.)

Does anybody have any samples/suggestions/etc?

Thanks!

dwh




Archive powered by MHonArc 2.6.16.

§