我有一个我想使用Chef进行配置的应用程序，该应用程序跨越多个节点。假设执行该过程的过程包括


在节点A上执行某项操作以捕获输出
在节点B上执行另一项操作并使用该输出
返回现在可以在节点A上进行某些操作
现在再次在节点B上进行操作
...

一种方法是编写一个配方，将其存储在每个节点上节点，然后继续在两个节点上重复运行它，直到最终它有机会在所有节点上执行所有操作。但这很笨拙，如果存在节点C，D等，则无法扩展。我观察到有关通知单个节点内的序列依存关系的通知，但不适用于多个节点。我可能不是唯一需要此服务的人，所以是否有这种活动方式的机制或设计模式/最佳实践/ TTP？

#1 楼

简而言之，Chef可能不是这里使用的工具。

Chef是一种收敛模型，因此您必须以幂等的方式编写食谱，例如在某些运行之后它将处于所需状态根据周围的其他节点。

您存储状态的方法听起来很可行，而且您必须使用外部协调器来安排主厨客户端在A和B上的交替运行。
如果您有厨师服务器，则推动工作可能成为坚持厨师生态系统的一种方式，与其他协调者相比，我认为它的主要优势是无需引入管理端口或在目标上使用ssh的拉模型节点。

#2 楼

这是服务器编排的教科书示例，Chef本质上不打算这样做。正如Tensibai所指出的，运行Chef的服务器是一个融合系统，它可以根据由配方，属性，数据包等设置的配置设置来达到自己的期望状态。在不涉及有关基础架构的特定细节的情况下，您可能会采用几种方法可以采取的措施如下：
创建独立的幂等操作
如您在问题中所述，创建一种操作状态，在该状态下，节点可以重复运行，直到所有任务都无法很好地扩展。但是，可以重新设计节点，这样就没有关系了。如果节点a和b运行任务以并行输出其日志，并且b在a之前完成，则它可以运行节点a正常运行的任务，反之亦然。
使用外部编排器进行委派
如果您打算安排许多节点，则使用委托节点绝对可以更好地扩展。但是，这可能与在委托方管理的节点上运行的Chef客户端产生冲突。很难验证您的节点配置和委托者节点任务是否相互冲突。一种聪明的管理方式是将任务合并到每个节点的配置中，并委派委托人在数据包或服务器的属性中设置一个值，以表示应如何配置自身（即，它需要执行哪些任务） ）。
组合您的基础架构
如果每个节点都根据其他节点依次运行它的任务，并且您在不同节点上运行任务没有成本/技术依赖性，则可能需要考虑将节点配置组合到一个节点中。这样可以消除任何节点之间的配置冲突。我想有明确的意图在不同节点上运行任务，但这绝对是一个值得考虑的选择（甚至可能会花费时间来重写不同节点的任务）。

评论

也许。我倾向于将业务流程更多地看作是运行事物，而不是执行它们的初始设置。

– Gaius
17-10-22在17:14

#3 楼

使用SaltStack来安排您的厨师运行。

您的跨节点协调逻辑在这里
https://docs.saltstack.com/en/latest/topics/orchestrate/orchestrate_runner.html# more-complex-orchestration

您可以声明性地
https://docs.saltstack.com/en/latest/ref/states/all/salt.states.chef.html

或强制性
https://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.chef.html

驱动Chef节点达到所需状态。