複雑なクラウド・アプリケーションのテスト・システムを構成する

IBM Workload Deployer と Collaborative Application Lifecycle Management を使用する

クラウド・アプリケーションは次第に複雑なものになっており、クラウド・ソリューションを迅速に提供しようとすると、そのソリューションが本番レベルのアプリケーションであろうと、複雑な仮想アプリケーションやシステム・パターンであろうと、その作業はより難しいものになっています。この難題に対処するために、この記事では実用的で容易に再現可能な CLM (Collaborative Lifecycle Management) システムを構築し、それに伴う複雑さを検証します (Collaborative Lifecycle Management は Collaborative Application Lifecycle Management と呼ばれることもあります)。この CLM システムはデータベースとして DB2 を使用し、IBM WebSphere Application Server 上で実行されます。

Bradley C. Herrin, Software Engineer, IBM

Herrin はノースキャロライナ州立大学 (North Carolina State University) のコンピューター・サイエンス学士コースの最後に産学協同プログラムを利用して IBM で働き始めました。彼は最初、RAD (Rational Application Developer) テスト・チームで JSF と JPA の Web ツールを担当しました。彼は RAD チームで働く中で、Rational Build Forge を使用した非常にアジャイルなインストールと構成の自動化機能を作成する機会を得ました。この機会により、彼は Rational Core Automation Team に異動し、そこで現在は自動化機能を統合したクラウド技術の活用を担当しています。彼は製品テスト、クラウド・コンピューティング、高速プロビジョニング・ツール、自動化、Linux に豊富な経験があります。彼は自動化機能を備えたクラウドの活用に情熱を傾けており、また自動化機能を備えたクラウドは明日の製品をテストするための方法に革命を起こす技術だと思っています。



2012年 4月 19日

クラウド・アプリケーションは次第に複雑なものになっており、クラウド・ソリューションを迅速に提供しようとすると、そのソリューションが一度限りの本番レベルのアプリケーションであれ、オペレーティング・システムを含むデプロイメント・パッケージ内のアプリケーションであれ、さらには複雑な仮想アプリケーション・パターン (クラウド・コンポーネントやミドルウェア・サービスと、構成のためのポリシー) や仮想システム・パターン (あるデプロイメント・トポロジーを実装した 1 つ以上の仮想イメージや仮想アプリケーション) であれ、その作業はより難しいものになっています。

この記事では、この難題に対処し、その複雑さを検証するために、データベースとして DB2 を使用して WebSphere Application Server 上で実行される、実用的で容易に再現可能な CLM システムを構築する方法について説明します。このシステムでは IBM Workload Deployer と Rational Team Concert の CLM フィーチャーが使用されます。最終的には、テスターがアプリケーションについて欠陥やビルドの検証を行ったり、スモーク・テストやその他のテストを実行したりするために、日常的なオンザフライのビルドで再現可能なトポロジーが構成されます。

はじめに

IWD (IBM Workload Deployer) は、再現可能なミドルウェアのパターン (つまりソリューション) をプライベート・クラウドにデプロイ可能な環境を提供するハードウェア・アプライアンスです。

私達のチームが最初に直面した問題は、データベースとして DB2 を使用して WebSphere Application Server 上で実行される実用的な CLM システムを、時間を節約できて再現可能な方法で構築する複雑さをどのようにして克服するのか、というものでした。この問題には以下のような要素が含まれています。

  • テスターは、このトポロジーを日常的なオンザフライのビルドの際に再現することができ、欠陥の検証、ビルドの検証、スモーク・テスト (システム全体が通常の動作をしているかどうかの大まかな検証) などを行える必要があります。
  • 平均的なテスターはテスト・シナリオを実行する前に、テスト・システムのインストールと構成に実働約 3 日から 5 日を費やしていました。

こうした文化を変えるために、IWD と統合自動化機能 (bash スクリプトや Python スクリプト、WSAdmin など) を使用して IWD 用スクリプト・パッケージを作成し、再現可能なソリューションを提供しました。私達のチームはこの作業に以下で説明するステップを用いたところ、60 分かかりました。


ステップ 1: 基礎を構築する

この記事で説明するソリューション・パターンのトポロジーでは、デフォルトの Red Hat Enterprise Linux 64 ビット WebSphere Application Server Network Deployment 8.0.0.1 仮想イメージ (WebSphere Application Server ND バージョン 8.0.0.1 と IBM Installation Manager 1.4.4 がプリインストールされた仮想イメージ) を使用し、スクリプト・パッケージによって、この仮想イメージにCLM をインストール、構成、デプロイします。さらにこのトポロジーでは、デフォルトの RHEL 64 ビット DB2 V9.7.4 仮想イメージも使用します。図 1 に、IWD の仮想システム・パターンがマッピングされた CLM トポロジーを示します。この記事で説明する仮想システム・パターンを表したのがこの図です。

