5

問題

Linux を実行する数種類のサーバーで構成される大規模なインフラストラクチャがあります。たとえば、データベース サーバー、ロード バランサー、アプリケーション固有のサーバーなどです。あらゆる種類のサーバーには多くのインスタンスがあり、それらすべてが再現可能である必要があります。

あらゆる種類のサーバーは、基本的にカスタム ディストリビューションです。カスタマイズには、アップストリーム パッケージ (他のアップストリーム バージョン、ビルド オプション、パッチなど) への変更と、追加のカスタム パッケージが含まれる可能性があります。

たとえば、特定のオプションといくつかのパッチでコンパイルされた最新の OpenLDAP slapd を実行するサーバーが必要です。そして、これが物事が複雑になるところです。

最新の slapd に更新するには、依存するライブラリも更新する必要があります。これは、これらのライブラリに依存するすべてのパッケージも再構築することを意味します。つまり、基本的にディストリビューションの重要な部分を再構築する必要があります。このプロセスを自動化するのに役立つソリューションを探しています。

ソリューション要件

漠然とした。カスタム ディストリビューションのビルドに必要なすべてのものを準備し、それに名前 (ldap-server など) を付けて、ビルドを再現する必要があるときはいつでもその名前を自動ビルド システムに付けたいと考えています。

これは Gengoo や LFS コミュニティが持つべきものだと思います。また、ALT Linux Hasher、Fedora Mock、Debian pbuilder/sbuild などのプロジェクトを見てきましたが、それらを使用したことはありません。

何か案は？

前もって感謝します！

4

5 に答える 5

5

タスクにNix パッケージ マネージャーと Hydra ビルド システムを利用することもできます。

  • Nixは純粋に機能的なパッケージ マネージャーです。

  • Hydraは、Nix ベースの継続的なビルド システムです。（知る限り、必要に応じて依存パッケージの再構築を行います。）

Nixは、パッケージの依存関係とその変更を追跡できるだけでなく、ホストの構成も追跡できるため、一貫した以前の状態にロールバックできます。(これが、Nix ベースの Linux ディストリビューションであるNixOSの背後にある考え方です。)

もあります：

  • Disnix、Nix ベースの分散サービス展開システム。
于 2011-03-21T08:55:34.527 に答える
4

実稼働サーバー用のカスタム ディストリビューションを維持することを選択した理由はお聞きしませんが、... 私はこの種のハッカソンの経験があり、それに伴う大きな頭痛の種です。

  1. ディストリビューションのビルドを自動化するために、ビルド順序と依存関係の XML 定義を使用し、スクリプト化された GNU Make を使用して、並行して独立したブランチでビルドし、バイナリ パッケージを構築しました。python+Make/Autotools の XML+shell-script+bit から得られた出力は、「コア」ツールとエクストラの特別なセットの完全なビルドでした。

  2. 2 番目のステップは、これらのバイナリ/raw ビルド ディレクトリをシステムにインストールすることでした。installwatch (と思う) を使用して inotify を使用し、インストール先を監視しました。次に、バイナリの依存関係とともに XML を出力します。

  3. この後、ビルド マニフェスト (XML) と、パッケージごとに、インストールされたパッケージの詳細を含む XML ファイルを作成しました。次に、XML とインプレース バイナリをさまざまな形式 (RPM など) に変換するツールを作成しました。

  4. これで (想像してみてください)、ビルドを自動化するインストール スクリプト、ビルドされたパッケージとその依存関係に関する大量のメタデータ、およびそのメタデータを展開可能なパッケージに変換する方法ができました。

  5. 次に、glib から :) まで、さまざまなサーバー用のビルド スクリプトを作成し、それらのビルドを実行しました。システムは、どのパッケージ/./configure が一般的であるかを認識し、それらのパッケージを共有しました。これにより、次のことがわかりました
    o /common という名前のレポ
    o ビルド タイプとアーキテクチャごとのレポ

  6. いくつかのスクリプト/rsync-over-ssh とパッチ管理スクリプトがあれば、すぐに作業を終えることができます。

明らかに、これは共通の環境用に複数のディストリビューションを構築するための私のアプローチの非常に大まかな概要です。一部のパッケージは、ソース ツリーに影響を与えるメタ パッケージでした (ただし、ビルド時には通常のパッケージのように扱われました。1 つの例は、最初に実行されてカーネルにパッチが適用されたメタ パッケージでした)。

