マスター/エージェント構成管理を実行する明確な利点は何ですか？

Ansibleは、エージェントがなく、ある程度のオーバーヘッドを節約できるため、シェフや人形のような競争よりも明らかに有利なようです。

さまざまな構成ツールの比較をいくつか読んだところ、各ツールにはそれぞれ長所と短所がありますが、その多くは個人の好みによるものであることがわかりました。

エージェントレスであることの利点は非常に簡単ですが、構成管理ツールに関してマスター/エージェントアーキテクチャの利点はありますか？

トピック「構成管理プルvsプッシュトポロジ」に関する興味深い議論を見つけました

プルシステム（マスター/エージェント）が1人の投稿者が書き込みを行うと、柔軟性が増し、拡張が容易になります。

マスター/エージェントプルアーキテクチャの唯一の利点は、プッシュアーキテクチャではできませんが、ファイアウォールに穴を開けずにファイアウォールネットワークで（実際の構成がネットワークの外部にある場合）使用できることです。

柔軟性の点では、最も重要な問題は、リモートで管理可能になるためにノードで必要な最小限のセットアップであると思います。この要件が満たされると、両方のアーキテクチャで更新を処理できます。マスター/エージェントアーキテクチャでは、エージェントをインストール、設定、実行する必要があります。一方では、PuppetとChefはデフォルトで（まだ）ほとんどのシステムにインストールされていませんが、sshd（Ansibleが必要）はインストールされています。一方、Ansibleでも、sshdを実行し、ノードで構成された資格情報にアクセスできるようにする必要があるため、特にカスタマイズされたシステムイメージを使用して最小限の設定を行う場合は、この観点から大きな違いはないと思います。

スケーラビリティの観点から、マスター/エージェントアーキテクチャはスケーラビリティが低い（ただし少しだけ）と考えます。

• マスターがアクティブなシステム状態（つまり、すべてのエージェントとその状態のマップ）をアクティブに維持しようとすると、時間/リソースが消費されます。マスターがいなければ、Ansibleはそのようなスケーラビリティの問題の影響を受けません。確かに、マスター/エージェントアーキテクチャでも、Ansibleと同様のシステム全体の状態を提供するためのスケーラブルなアプローチを提供できます（おそらく、今日ではすべてが可能です）。

• 昔は、マスターが実際にエージェントの構成タスクを実行する場合（回答で参照した投稿に記載されているように）、そのようなアーキテクチャのスケーラビリティは大きな影響を受ける可能性がありました。しかし、質問で言及されたすべてのツールの構成はローカルノードに転送され、そこでローカルタスクが実行されるため、これはもう大したことではありません。

• ローカルノードに構成を転送する場合、プルアーキテクチャはそれらの構成を提供する容量によってのみ制限されます（両方のアーキテクチャに共通）。ただし、マスター/エージェントは転送を駆動するロジックを実行し、実際に転送（該当する場合）（エージェントに独自の構成をプルするように指示することも可能）。これにより、マスターが構成を多数のエージェントに伝達する速度が制限されます。

私見、エージェントまたはマスター、あるいはその両方を持つことのアイデアは、これに要約されます：

ノードの状態を継続的に管理するメカニズム。

そのようなツールがこれを可能にする場合、「自己修復」機能は明らかな利点です。

Ansibleの場合、私に関する限り、自己修復機能を提供する組み込みのメカニズムはありません（状態を取得してそれに反応するために継続的に実行されているデーモンがないため）。

とは言っても、自己修復は構成管理ツールが解決すべき問題のようには聞こえないので、Ansibleに対する他のツールの「利点」を検討することはできないかもしれません。