レベル: 上級 W. David Ashley, Senior IT Specialist, IBM
2009年 7月 14日 パフォーマンス改善のために Linux® KVM (Kernel Virtual Machine) を利用するようになった ooRexx を使用して、オンデマンド・ソフトウェア・ビルド・サービスを作成してください。KVM は、ユーザーのターゲット・ソフトウェアをビルドするゲスト・オペレーティング・システムに対し、ホストとして機能します。このビルドを管理し、その結果をユーザーが後で取得できるように保存するのは、Apache Web サーバーです。この記事を読んで、ビルド・サーバーをセットアップしてゲストを作成する方法、ビルド・リクエストをカスタマイズする方法、そしてビルド結果を編成し、それにアクセスする方法を学んでください。
最近、ooRexx (Open Object Rexx プロジェクト。詳細は記事の終わりにある「参考文献」を参照) はそのオンデマンド・ソフトウェア・ビルド・システムを、今までの VMware がホストするゲスト・オペレーティング・システムから Linux KVM (Kernel Virtual Machine) がホストするゲスト・オペレーティング・システムへと切り替えました。この変更によってビルド環境は一層効率化され、ユーザーにとってもビルド時間が短縮される結果となっています。
ooRexx ソフトウェア・ビルド・システムでは、複数の x86 ベースのプラットフォームおよびオペレーティング・システムに対応する ooRexx ソフトウェア・パッケージをビルドすることができます。現在サポートされているゲスト・オペレーティング・システムには、Windows® XP (i386)、Fedora 10 (i386 および x86_64)、Ubuntu 8.04 (i386) があります。これらのゲスト・オペレーティング・システムでは、Windows (EXE)、Fedora and openSUSE (RPM)、Ubuntu (DEB) 対応の ooRexx インストールおよびドキュメント・パッケージを生成することができます。これ以外の x86 ベースのオペレーティング・システムについては、ooRexx の開発者およびユーザーの要望に応じてオンライン化されことになります。
この記事では ooRexx 開発チームが行ったセットアップを例に、ooRexx、Apache、および Linux の経験がある開発者に必要なヒントとアドバイスを織り交ぜながら、独自のソフトウェア・ビルド・システムを作成する方法を紹介します。サーバーおよびゲスト用スクリプトのダウンロードは、記事の終わりに用意されています。このシステムは ooRexx ソフトウェアをビルドするという特定の目的で設計されていますが、その概念は、あらゆるソフトウェアを対象とした汎用ビルド・システムに適用することができます。
このシステムの主な要件は以下のとおりです。
- ビルド・リクエストを生成するための Web インターフェースがあること。
- ビルド結果を取得するための Web インターフェースがあること。
- 複数のゲスト・オペレーティング・システムがサポートされること。
- ゲスト・オペレーティング・システムが完全に自動化されたビルドを実行すること。
- ビルド完了時に E メールを生成し、リクエストを行ったユーザーに送信すること。
以上の要件に対応するため、開発チームと私はクアッドコア Xeon ベースのサーバーを使用しました。このサーバーには 4GB のメモリーと 250GB のディスク・スペースがあります。メイン・オペレーティング・システムとしては、Fedora 10 x86_64 ディストリビューションを選びました。これは主に、このディストリビューションが使用している KVM が最新の安定リリースであるという理由からです。ハードウェアとソフトウェアの選択は読者それぞれに違うかもしれませんが、ハードウェアを選択する際に第一の基準となるのは、そのプロセッサーがハードウェア仮想化に対応できるかどうかです。このポイントは、KVM を使う上では必要不可欠です。
サーバーをセットアップする
ビルド・サーバーをセットアップする際の最初のステップは、パーティショニング方式を決定することです。私たちは、Web ストアとゲスト・オペレーティング・システム用イメージを別々のパーティションに分離することにしました。Web ストアに確保したのは 50GB、ゲスト・イメージが置かれる /var パーティションに確保したのは約 150GB です。そして残った分を /home パーティションと /root パーティションに分けました。
 |
