Artifactory、Maven、Nexus などのアーティファクト リポジトリに精通しています。
Berkshelf-API / Chef Supermarket は、上記のアーティファクト リポジトリと何が違うのですか?
一見すると、既存のアーティファクト リポジトリの機能を複製しているように見えます (不変性、推移的な依存関係の解決など)。
明確化: これは意見に基づく質問ではありません。他の典型的なアーティファクト リポジトリではなく、Berkshelf-API / Chef Supermarket が Chef Cookbook に使用される 技術的な理由を探しています。
tl;dr - Berkshelf-API と Chef Supermarket は、Berkshelf がクックブックの依存関係をダウンロードするために使用するものです。それらは、クックブックの依存関係を決定するために特別にフォーマットされた .JSON ドキュメントを Berkshelf に提供します。同様のフォーマットの .JSON ドキュメントを返すように他のアーティファクト リポジトリを変更できない理由は見つかりませんでしたが、私の知る限り、現時点ではそうしていません。
Berkshelf-API : 「さまざまなソースからクックブックをインデックス化し、REST API を介してホストするサーバー」
実際、Berkshelf-API はChef Supermarketで使用されています。
URL に「/universe」を追加することで、スーパーマーケットからクックブックのリストを手動で取得できます ( https://supermarket.getchef.com/universe )。
Berkshelf を使用して依存関係を解決する場合 (「berks install」または「berks update」を使用)、ソース エントリを探します (通常は、クックブックの Berksfile の上部にある「 source " https://supermarket.getchef.com "」)。 .
Berksfile には、ソース エントリの下に「メタデータ」もあります。これにより、cookbooks metadata.rb ファイルにリストされているクックブックの依存関係が読み込まれます。これらは、Berksfile の「メタデータ」エントリの下にリストされているクックブックの依存関係によってオーバーライドできます。
次に、Berkshelf はソース エントリ (この場合はスーパーマーケット) からクックブックの依存関係のダウンロードを開始します。
ただし、Berkshelf は依存関係の metadata.rb または Berkshelf ファイルを再帰的にロードしません。
例: Foo が Baz に依存する Bar に依存する場合
Foo => Bar => Baz
Foo は、metadata.rb または Berksfile で Bar の依存関係を示します。
Bar は、metadata.rb または Berksfile のいずれかで Baz 依存関係を示します。
ただし、Berkshelf は、Bar の metadata.rb または Berksfile を読み取って、Bar (この場合は Baz) の依存関係を判別しません。代わりに、ソース エントリへの呼び出しから返される、Berkshelf-API からのバージョン管理されたクックブックのキャッシュされたリストを使用して、Bar の依存関係を決定します。
プライベート Berkshelf-API サーバーは、異なるクックブック リポジトリ (別の Berkshelf-API サーバーまたは Chef サーバー) を指す複数のエンドポイントを使用してセットアップできます。
したがって、一般的な使用法は、Private Chef Server (非公開のクックブックを保存する) と Chef Supermarket サーバー (公開のクックブックを保存する) の両方を指す Private Berkshelf-API サーバーです。