patternMinor
Using Chef for multi-node operations
Viewed 0 times
chefmultioperationsnodeforusing
Problem
I have an application I would like to configure using Chef that spans multiple nodes. Let's say that the process of doing it consists of
One way to do this would be to write a recipe that stored the stage it was on on each node and just keep running it on both nodes repeatedly until eventually it had a chance to do all operations on all nodes. But this is clumsy and won't scale if there's node C, D, etc. I obv know about notify to sequence dependencies within a single node, but that won't work across multiple nodes. I can't be the only person who needs this, so is there a mechanism or a design pattern/best practice/TTP for this style of activity?
- Do a thing on node A capturing the output
- Do another thing on node B with that output
- Back to node A now for some operation
- Now on node B again
- ...
One way to do this would be to write a recipe that stored the stage it was on on each node and just keep running it on both nodes repeatedly until eventually it had a chance to do all operations on all nodes. But this is clumsy and won't scale if there's node C, D, etc. I obv know about notify to sequence dependencies within a single node, but that won't work across multiple nodes. I can't be the only person who needs this, so is there a mechanism or a design pattern/best practice/TTP for this style of activity?
Solution
In short, Chef may not be the tool to use here.
Chef is a convergent model, so you have to write your recipes in an idempotent way such as after some runs it will be at the desired state according to the others nodes around.
Your approach about storing the state sounds the way to go, and you'll have to use an external orchestrator to schedule the chef-client runs alternatively on A and B.
If you have a chef-server, push jobs could be the way to go sticking in chef ecosystem, main advantage I see with it compared to others orchestrators is a pull model not needing an incoming administrative port nor ssh on the target nodes.
Chef is a convergent model, so you have to write your recipes in an idempotent way such as after some runs it will be at the desired state according to the others nodes around.
Your approach about storing the state sounds the way to go, and you'll have to use an external orchestrator to schedule the chef-client runs alternatively on A and B.
If you have a chef-server, push jobs could be the way to go sticking in chef ecosystem, main advantage I see with it compared to others orchestrators is a pull model not needing an incoming administrative port nor ssh on the target nodes.
Context
StackExchange DevOps Q#2374, answer score: 6
Revisions (0)
No revisions yet.