[chef] Re: Re: how to set up cluster that has dependencies?

[Noah Kantrowitz < >]

On Sep 21, 2011, at 7:18 PM, Aaron Abramson wrote:

> The best thing to do would be to go through one of the getting-started 
> tutorials: http://help.opscode.com/kb/otherhelp/build-a-lamp-stack
> 
> Watch that, follow along and deploy it yourself (if you have access to 
> EC2), or just read through it.  It will give you a good idea on how nodes 
> can query and search within templates.
> 
> Look through the php-quick-start repo, the haproxy cookbook searches chef 
> for the apache nodes and updates the templates accordingly.
> 
> ----- Original Message -----
> From: "jeff stroomer" 
> <
 >
> To: 
> 
 
> Sent: Wednesday, September 21, 2011 7:00:17 PM GMT -06:00 US/Canada Central
> Subject: [chef] how to set up cluster that has dependencies?
> 
> Chef folks,
> 
> I have a question concerning the best way to use Chef to set up a cluster of
> nodes that have dependencies on one another. (Apologies in advance if this 
> is a
> naïve question, but I’m new to Chef.)
> 
> For concreteness, suppose I want node  V  to run varnish, node T to run 
> tomcat,
> and node  M to run mongo.  And let’s say that T needs to know the IP address
> of M, and V needs to know the IP address of T.        I believe  that each 
> node can
> register its IP address in a database maintained on the Chef server, and
> recipes run by each node can query this database.  For things to work 
> properly,
> I ought to set up M first, then T, and finally V.  
> 
> My question is this: How I should plan to use Chef so that the setup of 
> various
> nodes happens in the right order?  Do  I write a recipe that sets up M 
> first,
> then T, and finally V?         If so, then what is that recipe associated 
> to?  Or
> should I instead have a recipe for V that sets up T, and also  have the 
> setup
> recipe for T begin by setting up M?  Or should I write recipes for T, M, 
> and V
> that query the database, and don’t do anything unless they can find the IP
> addresses they need?

Chef doesn't (yet) address this kind of multi-node orchestration issue. 
search() does make the integration parts easy, but that isn't enough to 
handle a highly fluid environment sometimes. One option is just careful 
recipe construction, usually just making the Chef run abort early if a search 
for a needed component comes up empty can do the trick, as long as you run 
Chef in polling mode on a tight cycle. Another option is to use something 
like RunDeck or Fabric to execute chef-client in the correct order and not 
move on with the deployment until certain gate conditions are met. Beyond 
that you enter into the world of tools like Noah and ZooKeeper, which are 
built very specifically for this. Noah is somewhat new, but is also less 
encumbered by legacy Java craziness compared to ZooKeeper. ZooKeeper is 
probably your best bet though, as it has a powerful and flexible set of 
distributed locking and configuration primitives. We (Opscode) are also very 
interested in exploring this space as it is indeed a common problem and while 
we don't want to end up with a poor reimplementation of one or all of these 
something with tighter integration to Chef recipes would be awesome. Hope 
that helps!

--Noah

PS: Also a semi-related shootout to AJ's new pylon tool to do distributed 
master elections.

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail