オプション1。 すべての束
Communutyサイトには 、 1つのパッケージのみをインストールする単一の レシピを含むサンプルクックブックが多数あります。 カスタマイズなしでも。 多くの場合、1つではなく複数のパッケージを配置しますが、クックブックの普遍性が低下するため、状況が悪化するだけです。
このようなレシピでは、通常、リポジトリの追加は「bashで」行われ、通常は1つのディストリビューションまたはプラットフォームに対してのみ行われます。
その単純さと自明性のために、そのようなソリューションは普遍性を欠いており、特にそれが生成されたインフラストラクチャの外では、再利用の可能性はほとんどありません。 まず、run_listを大きくする必要があります。次に、別のパッケージをインストールする場合は、別のクックブックを作成し、run_listをさらに強くする必要があります。3番目に、リポジトリからパッケージをインストールする場合の対処方法がわかりません。 悪い、これは怠け者のためのオプションです。 状況を改善してみましょう。
オプション2。 ロールプレイングゲーム。
前のアプローチでは、明らかに、一般的な場所にインストールするパッケージのリストを作成し、レシピ自体でループ内でこのリストを調べます。 Community Cookbooksには、既製のソリューションplatform_packagesがすでにあります 。 Cookbookでは、標準パッケージ管理システムを使用して、属性またはデータバッグで指定されたリストをシステムにインストールできます。 単一のアクションからまだほとんど利点のない新しいレシピがまだある理由は、私には謎のままです。
これで、ソリューションはすでに見栄えが良くなり、必要なパッケージのリストをベースロールに設定できます。 追加の役割では、このリストを明確にすることができ、シェフ自身がこれらのリストをマージします。 さらに、環境設定では、たとえばテスト環境でデバッグ情報を有効にしてアセンブリをインストールする必要がある場合など、必要なものを再定義できます。 最初のオプションから明らかなことを改善するために私たちには何が残っていますか？ リポジトリのセットアップ。
3番目のオプション。 レシピからリポジトリを取り出します。
リポジトリ構成を「bashで」より汎用的にするにはどうすればよいですか？ すべて同じコミュニティレシピに、 APTリポジトリを操作するための既製のリソースがあります 。 ちなみに、Opscode自体はそれを使用しますが、パッケージのインストールの直前にレシピで使用します。 Yumを管理するためのすばらしいクックブックがあります。Solaris用のクックブックがありますが、レシピおよびすべてのプラットフォームでリポジトリを直接設定する場合は、読みにくいifの山ができます。 同時に、テスト環境と運用環境で異なるリポジトリを使用できるようにしたいので、属性またはデータバッグのいずれかを使用する必要があります。 すでにロールプレイングゲームをプレイし始めているので、引き続き属性を使用します。
適切な既製のソリューションの予備調査は失敗しました。そのため、自転車を四角い車輪で作ります 。
最も単純な形式のロールの例：
run_list( "recipe[repos::percona]", "recipe[repos::opscode-chef-10]", "recipe[platform_packages]") override_attributes( "platform_packages" => { "pkgs" => [ { "name" => "chef", "action" => "upgrade"}, { "name" => "percona-server-client"} ]})
クックブックの各レシピは、最大数のプラットフォーム用に1つのリポジトリを構成します。 簡単にするために、現時点では適切なもののみを使用します。将来的には、良い人がyumやその他のオプションを追加します。