问题描述
想要使用Chef来配置一个涵盖多个节点的应用程序。具体来说，操作流程如下：
1. 在节点A上执行某项操作，并捕获输出。
2. 在节点B上使用该输出执行另一项操作。
3. 回到节点A进行某些操作。
4. 再次在节点B上操作。
5. …
用户意识到一种做法是编写一个能在每个节点上保存当前阶段的食谱，并持续在两个节点上运行直到完成所有操作。但这种方式比较笨拙，而且如果有节点C、D等的话无法扩展。用户知道可以使用notify来处理单个节点内的依赖关系，但不能在多个节点之间起作用。用户认为肯定不止他一个人有这种需求，所以是否存在一种机制、设计模式、最佳实践或技巧来解决这种活动风格的问题？
解决方案
以下操作中可能涉及版本差异，请注意根据自己的情况进行适当调整。
方案1：外部编排器
在这种情况下，Chef可能不是最合适的工具。Chef是一个收敛模型，意味着你必须以幂等的方式编写食谱，确保经过一些运行后，根据周围其他节点的配置，它将达到所需的状态。
你提到的存储状态的方法似乎是可行的，但你需要使用外部编排器来交替在节点A和节点B上安排chef-client运行。如果你有一个Chef服务器，”push jobs”可能是一种选择，这是在Chef生态系统中的一种方法。与其他编排工具相比，主要优势在于它采用了拉模型，不需要目标节点上的入站管理端口或SSH。
方案2：独立的幂等操作
这是典型的服务器编排问题，而Chef并不适合处理这种情况。Chef作为一个收敛系统，根据食谱、属性、数据包等设置来实现自身的期望状态。
一种方法是创建独立的幂等操作，重新设计节点以使其能够并行运行任务，直到所有任务完成。例如，节点A和节点B并行运行任务以输出日志，如果节点B在节点A之前完成，则可以在节点B上运行节点A的任务，反之亦然。
方案3：使用外部编排器进行委派
使用委派节点来进行外部编排是扩展性更好的方式，特别是如果需要编排许多节点。但这可能会导致委派器节点上的Chef客户端运行与被委派节点的运行冲突。一种解决方案是将任务纳入每个节点的配置中，并在委派器节点上设置一个值，以指示节点如何进行配置（即需要执行哪些任务）。
方案4：合并基础设施
如果每个节点按序运行任务，并且在不同节点上运行任务没有成本/技术依赖关系，你可以考虑将节点配置合并为一个单一节点。这将消除在不同节点之间可能存在的任何配置冲突。当然，这可能涉及到节点的明确意图，但这也是一个可供考虑的选项，即使需要重新编写不同节点的任务。
方案5：使用SaltStack进行编排
你可以考虑使用SaltStack来进行跨节点的编排。SaltStack有丰富的编排功能，可以通过Runner模块实现跨节点的编排逻辑。同时，你可以使用SaltStack的State模块，以声明方式或命令方式将Chef节点驱动到所需的状态。
结论
在这种情况下，要实现多节点操作的编排，你可以考虑使用外部编排器（如SaltStack）或重新设计节点的配置来适应并行运行任务。在使用任何解决方案时，务必根据自己的情况进行适当的调整和测试。