図 1. IWD の仮想システム・パターンがマッピングされた CLM トポロジー
IWD の仮想システム・パターンがマッピングされた CLM トポロジー

この場合、CLM システムは WebSphere Application Server V8.0.0.1 が稼働しているサーバー上で実行されており、CLM データは DB2 V9.7.4 が稼働しているサーバーに格納されています。

IWD の優れた点の 1 つは、パターンの中にあるさまざまな仮想イメージの間に関係を確立できることです。既存の関係 (仮想システム・パーツ間の矢印で示されます) を利用することで、CLM データとアプリケーション自体との間でオープンな通信を行うことができるため、開発者にとって非常に使いやすいマルチサーバー環境を構築することができます。図 2 は IWD によって構築された関係を示しています。

図 2. IWD によって構築された関係
IWD によって構築された関係

矢印は WebSphere Application Server 8.0.0.1 が稼働しているサーバーが DB2 9.7.4 が稼働しているサーバーを認識していることを示しています。そのため、この 2 つのサーバー間の通信に関して (ファイアウォールやプロキシーなどを通過するための設定に) ユーザーが苦労する必要はありません。

このソリューションの基礎となる部分が構築できたので、以降のステップで CLM アプリケーションをデプロイできるように WebSphere Application Server と DB2 を準備します。


ステップ 2: データベースを作成する (JTS、CCM、QM、DW)

私達は Linux の bash スクリプトで構成されるスクリプト・パッケージを作成しました。このパッケージが db2admin (DB2 管理サーバー・コマンド) を呼び出し、各アプリケーションに対して CLM に必要なデータベースを暗黙的に作成します。

親の bash スクリプトは以下のとおりです。

#!/bin/sh
su - db2inst1 -c "sh /tmp/createDatabases.sh"

子の bash スクリプトは以下のとおりです。

#!/bin/sh
db2 CREATE DATABASE jtsDB AUTOMATIC STORAGE YES ON '/db2fs' DBPATH ON '/db2fs' 
 USING CODESET UTF-8 TERRITORY US COLLATE USING SYSTEM PAGESIZE 16384

ステップ 3: プリインストールされている Installation Manager をバージョン 1.5.2 に更新する

CLM 4.0 は Installation Manager との依存関係があり、Installation Manager バージョン 1.5.2 を必要とします。私達は Installation Manager のレスポンス・ファイルを使用して、プリインストールされている Installation Manager のバージョンを更新し、この処理を IWD スクリプト・パッケージの中にまとめました。

サンプルの bash スクリプトは以下のとおりです。

echo "Enter IM Directory"
cd /opt/IBM/InstallationManager/eclipse

echo "Launching IM 1.5.2 Update"
./IBMIM --launcher.ini silent-install.ini -input $IMFilePath/imUpdate152.xml
 -keyring $IMFilePath/im.keyring -accessRights admin -acceptLicense

IM を更新するためのレスポンス・ファイルのサンプル・テンプレートは以下のとおりです。

<?xml version="1.0"?>
<agent-input clean="true" temporary="true">
<server>
<repository location="<IM repository>"/>
</server>
<install>
<offering features="agent_core,agent_jre" id="com.ibm.cic.agent"
 version="<IM BUILD Version>"/>
</install>
<profile id="IBM Installation Manager" installLocation="/opt/IBM/InstallationManager"
 kind="self"><data key="eclipseLocation" value="/opt/IBM/InstallationManager"/>
 </profile>
</agent-input>

ステップ 4: WebSphere Application Server が稼働しているサーバーに CLM をインストールする

次のステップでは WebSphere Application Server が稼働しているサーバーに CLM をインストールします。このシナリオでは、ユーザーが CLM の特定のビルドを取得できる必要があります。それを考慮し、私達のチームはインストール対象の CLM をスクリプト・パッケージ内で指定するパラメーターとして Build ID を使用しました。

プロビジョニングの際、ユーザーは Build ID を入力するように促されます。Installation Manager が生成するレスポンス・ファイルには、bash のコマンドによって、この Build ID が使われるようになります。

呼び出される bash スクリプトは以下のとおりです。

#!/bin/sh
. /etc/virtualimage.properties

echo "CLM Build to be installed: "$CLM_BUILD_ID

echo "Substitute CLM Build ID"

sed -i s%CLM_BUILD_ID_1%$CLM_BUILD_ID% /tmp/CLM/CLM.xml
sed -i s%CLM_BUILD_ID_2%$CLM_BUILD_ID% /tmp/CLM/CLM.xml

echo "Install CLM 4.x via Installation Manager"

cd /opt/IBM/InstallationManager/eclipse
./IBMIM --launcher.ini silent-install.ini -input /tmp/CLM/CLM.xml
 -keyring /tmp/CLM/im.keyring -acceptLicense -accessRights admin