ビルド・システムの一般要件
ビルド・システムの基本要件としては、以下のものが挙げられます。
- 頻繁にビルドすること。できるだけ初期の段階に問題を見つけるためです。
- 短時間でビルドできること。ビルドの速度が速ければ速いほど、より頻繁にビルドすることができます。
- インクリメンタル・ビルド処理をすること (つまり全ビルドを回避すること)。開発段階での小さな更新を反映させるためです。
- ソース・コード依存関係の管理を (少なくとも下位レベルで) サポートすること。システムをできるだけ柔軟な状態に維持するためです。
- ビルド、コンパイル、リンクの使用状況を抽出/レポートできること。
- レポート・システムがソースとバイナリーとの一致を追跡できること。効率的な新旧比較を可能にするためです。
- ビルドのステータスやテストの成功/失敗などをレポートできること。
- リリース・ノートとシステム・ドキュメントを作成できること。
|
|
次のステップでは、Fedora 10 x86_64 リリースのディストリビューションを使用して、メイン・オペレーティング・システムをインストールします。独自のシステムをセットアップしている場合は、以下のようにすると問題が生じにくくなります。
- インストールを開始する前に、マシンの BIOS でハードウェア仮想化を有効に設定します。これによって、Fedora は KVM が使用可能であることを認識します。
- ソフトウェア・コンポーネントのカスタム・インストールを行います。カスタム・インストールでは、Fedora 仮想化オプションを選択できるからです。
サーバー・オペレーティング・システムをインストールした後は、このシステムにゲスト・オペレーティング・システムがアクセスできるように構成します。その際、Windows ゲストに対しては Samba を使用可能に設定し、Linux ゲストに対しては NFS を使用可能に設定する必要があります。この設定によって、ゲスト・オペレーティング・システムはビルド結果のパーティションにアクセスできるようになり、ユーザーがアクセスできる場所にビルド・ファイルを保存できるようになります。主な Samba 共有と主な NFS エクスポートが指す場所は、すべてのゲストに対して同じ場所になります。
次に Apache Web サーバーを構成して、ビルド・リクエスト・システム (「ビルドのリクエスト」セクションで説明) とビルド結果リポジトリーにアクセスできるようにします。
構成に関して 1 つ決定しなければならないことは、ゲストのネットワーク・オプションについてです。デフォルト・インストールは、すべてのゲストに専用の内部ネットワークを提供するように構成されます。ゲストに IP アドレスを提供するために、クラス C ネットワークが DHCP サーバーとともに提供されます。デフォルト以外のオプションは、ネットワーク機器のいずれかがサーバーの外部ネットワークへのブリッジとして機能するようにシステムをセットアップすることです。その場合には、手作業で構成しなければなりません。libvirt の Wiki に、このオプションでサーバーを構成する例が記載されているので参照してください (リンクについては「参考文献」を参照)。
ゲストを作成する
KVM 用のゲストを作成するには、2 つの手法があります。1 つ目の手法は、要件を満たすために必要なゲストだけを作成する方法です。そして 2 つ目の手法は、それよりも長期的な視野でゲストを作成する方法で、私たちはこの手法を使ってゲストを作成しました。必要なリソースが使用できる場合には、後者の手法を標準の手法として使用することを推奨します。
まず、要件を基にゲストの数とタイプを決定します。私たちに必要だったのは、それぞれの環境に対応したソフトウェア・ビルドを作成するためのオペレーティング・システムと、それとは別のドキュメントを作成するためのオペレーティング・システムです。結果的には、ドキュメントの作成と i386 RPM タスクを組み合わせて、単一のゲストで処理できるということがわかりました。以下に、私たちが作成したゲストとそれぞれのゲストに割り当てられたタスクをリストします。
- Windows XP (i386): Windows インストール実行可能ファイルのビルド
- Fedora 10 (i386): i386 RPM ファイルとドキュメントの ZIP ファイルのビルド
- Fedora 10 (x86_64): x86_64 RPM ファイルのビルド
- Ubuntu 8.04 (i386): DEB ファイルのビルド
私たちが採用した手法では、上記のゲストは後から複製可能なイメージとして作成されました。そのため各ゲストには、後で複製するために保持されている基本バージョンと、実際のビルド・タスクを行うためにカスタマイズした複製バージョンがあるという結果になりました。
KVM ゲストを複製するのは実に簡単なことです。Fedora 10 が提供する virt-clone スクリプトによって、このタスクは完全に自動化することができます。
リスト 1. Fedora 10 の virt-clone スクリプト
$ virt-clone --original=Fedora10-i386-Base \
--name=Fedora10-i386-Build \
--file=/var/lib/libvirt/images/Fedora10-i386-Build.img
|
original オプションでは、仮想マシン・マネージャーに既知のゲスト・オペレーティング・システム名を指定します。name オプションでは、新規ゲストの名前を指定し、file オプションでは、ゲストの新規イメージ・ファイルのファイル名を指定します。これで、既存のゲストが完全に複製されて、ゲストの新しいバージョンにコピーされます。さらに、新規ゲストの MAC アドレスと UUID も変更されるので、複製元のゲストは以降の複製用に保存され、必要な場合にはカスタマイズ用の新しいゲストが提供されることになります。
virt-clone スクリプトについて注意が必要な点として、複製元のゲストに接続されていないデバイス (CD-ROM など) があると、スクリプトの実行に失敗します。ゲストに接続されていないデバイスがあったら、ゲストを複製する前にすべて取り外しておいてください。必要な場合は、複製操作が完了してからデバイスを再び追加することができます。
私たちは基本のビルド・ゲストを作成した後、ビルド・タスクに応じてそれぞれのゲストをカスタマイズしました。カスタマイズが最も難しかったのは、Windows XP ゲストでした。これは、カスタマイズの一環として Visual C++ コンパイラーと Software Development Kit をインストールしなければならなかったためです。一方 Linux ゲストの場合は NFS を Ubuntu ゲストにインストールすること以外、カスタマイズは実質的に必要ありませんでした。
ビルドのリクエスト
すべてのビルド・ゲストには、さらにもう 1 つのカスタマイズ作業が必要となります。それは、ビルド・ゲストごとに Open Object Rexx バージョン 3.2 をインストールすることです。なぜなら、ooRexx で作成されたスクリプトはゲストごとにリクエストとビルド・プロセスを管理するからです。スクリプトは、ビルド・マシン・サーバーの TCP/IP ポートにアクセスしてビルド・リクエストを検索します。リクエストが見つかると、ビルド・プロセスが呼び出されます。このプロセスによってインストール・ファイル一式 (RPM、DEB、EXE) がビルド・レポートと併せて作成され、ユーザーが HTTP でアクセスできるようにビルド・マシン・サーバーに保存されます。
ooRexx ビルド・リクエスト・スクリプトは、既にビルドされているソフトウェアのバージョンを複製しないだけの賢さを持ち合わせています。さらに、ビルドの完了をユーザーに E メールで通知し、ビルドが保存されているビルド・マシン・サーバー上の場所の URL を提供します。
ビルド・リクエストは、ビルド・マシン・サーバー上の CGI スクリプトによって生成されます。まず、ユーザーが HTTP Web ページにアクセスして、目的のオペレーティング・システムのビルドを要求します。すると Apache サーバーが CGI スクリプトを呼び出し、リクエストをキューに入れます。その後は、ビルド・ゲストがキューに入れられたリクエストにアクセスして、要求された操作を実行します。ビルドの結果を Web サイトからダウンロードすることもできます。
前述したように、サーバーとビルド・ゲスト・クライアント両方のコードは、記事の終わりの「ダウンロード」セクションで入手することができます。すべてのスクリプトは ooRexx で作成されているため、簡単に理解できるはずです。ダウンロードには以下のファイルが含まれています。
- buildserver.rex: このスクリプトは Web サーバー上で実行され、ゲスト・オペレーティング・システムが作業を検索するために使用するキューの保守をします。
- buildd.rex: このスクリプトは各ゲスト・オペレーティング・システム上で実行され、Web サーバー上のキューにアクセスして作業を検索します。それぞれのゲストが担当するキューは 1 つだけなので、各ゲストがビルドする出力ファイルの種類は 1 種類のみです。
- simq.cls: このファイルはスクリプトではなく、buildserver.rex スクリプトが使用するクラス・ファイルです。
- socket.cls: このクラス・ファイルは、buildd.rex スクリプトが使用します。
- streamsocket.cls: このクラス・ファイルも同じく buildd.rex スクリプトが使用します。
ビルドの結果
ビルド・ゲストはビルドの結果を Web サイトに配置します。ビルドは、サブバージョン改訂ごとに固有のサブディレクトリーにその改訂のすべてのプラットフォーム・ゲスト・ビルドが含まれるように編成されます。また、それぞれのプラットフォーム・ゲストが生成するビルド・レポートも改訂サブディレクトリーに保存されます。
ビルド・レポートは、このすべてのプロセスが実際に機能するには必要不可欠です。ビルド中にエラーが発生した場合には、最終出力ファイルは生成されません。その場合、ユーザーは、何が問題なのかを発見する手段が必要になります。そこで、各ゲストでのビルド・プロセスは常にビルド・レポートを生成し、そのレポートをビルド・リポジトリーに保存するというわけです。
ビルド・リポジトリーの場所は、ooRexx ソフトウェア・ビルドと、ドキュメント・ビルドとで異なります。ドキュメント・ビルドは大量の出力ファイルを生成するため、ソフトウェア・ビルドとは別にしておくほうが便利であると判断したのです。
現在、自動化されたビルド・クリーンアップ・プロセスはありません。現時点でこのプロジェクトは、自動ビルド・クリーンアップ・プロセスが必要になるほどの出力を生成しません。
まとめ
VMware ビルド・ゲストから Linux KVM ゲストに切り替えたことにより、各ゲストでのビルド時間は約 50 パーセント短縮されています。これはつまり、ooRexx での開発サイクルも短縮されたことを意味します。
ooRexx 開発チームはビルド・マシンの最大のユーザー・グループとして飛び抜けた存在ですが、メジャー・リリースのアルファ・サイクルおよびベータ・サイクルの間には、多くの ooRexx ユーザーもこの環境を利用します。そのため、ooRexx で行われたバグ修正や機能強化について、ユーザーがタイムリーなフィードバックを提供できるようになっています。
最もよく使われているビルド・ゲストの 1 つは、ドキュメント・ビルダーです。ooRexx ドキュメントはすべて DocBook でコード化されるため、Windows システムでの DocBook の操作にある程度の経験がなければ、この環境でドキュメントをビルドするのは容易ではありません。ooRexx の開発者とユーザーの大部分にとって、これは深刻な問題です。誰もが利用できるドキュメント・ビルド・プロセスを実現することによって、私たちは開発者とユーザーがドキュメントの作成と保守に貢献することを確実にしています。このドキュメント・ビルド・プロセスで作成された ooRexx のドキュメントは、ほとんどのオープン・ソース・プロジェクトより遙かに優れています。そしてこれは、私たち開発チームの誇りです。
ダウンロード | 内容 | ファイル名 | サイズ | ダウンロード形式 |
|---|
| Build server and guest scripts | buildserver.zip | 23KB | HTTP |
|---|
参考文献 学ぶために
製品や技術を入手するために
- SourceForge が Open Object Rexx ダウンロードをホストしています。
- IBM REXX ファミリーには、Compiler and Library for REXX on zSeries、REXX for VSE、および REXX for CICS があります。
- developerWorks から直接ダウンロードできる IBM 試用版ソフトウェアを使用して、Linux で次の開発プロジェクトを構築してください。
議論するために
- My developerWorks コミュニティーに加わってください。自分個人のプロファイルとカスタム・ホーム・ページを作成して、自分の興味に合わせて developerWorks をカスタマイズしたり、他の developerWorks ユーザーと対話したりすることができます。
著者について | | | David は、IBM Lab Services の Senior IT Specialist です。IT ソフトウェア開発での経験は 25 年以上に及びます。 |
記事の評価
| 
