最近、いくつかのシェフベースのレシピをVagrant環境にデプロイするときに問題が発生しました。私がインストールしようとしたコンポーネントの1つ（percona xtradbcluster）が一時的に利用できませんでした（percona ubuntuリポジトリに障害のあるビルドが含まれていました）。Perconaのスタッフは週末に問題を修正しましたが、実際に修正するための代替手段がなければ、しばらくの間テストセットアップを展開できませんでした。
これは私に考えさせられました：デプロイ時に、私はインターネット上で利用可能なたくさんの「もの」に依存しています：ubuntuリポジトリサードパーティリポジトリ、それらのリポジトリ内で利用可能なパッケージ、利用可能なrubygemsなど...これらのうち（一時的に）利用できない可能性があり、展開が不可能になります。
私の質問：すべての依存関係をキャッシュすることは可能ですか？それは価値がありますか、それとも私は時折グリッチを抱えて生きるべきですか？これにどのように対処しますか？
ありがとう！ニック。
Opscode の「apt」クックブックを使用して、システムの 1 つで apt キャッシュをセットアップすると、他のシステムはそれを apt ソースに使用できます。
キャッシュにするシステムでrecipe[apt::cacher-ng]、その実行リストに入れます (またはロールを使用します)。
他のすべてのシステムでrecipe[apt::cacher-client]は、実行リストに入れます (たとえば、すべてのシステムに適用される「ベース」ロールに入れます)。node['apt']['cacher_ipaddress']Chef Solo を使用している場合は、属性をキャッシュ システムの IP に設定する必要があります。
次に、インストールされたすべてのパッケージがキャッシュされ、他のシステムがキャッシュからインストールされます。
Chef は実際にキャッシュを行いますが、これはremote_fileリソースに対してのみです。ただし、パッケージのインストールに関しては、Chef は完全にパッケージ プロバイダーに依存します。つまり、シェル コマンドの呼び出しapt-get install(または yum または smth.else) を実行し、apt はダウンロードされたパッケージをキャッシュできますが、chef にはまったく依存しません。
また、一部のリモート コンテンツを事前にダウンロードするのに役立つものは何も知りません。私たちの会社で行った唯一のことは、より大きなファイル (>500Mb) と、複数のマシンで必要になると確信しているファイル用に、いくつかのローカル ファイル ストレージを作成したことです。(たとえば、どこにでも Java コンテナがインストールされています) 次に、レシピにローカル ストアへのリンクを提供すると、新しいマシンがそこからダウンロードします。
これを改善する方法として思いつくのは、次のことだけです。
remote_fileまたはpackageリソースに基づいて、独自の LWRP を作成します。そして、ダウンロード元の URL またはパッケージ名を受け取ると、どうにかして最初にローカル リポジトリからダウンロードしようとし、失敗した場合にのみ、リモート URL を使用してダウンロードしようとします。ただし、リモート URL とローカル リポジトリ URL の一致に問題がある可能性があります。