Exit

ステップ 5: WebSphere Application Server を構成し、CLM アプリケーションをデプロイする

パターン・ソリューションの最後のステップは、要求される適切な設定で WebSphere Application Server を構成し、CLM の WAR ファイルを WebSphere Application Server にデプロイすることです。

要求に合わせて WebSphere Application Server を構成するために、私達のチームは以下のように AdminTask オブジェクトを呼び出す Python スクリプトを作成しました。

print "-------Set Run as User to Root------"
#Set Run as Root
AdminConfig.modify('(cells/CloudBurstCell_1/nodes/CloudBurstNode_1/servers/
 server1|server.xml#ProcessExecution_1183122130078)', '[[runAsUser "root"]
 [runAsGroup ""] [runInProcessGroup "0"] [processPriority "20"] [umask "022"]]') 

print "-------Save Master Configuration-------"
#Save to Master Config
AdminConfig.save()

WebSphere Application Server を構成したら、teamserver.properties ファイルを構成し、データベース・テーブルを作成して、CLM の WAR ファイルを WebSphere Application Server にデプロイする必要があります。

teamserver.properties テンプレートは、スクリプト・パッケージに含めました。bash の文字列置換を使用することで、これらのテンプレートには適切なホスト名とデータベースのストリングが入力されます。

文字列が置換された後、各アプリケーションの teamserver.properties ファイルはカスタマイズされたテンプレートに置き換えられます。

ここから先の作業は、CLM インストールに用意されたツールのみを使用して行います。CLM インストールには一連のリポジトリー・ツール (repotool) が用意されており、これらのツールを使用して既存のデータベースにテーブルを作成することができます。そのため、ユーザーが JTS (Jazz Team Server) セットアップ・ウィザードでテーブルを作成する必要はありません。

repotool の例:

echo "------Run Repo Tools for JTS Tables------"
cd /opt/IBM/JazzTeamServer/server
./repotools-jts.sh
 -createTables teamserver.properties=
 "/opt/IBM/JazzTeamServer/server/conf/jts/teamserver.properties"
  logFile=repotools.log

最後に、Python スクリプトを使用して WebSphere Application Server にアプリケーションの WAR ファイルをデプロイしました。このスクリプトは WebSphere Application Server の Admin プログラム (wsadmin.sh) に渡され、Admin プログラムから呼び出されてアプリケーションのデプロイメントを実行します。

アプリケーションをデプロイするための Python スクリプトの例を以下に示します。

def deployJazzApp(app_name):

    print "====== installing " + app_name + " Web Application on WAS ======\n"
    app_war= app_name + '.war'
    installed_appname = app_name + '_war'
    app_ctx = '/' + app_name
    appfile = properties.getProperty("CLM_HOME") + "/server/webapps/" + app_war

installcmd = ""

AdminApp.install(appfile, installcmd)
    AdminConfig.save()
    print "====== application " + app_name + " is installed on WAS =========\n"

print "====== Install completed. Please restart your WAS server.============\n"

アプリケーションがデプロイされ、WebSphere Application Server が稼働しているサーバーが再起動されると、ユーザーは JTS セットアップ・ウィザードのステップに従って、任意の CLM アプリケーションを登録することができます。図 3 に、このプロセスの最終結果として表示されるパターンを示します。

図 3. 最終的に表示されるパターン
最終的に表示されるパターン

まとめ

チームがこのパターンを作成したことで、テスターは CLM/WebSphere Application Server/DB2 トポロジーをいつでも素早くデプロイできるようになり、しかも特定のビルドを選択できるという柔軟性も実現することができました。一方、この方式は私達が当初意図していたよりも有用なことがわかりました。この方式は Rational 製品のソフトウェアを使える技術者ならば誰もが使用できる技術であり、しかもシステム検証テスター以外にも以下のような人達がこの方式を使用することができます。

  • チェックインされた最新コードをテストする機能検証テスター
  • 日常的に作成されるビルドの安定性を検証するビルド検証テスター
  • CLM との統合をテストする製品の開発者

この CLM パターン・ソリューションは IWD の機能の一部にすぎず、また開発プロセスのあらゆる段階での革新により、いかにソフトウェアの品質を向上できるかを示しています。このソリューションを Rational 製品に実装することで、ユーザーは時間という貴重なリソースを CLM の設定や構成に費やす代わりに、その大部分を開発とテストに費やせるようになります。

IWD により、複雑なテスト・システムが単純なものになったのです。

参考文献

学ぶために

製品や技術を入手するために

  • IBM SmartCloud Enterprise で利用可能な製品イメージを調べてみてください。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing, Rational, WebSphere, Information Management
ArticleID=810102
ArticleTitle=複雑なクラウド・アプリケーションのテスト・システムを構成する
publish-date=04192012