質問が「シェフソロの利点は何か」であるかのように、この答えの方向を決めます。なぜなら、それがアプローチ間の違いをカバーするための最良の方法だからです。
私の要約の推奨事項は、他の人と一致しています。ノードを頻繁に追加および削除する動的な仮想化環境を管理する必要がある場合は、chef-serverを使用します。chefサーバーも必要な場合、優れたCMDBです。ノードがあまり頻繁に変更されず、ロールとレシピが変更される、あまり動的ではない環境がある場合は、chef-soloを使用します。環境のサイズと複雑さは、大体無関係です。どちらのアプローチも非常にうまく拡張できます。
chef-soloをデプロイする場合、rsync、「git pull」、またはその他のdem等ファイル転送メカニズムを備えたcronjobを使用して、各ノードでchefリポジトリの完全なコピーを維持します。cronjobは、（a）まったく実行しない、（b）実行するが、ローカルリポジトリを同期しないように簡単に構成できる必要があります。各ノードのjsonファイルを使用して、chefリポジトリにnodes /ディレクトリを追加します。cronジョブは、適切なノードファイルを識別するという点で、望みどおりに洗練することができます（ただし、$（hostname -s）.jsonを推奨します。ナイフを使用してコミュニティクックブックをダウンロードし、スケルトンを作成できる以外に理由はありません。
このアプローチには、明らかな「サーバーを管理する必要がない」ことに加えて、いくつかの利点があります。ソース管理はすべての構成変更の最終的な調停者になり、リポジトリにはすべてのノードとランリストが含まれ、各サーバーは完全に独立しているため、便利なテストシナリオが容易になります。
Chef-serverは、「ナイフアップロード」を使用してクックブックを更新するホールを導入します。このホールに自分でパッチを適用する必要があります（ポストコミットフックなど）。 sラップトップの古いローカルリポジトリからの古いレシピ。すべての変更がマスターリポジトリからサーバーに直接同期されるため、chef-soloでこれが発生する可能性は低くなります。ここでの問題は、規律と協力者の数です。あなたがソロ開発者または非常に小さなチームの場合、APIを介してクックブックをアップロードすることはそれほど危険ではありません。大規模なチームでは、適切なコントロールを適切に配置しない場合があります。
さらに、chef-soloを使用すると、すべてのノードのロール、カスタム属性、およびランリストをnode.jsonファイルとしてメインchefリポジトリに保存できます。chef-serverでは、APIを使用してロールとランリストがオンザフライで変更されます。chef-soloを使用すると、リビジョン管理でこの情報を追跡できます。これは、静的環境と動的環境の競合が明確に見られる場所です。ノードのリスト（どれだけ長くても）が頻繁に変更されない場合、このデータをリビジョン管理に入れると非常に便利です。一方、頻繁に新しいノードを作成し、古いノードを破棄する場合（ホスト名やfqdnを再度表示することはありません）、すべてをリビジョン管理に維持するのは不必要な面倒な作業であり、変更を行うAPIがあれば非常に便利です。Chef-serverには、ノードを識別するデフォルトの方法としてfqdnを置き換えることができる「knife bootstrap」の名前オプションなど、動的なクラウド環境の管理に向けた機能全体が備わっています。しかし、静的な環境では、これらの機能は、特に他のすべての機能でリビジョン管理のロールとランリストを持つことに比べて、価値が限られています。
最後に、追加の作業をほとんど行わずに、レシピテスト環境をオンザフライで設定できます。サーバーで実行されているcronjobsを無効にし、ローカルリポジトリに直接変更を加えることができます。chef-soloを実行して変更をテストすると、サーバーが本番環境でどのように設定されるかを正確に確認できます。すべてをテストしたら、変更をチェックインして、ローカルcronjobを再度有効にすることができます。ただし、レシピを作成する場合、「検索」APIを使用することはできません。つまり、動的なレシピ（ロードバランサーなど）を作成する場合、この制限を回避し、jsonファイルからデータを収集する必要があります。 nodes /ディレクトリ。これは利便性が低く、完全なCMDBで利用可能なデータの一部が不足している可能性があります。繰り返しますが、より動的な環境ではデータベース駆動型のアプローチが好まれ、ローカルディスク上のjsonファイルを使用すると、動的性の低い環境でも問題ありません。chefの実行が中央データベースに対してAPI呼び出しを行う必要があるサーバー環境では、そのデータベース内のすべてのテスト環境の管理に依存します。
最後は緊急時にも使用できます。本番サーバーで重大な問題をトラブルシューティングし、構成を変更して解決する場合、サーバーのリポジトリですぐに変更を加えてから、マスターにアップストリームにプッシュできます。
これらがシェフソロの主な利点です。サーバーを管理したり、ホストされているシェフにお金を払ったりする必要がないなど、他にもいくつかありますが、それらは比較的小さな懸念です。
要約すると：動的で高度に仮想化されている場合、chef-serverは多くの優れた機能（他の場所で説明）を提供し、chef-soloの利点のほとんどは目立たなくなります。しかし、特に従来の環境では、シェフソロには明確で、しばしば言及されていない利点がいくつかあります。クラウドにデプロイされているからといって、必ずしも動的な環境があるとは限らないことに注意してください。たとえば、ソフトウェアの新しいバージョンをリリースせずにシステムにノードを追加できない場合、おそらく動的ではありません。最後に、高レベルの観点から、CMDBは、チーム間のアカウンティングや情報共有など、システム管理と構成に正接的に関連する多くの事柄に役立ちます。chef-serverを使用することは、その機能だけで価値があります。