次に、ツールチェーンの自動化の問題があります。

すべては LFS から始まりました...しかし、ご覧のとおり、物事は少し冒険的になりました。

要するに、とても楽しかったのですが、BSD と Fedora のためにすべてを捨ててしまいました。

Suse Build Serviceのようなものが興味深いかもしれません。安定したソースの組み合わせの検索とコンパイルを実行すると、物事が簡単になります! Suse に関係するものを構築する必要さえありません。

于 2009-08-22T19:00:24.777 に答える
1

念のため、元の質問以来、同様の問題のセットに対するさらに別の回答が利用可能になりました: mkimage-profilesは、ALT Linux ディストリビューション関連のツールチェーンに基づいていますが、発生させようとしているイメージ構成管理ツールでそれを拡張します。ミニマルで簡潔なフォーク。現在ではほとんど公式にロシア語で文書化されていますが (いくつかの理由からこれは私の決定でした)、コード自体は英語でかなりよくコメントされています。

アプローチの感触をつかむには、たとえばconf.d/server.mkを参照してください:

distro/.server-base: distro/.installer use/syslinux/ui/menu use/memtest
    @$(call add,BASE_LISTS,server-base openssh)

distro/server-nano: distro/.server-base \
    use/cleanup/x11-alterator use/bootloader/lilo +power
    @$(call add,BASE_LISTS,$(call tags,server network))
    @$(call add,BASE_PACKAGES,dhcpcd cpio)

distro/server-mini: distro/.server-base use/server/mini use/cleanup/x11-alterator
    @$(call set,KFLAVOURS,el-smp)

OpenVZテンプレート キャッシュ、VMイメージ、ARM/PPCアーチ、git (生成されたプロファイルのステージを意味のある説明でコミットする場合など)、構成ツリー グラフなどのサポートがいくつかあります。

PXE ブートのサポートは、フレームワーク内で実装 (およびアップストリームへの移行) が非常に簡単なはずですが、実際にはまだ完了していません。

サイズが ~17MB から始まる netinstall イメージの予備的なサポートがあります (例)。

また、ALT が非実用的であると考えるあなたの特定の理由にも興味があります。もちろん、既知のものはいくつかありますが、あなたのものは私にとって新しいものかもしれません :-) PS: 特に多かれ少なかれ LFS まで行く準備ができている場合。

PS2: 4 GB 以上の RAM と DHCP が有効なインターネット経由のイーサネット接続を備えたシステムでlive-builder.isoを使用してライブ モードで試すことができます。altlinuxとしてログインし、cd /usr/share/mkimage-profilesおよびサーバーミニ.isoを作る

于 2012-12-19T11:13:49.333 に答える
1

ALTLinux girar-builderは、パッケージを再構築し、パッケージの一貫したリポジトリを維持するための (内部でハッシュを使用する)システムです。Hasher は、ビルド プロセスを分離するためのツールです。これにより、すべての要件を正確に「追跡」して、ビルド プロセスの再現性を保証することができます。

とりわけ、girar-builder は、新しくビルドされたパッケージをリポジトリに追加 (更新、削除) するときに依存関係のチェックを行います。そのため、他の依存パッケージが変更されない限り、新しいパッケージが他のパッケージの依存関係を壊した場合、新しいパッケージは受け入れられません。また、同じビルド タスク (= repo 変更トランザクション) に追加され、新しいパッケージの後に再ビルドされます。これは、 ALTLinux 開発者メーリング リスト(メーリング リストの英語版) で議論されているのをよく目にする状況です (共有ライブラリ内のシンボルの消失による dep の破損の例、パッケージの削除の例)。): 「新しい満たされていない依存関係が検出されました」。続行するには、メンテナーが依存パッケージをそのタスクに追加する必要があります。

girar-builder は、新しいパッケージのインストール テストも行います。git.alt (girar-bulder) によって行われる別のチェックに名前を付けるだけです。

パッケージのビルドがパッケージのリポジトリの現在の状態で再現できることを確認するために、リポジトリ内のすべてのパッケージ ( Sisyphusと呼ばれる) が現時点で再ビルド可能であることを時々 (かなり定期的に) チェックしています。 --再構築テスト ステータス レポート、最後の再構築テストのログ、パッケージごと。

于 2011-03-21T08:38:14.463 に答える
0

私はそれについてあまり知りませんが、Suse Studioは一見の価値があると思います。

于 2011-03-21T09:09:58.450 に答える