複数のノードにまたがるChefを使用して構成したいアプリケーションがあります。それを行うプロセスがから成っているとしましょう
これを行う1つの方法は、各ノードでのステージを格納するレシピを記述し、最終的にすべてのノードですべての操作を実行できるようになるまで、両方のノードで繰り返し実行することです。しかし、これは不格好であり、ノードC、Dなどがある場合はスケーリングされません。単一ノード内のシーケンスの依存関係への通知について知っていますが、複数のノード間では機能しません。これを必要とするのは私だけではないので、このスタイルのアクティビティのメカニズムやデザインパターン/ベストプラクティス/ TTPはありますか？
回答:
つまり、シェフはここで使用するツールではないかもしれません。
Chefは収束モデルであるため、いくつかの実行後、他のノードに応じて望ましい状態になるなど、べき等の方法でレシピを記述する必要があります。
状態の保存に関するアプローチは進むべき道のように
思えます。外部のオーケストレーターを使用して、AとBでchef-clientの実行を交互にスケジュールする必要があります。chef-serverがある場合は、プッシュジョブがchefエコシステムに固執する、他のオーケストレーターと比較してそれと私が見る主な利点は、ターゲットノードに受信管理ポートもsshも必要としないプルモデルです。
これはサーバーオーケストレーションの教科書の例であり、Chefが本来行うことを意図していないものです。Tensibaiによって指摘されているように、Chefを実行するサーバーは、レシピ、属性、データバッグなどによって設定された構成設定に基づいて独自の望ましい状態を実現する収束型システムです。インフラストラクチャに関する特定の詳細に触れずに、取ることができる：
独立したべき等演算を作成する
質問で述べたように、すべてのタスクが完了するまでノードを繰り返し実行できる運用状態を作成することは、適切にスケーリングされません。しかし、問題にならないようにノードを再設計することは可能かもしれません。ノードaとbがログを出力するタスクを並行して実行し、bがaの前に完了する場合、ノードaが通常実行するタスクを実行でき、その逆も同様です。
委任に外部オーケストレーターを使用する
委任ノードを使用すると、多くのノードをオーケストレーションする予定がある場合、間違いなくはるかに適切にスケーリングされます。ただし、これにより、委任者によって管理されているノードで実行されているchefクライアントとの競合が発生する可能性があります。ノード構成と委任ノードのタスクが互いに競合しないことを確認することは非常に困難です。これを管理する賢い方法は、各ノードの構成にタスクを組み込み、委任者にデータバッグまたはサーバーの属性に値を設定して、サーバー自体の構成方法（つまり、実行する必要があるタスク）を通知することです。 ）。
インフラを組み合わせる
各ノードが他のノードに応じてタスクを連続的に実行し、異なるノードでタスクを実行するためのコスト/技術的な依存関係がない場合は、ノード構成を1つの単一ノードに結合することを検討してください。これにより、ノード間で発生する構成の競合が解消されます。別のノードでタスクを実行する意図は明確にあると思いますが、これは間違いなく検討すべきオプションです（おそらく、別のノードのタスクを書き換えるのに時間を費やしても）。
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ノードを目的の状態に駆動します。