大規模な環境でFreeBSDのポートをどのように管理および展開しますか？

FreeBSDのポートを環境にどのように展開しているのか興味があります。私はFreeBSDを使用しているほとんどの人が実際にPortsを使用していると仮定しています（そして、しばしばバイナリでアップグレードするためにportupgrade）。しかし、最近のバージョンでの動作に満足していないため、このセットアップの方法に興味があります。私は現在FreeBSD 9.0を実行していますが、問題があります。

次のように設定しました。

• / usr / portsは、1つのノードからNFSを介して共有されます（夜間の「portsnap fetch update」を使用）。
• 各ノードは、読み取り/書き込みで/ usr / portsをマウントします
• すべてのノードで/etc/make.confに「WRKDIRPREFIX = / usr / tmp」を設定しました
• 以下を/usr/local/etc/pkgtools.confに追加して、ローカルインデックスを使用するようにPortsnapを構成しました。

ENV['LOCALINDICES'] ||= '/var/db'

ENV['PORTS_INDEX'] ||= ENV['LOCALINDICES'] + '/INDEX.local'

portupgrade -p packageパッケージをビルドportupgrade -P packageし、他のノードにバイナリをインストールするために正常に実行できます。

それでも、次の問題が発生する場合があります。 /var/db/INDEX.local:23265:dbm_store failed

インデックスは現在ローカルに存在し、実際にエクスポートされるのはポートツリーのみであり、ノードからそこに何も書き込まれないため、システムに対して行うことができる他の最適化は考えられません。

私は大規模な環境のポートシステムに完全に満足したことはありませんでした。うまく機能させるためには、外部管理を適用する必要があるようです。

私の最高のヒント（昇順の優先順位、「最悪」のソリューションから「最高」のソリューション）：

各ホストでビルドしている場合は、しないでください。
必要に応じて、NFSを使用して、説明したような読み取り/書き込みマウントを行わないでください。通常、代替の作業ディレクトリを提供する場合は、ポートツリーを踏みつけずにDo The Right Thingのポートを信頼できますが、申し訳ありませんが安全です：ローカルCVS / csupミラーを実行し、そのボックスからすべてのホストをcsupし、個々のマシンの場合と同じようにローカルでビルドします。
はい、これはホストのディスク容量を増やすことと追加のステップを意味します。また、問題がないことがほぼ保証されています。
警告： パッケージ構成ファイル（rsyncなど）を指定された「構成ホスト」から同期して、各マシンの整合性を確保することができます（各ノードでcsupを使用するのではなく、必要に応じてポートツリー全体をrsyncすることもできます）。

ビルドホストを使用してパッケージを作成し、それらをインストールします。
個々のマシンでビルドするよりもはるかに優れたソリューション：ビルドホストを使用してパッケージを作成し、それらのパッケージにツールを向けます。
これは、実行するすべてのアーキテクチャでビルドホストを維持すること（またはクロスコンパイル）を意味しますが、最終的にはターゲットマシンに適しています（大規模なコンパイルジョブなし、一貫性の保証）

構成/システム管理ツールを使用します。
これが私が巻き上げたソリューションです。標準のサーバーイメージを構築し、を使用して自分の環境に展開しradmindます。PuppetまたはChefでも同様のことができます。これには、ビルドホストを使用するすべての利点（一貫性、個々のサーバーの負荷の軽減）があり、構成管理の利点が追加されます。

警告：これは、マシンが「同一」である場合にのみ非常にうまく機能します。つまり、すべてのマシンに同じポートセットをインストールできます。それはできますが、ポートのセットを変化させた場合は動作しますが、ということは、実質的に管理オーバーヘッドが増加します。

免責事項：私はのポートメンテナーですsysutils/radmind。ええ、私はそれを採用したことをとても気に入っています。

これらはすべて、さまざまなサイズのFreeBSD環境（1〜2台のマシンから100台以上まで）を管理した私の経験に基づいています。標準化されたイメージをプッシュおよび維持する構成/システム管理ツールは、私の経験でこれを実際に処理する最良の方法です。

奇妙なことに誰もports-mgmt / tinderboxについて言及していませんでした：

Tinderboxは、FreeBSDポート用のパッケージ構築システムであり、pointyhat構築クラスターで使用される公式のPortbuildスクリプトに基づいています。TinderboxはJoe Marcus Clarkeによって書かれました。

複数のjail（ベースシステムバージョン）と複数のポートツリーを定義できます。jailとportstreeの組み合わせは、ビルドと呼ばれます。Tinderboxの刑務所は、FreeBSDで刑務所として理解されているものではなく、実際にはchrootの特定の世界です。Tinderboxは依存関係の自動追跡をサポートし、最後の実行以降に変更されたパッケージのみを再構築します。Tinderboxは、失敗したビルドの電子メール通知をサポートしています。Tinderboxはccacheともうまく統合します。

Tinderboxは、必要なプラットフォームおよびアーキテクチャ向けに、必要なポートのパッケージセットを簡単に提供するように設計されています。Tinderboxは、特に依存関係とパッキングリストをテストするための、新しいポートとポートのアップグレードをテストするための優れたツールでもあります。また、FreeBSD 6.XワールドをFreeBSD 7.X / 8.Xホスト上でjailとして実行できるため、FreeBSDのさまざまなリリースでポートをテストするのにも役立ちます。

また、pkgngに切り替えると、パッケージの展開が大幅に簡素化されます。
githubで確認してください：https : //github.com/pkgng/pkgng

適切に調整されたNFS上で/ usrを読み取り専用で共有し、パッケージデータベースを/ varから/ usrに移動してシンボリックリンクするだけで、100以上のFreeBSDサーバーを管理しました（厳密には必要ありませんが、pkg_infoなどを有効にします）。ある方向または他の方向に移動してシンボリックリンクする必要のある他のファイルが1つまたは2つあったかもしれませんが、全体のセットアップを理解するのに約1時間かかりました。とてもうまくいきました。スケーリングの問題が発生した場合、NFSサーバーを追加してワークロードを分割していましたが、それは実現しませんでした。パフォーマンスは私にとって決して問題ではありませんでした（実際、それは素晴らしいものでした）が、NFSサーバーの/ usr（またはそのコピー）をmdに置くことができると思います。

残念ながら、これに対する良い解決策を誰も得ていないようです。ほとんどの場合、これは下敷きツールの制限によるものです。

ここに私が思いついたものがあります：私はports-tree全体をエクスポートするという考えを捨てました。代わりに、各ノードに完全なポートツリーを追加しました。次に、「パッケージ」をNFS経由でマウントしました（パッケージの配布を可能にするため）。

また、portnapプロセスを高速化するために、キャッシングプロキシ（おそらくSquid）を利用するつもりです。これをセットアップする方法についての短い投稿をブログに書きました。

参照：

• プロキシのアイデア
• portsnapでの（またはグローバルな）HTTPプロキシの実装