ミドルウェア・アプリケーション環境を対象としたクラウド･ベースの手法について調べる場合、これらの手法が、デプロイメント時間の短縮、一貫性の強化、アジリティーの促進といったメリットを持つことを期待するはずです。従来の手法では、ミドルウェア・アプリケーション環境を構築するのに長い時間と大量のリソースが必要となるのが通常で、何人もの人員が数週間かけて行うことになるという事態も珍しくありません。

さらに、いくつものステップと複雑さを伴うことから、プロビジョニングによる一貫した結果を得るのも困難になりがちです。これらの問題は、この 10 年にわたって IT コストが増加してきた理由の 1 つになっているだけでなく、急激に変化する現代の消費者市場において、企業が必要とするアジリティーを実現する妨げとなっています。

IBM Workload Deployer の世界へ足を踏み入れてください。この革新的なソリューションは、その前身である WebSphere CloudBurst Appliance をベースに、上記に挙げた従来からの問題に対処して、クラウド・ミドルウェア環境のデプロイメントを迅速かつ効率的に、しかも繰り返し行えるようにします。

IBM Workload Deployer を支え、その利点をもたらす土台となっているのは、パターン・ベースの手法です。ユーザーはこのクラウド管理アプライアンスを使用して、構成が完全に行われたアプリケーション環境を表すパターンを作成し、そのパターンをデプロイします。仮想イメージから提供されるこれらのパターンによって、ユーザーは完全な、そして大抵は複雑に構成された環境を単一のデプロイ可能なユニットとして表現することができます。

特定のアプリケーション環境を実際に使用する段階になったら、パターンを選択してデプロイするだけでよいのです。後は、IBM Workload Deployer がそのパターンによって表される環境を構成するさまざまな仮想マシンを自動的にデプロイ、構成、統合してくれるため、ものの数分でアプリケーション環境が完成します。

これまでにないスピードで完成するという明らかなメリットに加え、パターンには一貫性というメリットもあります。パターンを使用することで、デプロイメントを繰り返しても常に一貫した結果が保証されるため、開発者はより多くの時間をアプリケーションに専念できるようになり、サポート環境が適切に構成されていることを確実にするための作業時間を削減することができます。

迅速に導入できるように、IBM Workload Deployer には、あらかじめビルドされた一連の仮想イメージ、仮想システム・パターン、および仮想アプリケーション・パターンが同梱されています。これらの仮想イメージとパターンはそのままデプロイすることができるため、汎用的なミドルウェア・アプリケーション環境を迅速かつ安定的に提供できるメリットがもたらされます。

その一方、独自のカスタム・パターンを作成すれば、パターン・ベースの手法がもたらす価値はさらに高まります。そのため、IBM Workload Deployer には、サポートしている仮想システム・パターンおよび仮想アプリケーション・パターンの両方を対象に、包括的なカスタマイズ機能が用意されています。

IBM Workload Deployer は、その前身である WebSphere CloudBurst の仮想システム・パターンを継承しています。製品名は変更されていても、このタイプのパターンをカスタマイズするための一般的な概念と手法はほとんど変わっていません。これらのカスタマイズ手法については、この記事では取り上げませんが、developerWorks の連載「WebSphere CloudBurst を使ってカスタマイズする」で、仮想システム・パターンをカスタマイズする各種の手法を詳しく説明しているので参照してください。

この記事では以降、IBM Workload Deployer での仮想アプリケーション・パターンのカスタマイズに焦点を絞り、最後にカスタマイズの一例を紹介して記事を締めくくります。

仮想アプリケーション・パターンをカスタマイズする

仮想アプリケーション・パターンは、IBM Workload Deployer バージョン 3 で導入された新たなデプロイメント・モデルです。このタイプのパターンでは、完全にアプリケーションを中心とした手法によって、クラウド内のミドルウェア・アプリケーション環境を構築、デプロイ、および管理します。

仮想アプリケーション・パターンを作成するには、アプリケーションを提供し、そのアプリケーションの機能要件と非機能要件の両方を指定します。すると、IBM Workload Deployer はユーザーからの入力を取り、その情報を基にして、ミドルウェア・アプリケーション環境のインストールから構成、統合までを完全に行います (図 1 を参照)。

仮想アプリケーション・パターンのユーザーは、ミドルウェアとアプリケーションをどのようにインストール、構成、または統合するかを知る必要はありません。これらの情報は、パターンにカプセル化されます。どのようにカプセル化されるかと言うと、すべてはプラグイン次第です。

仮想アプリケーション・パターンに対してプラグインが果たす役割

図 2 は、IBM Workload Deployer Pattern for Web Applications の基本的な例です。この例から、仮想アプリケーション・パターンの主要な要素がわかります。

ご覧のように、仮想アプリケーション・パターンは、コンポーネント (Components)、リンク (Links)、ポリシー (Policies) で構成されます。

• コンポーネントは、特定のワークロードの機能プロファイルを表します。Web アプリケーションの仮想アプリケーション・パターンの場合には、エンタープライズ・アプリケーション (EAR ファイル)、Web アプリケーション (WAR ファイル)、データベース、OSGI アプリケーションなどに対応するコンポーネントがあります。これらのコンポーネントは、環境を構築してデプロイする際に不可欠です。
  
• リンクは、仮想アプリケーション・パターンを構成するコンポーネント間の統合ポイントを表現します。図 2 に示されているパターンでリンクが示しているのは、このパターン内ではエンタープライズ・アプリケーションがデータベース・コンポーネントに依存することです。
  
• ポリシー (図 2 に示されている Scaling Policy など) は、アプリケーション環境の機能要件と非機能要件を指定するために使用します。ポリシーは、環境の構成および継続的管理の両方の側面を決定付けます。

仮想アプリケーション・パターンを作成し、デプロイする際には、図 2 に示した形でビジュアル・エディターを操作します。エンド・ユーザーにとってビジュアル・エディターは、完全に構成および統合された動的なクラウド・ベースの環境を素早く簡単に構築およびデプロイする手段となります。

仮想アプリケーション・パターンによって表現されてカプセル化される機能は、何らかの手段で提供されなければなりません。そこで登場するのが、プラグインです。仮想アプリケーション・パターンから入手するインストール機能、構成機能、統合機能、そして管理機能はすべて、1 つまたは複数のプラグインによって提供されます。プラグインは、仮想アプリケーション・パターンのユーザーが使用できるコンポーネント、リンク、ポリシーを定義し、必要な機能によってこれらの要素をバックアップします。

嬉しいことに、IBM Workload Deployer の設計は公開されているため、皆さんが独自に作成したプラグインをシステムで使えるようにすることができます。この点が重要な理由は、例えばカスタム・ソフトウェアでのカスタム・ワークロードに対応するために独自の仮想アプリケーション・パターン・タイプを作成しなければならない場合や、IBM Workload Deployer が提供する仮想アプリケーション・パターンを拡張したいという場合を考えてみてください。そのような場合、1 つ以上のカスタム・プラグインを開発しなければならなくなります。

この記事ではカスタム・プラグインの作成方法に焦点を当て、例として、IBM Workload Deployer Pattern for Web Applications を拡張して WebSphere Application Server Community Edition をサポートするためのカスタム・プラグインを作成します。この例によって、プラグインの全体的なアーキテクチャー、IBM が新たに提供している Plug-in Development Kit の使用方法、そしてカスタム・プラグインを IBM Workload Deployer に追加する方法についての基礎知識を提供します。では早速、本題に入りましょう。

上に戻る

プラグインを作成するステップ

WebSphere Application Server Community Edition をサポートするためのカスタム・プラグインの作成に取り掛かる前に、プラグインの作成ステップについて理解しておかなければなりません。標準的なプラグインの作成ステップには次の 6 つの段階があります。

1. デプロイメントの前に、プラグインの定義全体が config.json ファイルに規定されます。
2. デプロイメントの時点で、アプリケーション・モデルが未解決トポロジーに変換されます。
3. 未解決トポロジーが解決済みトポロジーに変換されます。
4. 必要なリソースがプロビジョニングされ、解決済みトポロジーが最終トポロジーに変換されます。
5. プライベート･クラウドへのデプロイメントが実際に行われます。
6. デプロイ後の仮想マシンでソフトウェアがインストール、構成、起動されます。

デプロイメント前

プラグインの定義全体が config.json 構成ファイルに規定されます。config.json ファイルには、以下に関する情報が格納されます。

• インストールするパッケージ (ミドルウェアまたはその他のソフトウェア)
• ハードウェアの基本要件 (インストールされたパッケージをホストする VM を 32 ビットにするか、64 ビットにするかなど)
• プラグインの名前、バージョン、関連付けるパターン・タイプ

仮想アプリケーション・パターンを作成するには、Virtual Application Builder ツールを使用します。パターンを構成するコンポーネント、リンク、ポリシーは、それぞれ metadata.json という名前のプラグイン構成ファイルに定義します。metadata.json ファイルには、コンポーネント、リンク、ポリシーごとに以下の情報を定義します。

• 名前、説明、そして Virtual Application Builder でプラグインをグラフィックで表現するために使用するアイコン
• デプロイメント VM でパッケージを構成するときに使用する、構成可能な属性

デプロイメント

Virtual Application Builder は、ユーザーが metadata.json に定義された情報を元に作成したパターンを使用してアプリケーション・モデルを作成します。図 2 は、コンポーネント、リンク、ポリシーで構成されたアプリケーション・モデルの一例を図で表したものです。このようなアプリケーション・モデルが徐々に作り込まれていって最終的なデプロイメントが行われます。このプロセスの各ステップの実行は、IBM Workload Deployer によって調整されます。

デプロイメント・プロセスの最初のステップは、アプリケーション・モデル (App model) から未解決トポロジー (Unresolved topology) への変換です。未解決トポロジーは汎用的なトポロジーであり、組み込む必要があるパッケージ、そしてメモリーとディスクの要件といった情報が含まれます。未解決トポロジーへの変換に使用される <template>.vm は、ユーザーが定義します。

2 番目のステップでは、未解決トポロジー (Unresolved topology) が解決済みトポロジー (Resolved topology) に変換されます。このプロセスを完了するために必要な変換データは、config.json ファイルに含まれます。このプロセスの重要な部分は、アプリケーション・モデルの要件 (オペレーティング・システム、アーキテクチャー、ディスク、メモリー) をプラグインが提供する構成要素にマッピングすることです。

3 番目のステップで、最終的なトポロジー (Final topology) が作成されます。IBM Workload Deployer が解決済みトポロジーの文書を使用して、必要なすべてのリソースをプロビジョニングし、最終的なトポロジー文書を作成します。

4 番目のステップは、プライベート・クラウドへの実際のデプロイメントです。図 3 に、デプロイメント・プロセスと、このステップに必要な構成ファイルを示します。

5 番目かつ最後のステップは、デプロイ後の仮想マシンにソフトウェアをインストールし、構成し、起動することです。このステップは、インストールするソフトウェアごとに定義する install.py、configure.py、および start.py というライフサイクル・スクリプトによって行われます。

part と nodepart

カスタム・プラグインの作成に取り掛かる前に、part と nodepart について説明しておきます。この 2 つは、以降のセクションに大きく関わってくるからです。

プラグインに組み込まれるパッケージには、part と nodepart の両方が含まれています。part および nodepart はそれぞれ特定の成果物 (ソフトウェア製品など) に対応します。技術的な観点から言うと、part と nodepart は両方ともソフトウェアをインストールし、構成し、起動するために使用されるという点で、この 2 つの間に違いはありません。

論理的な観点から言うと、nodepart は一般に、ファイアウォールなどのシステム･レベルのソフトウェアをインストール、構成、および起動するために使用される一方、part は WebSphere Application Server Community Edition などのミドルウェア・タイプのソフトウェアをインストール、構成、起動するために使用されます。

上に戻る

カスタム・プラグインを作成する

記事の残りでは、WAS CE (WebSphere Application Server Community Edition) 上で実行されるエンタープライズ・アプリケーション (EAR) および Web アプリケーション (WAR) ファイルをサポートするためのカスタム・プラグインの作成プロセスを詳しく辿ります。大まかな概要として、以下のステップについて説明します。

1. プラグイン成果物を定義し、パッケージ化する
2. Virtual Application Builder で表示される構成可能なアプリケーション・モデル・コンポーネントを定義する
3. アプリケーションの仮想モデルを物理モデルに変換するためのテンプレートを定義する
4. デプロイ後の仮想マシンでソフトウェアをインストール、構成、および起動するためのライフサイクル・スクリプトを定義する

プラグイン成果物を定義し、パッケージ化する

プラグイン成果物をパッケージ化する際に選択可能な方法については、この後すぐに説明しますが、どのパッケージ化メカニズムを使用するにしても、プラグイン・アーカイブ内の config.json ファイルに成果物に関する情報を記述する必要があります。リスト 1 に、サンプル WASCE プラグインの config.json を記載します。

{
   "name"    : "wasce",
   "version" : "1.0.0.1",
   "patterntypes": {
      "secondary"  : { "*":"*" }
   },
   "packages" : {
      "WASCE" : [ {
            "requires"  : {
               "arch"   : "x86_64",
               "memory" :  512,
               "disk"   :  300
            },
            "parts":[ {
                  "part"  : "parts/wasce.tgz",
                  "parms" : {
                     "installDir" : "/opt/wasce"
                  }
            } ], 
      "WASCE_SCRIPTS":[ {
            "parts":[ {
                  "part":"parts/wasce.scripts.tgz"
            } ]
      } ]
      } ]
   }
}

プラグインに必ず含まれていなければならないファイルは、この config.json ファイルだけです。name、version、および patterntypes はすべて必須の要素です。

• name 要素は、プラグインの名前を指定します。
• version 要素は、プラグインのバージョン番号を定義します。
• patterntypes 要素は、プラグインを関連付けるパターン・タイプを指定します。

サンプル WASCE プラグインは、patterntypes の値に webapp を指定することで、IBM Workload Deployer Pattern for Web Applications パターンを拡張します。これは、IBM Workload Deployer に同梱されている Web アプリケーション・パターンからパターンを作成する際に、この例で私たちが定義するコンポーネントが選択可能になることを意味します。

プラグインにデプロイする仮想マシンに必要なオペレーティング・システムおよびビット・アーキテクチャー構成は、requires 要素を使って指定します。サンプル・プラグインの仮想マシンに指定したのは、64 ビットの x86 アーキテクチャーです。

memory 要素と disk 要素は、プラグインで定義されたパッケージごとの最小ディスク要件、最小メモリー要件をそれぞれ指定します。プロビジョニングのプロセスで、IBM Workload Deployer は各パッケージの最小値を合計して、指定された要件を満たす仮想マシンをプロビジョニングします。

packages 要素は、part 要素と nodepart 要素の両方を使ってファイル・パッケージを定義します。サンプル・プラグインが提供するパッケージは、WASCE と WASCE_SCRIPTS の 2 つです。WASCE パッケージには parts/wasce.tgz part ファイルが含まれ、このアーカイブに WebSphere Application Server Community Edition をインストールするために必要なバイナリーが含まれるので、このバイナリーをプラグインに直接パッケージ化します。

必要なバイナリーを指定する方法は他にもあります。例えば、ファイル属性を定義して、プラグインが IBM Workload Deployer にロードされた後に、必要なバイナリーを管理者にアップロードさせるという方法もあります。また、必要な成果物が格納されているリモート・サーバーにリンクすることも可能です。WASCE_SCRIPTS パッケージが提供するライフサイクル・スクリプトによって、WASCE イメージが指定の場所にインストールされ、EAR ファイルまたは WAR ファイルがインストールされ、サーバーが起動されます。

構成可能なアプリケーション・モデル・コンポーネントを定義する

アイコン・グラフィックを作成する作業を抜かせば、このステップを完了するのは簡単です。Web アプリケーションとエンタープライズ・アプリケーションは、Virtual Application Builder でユーザーに表示する必要があるコンポーネントなので、このそれぞれを、プラグイン・アーカイブの plugin/appmodel ディレクトリーに配置された metadata.json ファイルで指定します。リスト 2 に、Web アーカイブ・コンポーネントを定義する JSON を記載します。

[
 {
        "id"          : "WARCE",
        "label"       : "Web Application (WebSphere Application Server 
                         Community Edition)",
        "description" : "A web application cloud component represents an execution 
                        service for Java EE Web applications (WAR files).",
        "type"        : "component",
        "thumbnail"   : "appmodel/images/WASCE.png",
        "image"       : "appmodel/images/WASCE.png",
        "category"    : "application",
        "attributes"  : [
            {
                "id"          : "archive",
                "label"       : "WAR File",
                "description" : "Specifies the web application (*.war) to 
                                be uploaded.",
                "type"        : "file",
                "required"    : true,
                "extensions"  : [ "war" ] 
            }
        ]
 } 
]

エンタープライズ・アーカイブ･コンポーネントのダウンロード可能なアーカイブにも、上記と同じようなスタンザがあります。このリストで重要なのは、最初の type フィールドです。このフィールドで選択できる値には component、link、または policy があり、ここで選択したタイプが、アプリケーション・モデルに定義されるためです。上記のコンポーネントの id は WARCE となっていますが、一意の値である限り、任意の値を設定することができます。category は、Virtual Application Builder のパレットでこのコンポーネントを表示するタブを参照します。attributes 配列は、現在定義しているコンポーネントのプロパティーを定義します。ユーザーが Virtual Application Builder でこのコンポーネントを使用するときには、このファイルで定義されたプロパティーが表示され、それぞれの値を指定することができます。type 属性の値には、file (上記で使用)、string、number、Boolean、array、および range があります。

仮想モデルを物理モデルに変換するためのテンプレートを定義する

プラグインは、定義したコンポーネントのデプロイメントを実装 (つまり、実現) する方法についての情報を提供する必要があります。この例の場合で言うと、エンタープライズ・アプリケーションまたは Web アプリケーションのコンポーネントをデプロイする意味を指定する必要があるということです。

これを指定するために、ユーザーが Virtual Application Builder で構成した情報を基に作成されるアプリケーション・モデルを具体的なトポロジーに変換するための単一の変換テンプレートを用意します。リスト 3 に、具体的なトポロジーへの変換に使用する JSON ファイルの一部を記載します。このような変換は、コンポーネントおよびリンクごとに必要です。サンプル・プラグインでは、WARCE コンポーネントと EARCE コンポーネントが同じ変換テンプレートを共有します。

{
   "vm-templates":[
      {
         "name"     : "${prefix}-wasce",
         "packages" : [ "WASCE", "WASCE_SCRIPTS" ],
         "roles"    : [
            {
               "plugin"       : "$provider.PluginScope",
               "name"         : "WASCE",
               "type"         : "WASCE",
               "quorum"       : 1,
               "external-uri" : [{"ENDPOINT":"http://{SERVER}:8080"}],
               "parms":{
                  "ARCHIVE"   : "$provider.generateArtifactPath( $applicationUrl, 
                                ${attributes.archive} )"
               },
               "requires"     : { "memory":512, "disk":300 }
            }
         ],
         "scaling" : { "min":1, "max":1 }
      }
   ]
}

上記のトポロジー・フラグメントは、vm-template の配列からなる vm-templates 要素が含まれる JSON オブジェクトです。vm-template とは仮想マシン・テンプレートのことで、デプロイする仮想マシンの parts、nodeparts、および attributes を定義します。この例には、以下の3 つの重要な要素が含まれる vm-template が 1 つだけ必要です。

1. name: デプロイする仮想マシンの固有名。
2. packages: この要素は、デプロイされる仮想マシンごとにインストールされる parts と nodeparts のリストを指定します。WASCE エントリーは WASCE 仮想イメージを使用することを意味し、WASCE_SCRIPTS エントリーは WASCE ライフサイクル・スクリプト (次のセクションで説明) を示します。
3. roles: プラグインに含まれる parts は、roles のライフサイクル・スクリプトを呼び出します。プラグインには 1 つ以上の roles を使用することができますが、この例で使用しているのは 1 つの WASCE ロールだけです。ノードに指定されたすべての roles が RUNNING 状態になった時点で、ノード自体が緑色の RUNNING 状態になります。

ソフトウェアをインストール、構成、および起動するライフサイクル・スクリプトを定義する

ここまでで、プラグイン用のライフサイクル・スクリプトを定義する準備ができたので、プラグインを構成するコンポーネントをインストールするスクリプト、構成するスクリプト、および起動するスクリプトを作成することになります。完全なスクリプトはダウンロード可能なアーカイブで確認することができますが、ここでは重要な成果物をいくつか取り上げて説明します。

wasce の install.py

install.py スクリプトは、ダウンロード場所にある WASCE イメージを目的の installDir にコピーします。また、後続のスクリプトのために環境内で installDir 値を設定します。

IBM Workload Deployer エージェントによってインストールされる parts と nodeparts はすべて、root として実行されます。chown -R virtuser:virtuser コマンドが、インストールされたコンテンツのファイル所有権を目的のユーザーおよびグループに変更します。

最後に、install.py スクリプトは WebSphere Application Server Community Edition の bin ディレクトリーに配置されたスクリプトを実行できるようにします。install.py スクリプトの内容は、リスト 4 のとおりです。

installDir = maestro.parms['installDir']
maestro.trace_call(logger, ['mkdir', installDir])

if not 'WASCE' in maestro.node['parts']:
    maestro.node['parts']['WASCE'] = {} 
maestro.node['parts']['WASCE']['installDir'] = installDir

# copy files to installDir to install WASCE
this_file = inspect.currentframe().f_code.co_filename
this_dir = os.path.dirname(this_file)
rc = maestro.trace_call(logger, 'cp -r %s/files/* %s' % (this_dir, installDir), 
 shell=True)
maestro.check_status(rc, 'wasce cp install error')

rc = maestro.trace_call(logger, ['chown', '-R', 'virtuser:virtuser', installDir])
maestro.check_status(rc, 'wasce chown install error')

# make shell scripts executable
rc = maestro.trace_call(logger, 'chmod +x %s/bin/*.sh' % installDir, shell=True)
maestro.check_status(rc, 'wasce chmod install error')

リスト 4 には、このスクリプトがプラグイン・フレームワーク内に提供されている maestro モジュールを使用する方法が示されています。このモジュールには、インストールなどの際に役立つヘルパー・メソッドがいくつか用意されています。

wasce.scripts の install.py

wasce.scripts part にも、install.py スクリプトがあります。このスクリプトは、WebSphere Application Server Community Edition のライフサイクル・スクリプトをインストールします。

# Prepare (chmod +x, dos2unix) and copy scripts to the agent scriptdir
maestro.install_scripts('scripts')

wasce.scripts の configure.py

wasce.scripts part に含まれる configure.py スクリプトは、ユーザー提供のアプリケーションを WebSphere Application Server Community Edition にインストールします。このスクリプトは WebSphere Application Server Community Edition のホット・デプロイ機能を利用して、アプリケーションのバイナリーをモニター対象のディレクトリーに単純にコピーします。リスト 6 に、configure.py の内容を記載します。

installDir = maestro.node['parts']['WASCE']['installDir']

ARCHIVE = maestro.parms['ARCHIVE']
archiveBaseName = ARCHIVE.rsplit('/')[-1]
# Use hot deploy
deployDir = os.path.join(installDir, 'deploy')
if os.path.exists(deployDir) == False:
        # Make directories
        os.makedirs(deployDir) 
deployFile = os.path.join(deployDir, archiveBaseName)

# Download WASCE archive file
maestro.download(ARCHIVE, deployFile)

wasce.scripts の start.py

wasce.scripts part に含まれる start.py スクリプトの役目は、WebSphere Application Server Community Edition プロセスを起動することです。プロセスを起動した後、ロールの状態を RUNNING に更新します。デプロイメントが RUNNING 状態になると、デプロイされたアプリケーション環境へのアクセスが可能になります。リスト 7 では、WebSphere Application Server Community Edition を起動するための geronimo.sh start コマンド、ならびに起動を待機するための gsh.sh コマンドが使われています。

wait_file = os.path.join(maestro.node['scriptdir'], 'WASCE', 'wait-for-server.txt')

installDir = maestro.node['parts']['WASCE']['installDir']

rc = maestro.trace_call(logger, ['su', '-l', 'virtuser', installDir + 
  '/bin/geronimo.sh', 'start'])
maestro.check_status(rc, 'WASCE start error')

logger.info('wait for WASCE server to start')

rc = maestro.trace_call(logger, ['su', '-l', 'virtuser', installDir + '/bin/gsh.sh', 
  'source', wait_file])
maestro.check_status(rc, 'wait for WASCE server to start error')

maestro.role_status = 'RUNNING'

logger.info('set WASCE role status to RUNNING')  

logger.debug('Setup and start iptables')
maestro.firewall.open_tcpin(dport=1099)
maestro.firewall.open_tcpin(dport=8080)
maestro.firewall.open_tcpin(dport=8443)

プラグインを構成するスクリプトおよび成果物は他にもありますが、最も重要なものはここまでで紹介しました。プラグインの完全な内容を調べるには、記事の終わりで紹介しているリンクからプラグインをダウンロードしてください。

Eclipse プラグインのまとめ

図 4 に、Eclipse の「Package Explorer (パッケージ・エクスプローラー)」ビューに表示された、wasce プラグインの全構成要素を示します。

上に戻る

プラグインをインストールして使用する

WebSphere Application Server Community Edition プラグインを作成すると、その内容は .tgz ファイルにパッケージ化されます。パッケージ化された新規プラグインは IBM Workload Deployer リポジトリーにロードしてください。ロードが完了すれば、早速、新しいプラグインのコンポーネントを使用して仮想アプリケーション・パターンを作成し、そのパターンをデプロイすることができます (このステップを実行する無料の PDK (Plug-in Development Kit) を入手して使用する方法については、「参考文献」の IWD Plug-in Development Kit を参照してください)。

プラグインをロードする

プラグインをロードする手順は以下のとおりです。

1. IBM Workload Deployer ユーザー・インターフェースを開きます。
2. ページ上端のメニューから、「Cloud (クラウド)」メニューを選択し、「System Plug-ins (システム・プラグイン)」リンクをクリックします。
3. 緑色の + アイコンをクリックして、.tgz ファイルをアップロードします。ファイルのロードが完了したら、プラグインの属性を確認することができます (図 5 を参照)。
   
   図 5. インポートされたプラグインの定義
   
   
   

図 5 を見るとわかるように、wasce プラグインでは、定義したエンタープライズ・アプリケーション・コンポーネントと Web アプリケーション・コンポーネントの両方が表示されます。

新規プラグインを使用する

新規プラグインのロードが完了したら、プラグインのコンポーネントを使って新しい仮想アプリケーション・パターンの作成に取り掛かることができます。この作業には、IBM Workload Deployer の Virtual Application Builder を使用します。

1. 上部ツールバーで「Patterns (パターン)」メニューをクリックし、次に「Virtual Applications (仮想アプリケーション)」リンクをクリックします。
2. 新しいパターンを作成するには、緑色の + アイコンをクリックします。図 6 に示されているように、パターン・タイプが Web アプリケーションになっていることを確認した上で、空白のテンプレートを選択します。
   
   図 6. 仮想アプリケーション・パターンの新規作成
   
   
   
3. 「Start Building (ビルドの開始)」ボタンをクリックして、Virtual Application Builder をアクティブにします。
4. ビルダーが表示されたら、「Application Components (アプリケーション・コンポーネント)」セクションを展開します。すると、WebSphere Application Server Community Edition サーバーをベースとしたエンタープライズ・アプリケーションおよび Web アプリケーション両方のコンポーネントが表示されます。これらのコンポーネントをキャンバスにドラッグ・アンド・ドロップすることで、パターンに追加します。図 7 には、新規 Web アプリケーション・コンポーネントが使用されている様子が示されています。
   
   図 7. 新規コンポーネントの使用
   
   
   
5. プラグインに含まれるコンポーネントの定義ごとに、「Name (名前)」と「WAR File (WAR ファイル)」という 2 つのプロパティーがあります。この 2 つはどちらも必須プロパティーです。「WAR File (WAR ファイル)」プロパティーには、ファイル・アップロード・ダイアログがあります。新規パターンの作成が完了したら、Virtual Application Builder の上端にある「Save (保存)」ボタンまたは「Save As (名前を付けて保存)」ボタンをクリックして、そのパターンを保存してください。これで、新規パターンをデプロイする準備ができました (詳細については、「参考文献」に記載されている wasce サンプル・インストール・バンドルのダウンロードを参照してください)。

カスタム仮想アプリケーション・パターンをデプロイする

1. 「Patterns (パターン)」メニューを選択し、「Virtual Applications (仮想アプリケーション)」リンクをクリックして、仮想アプリケーション・パターンのページに戻ります。
2. 画面左側のリストから、新規仮想アプリケーション・パターンを選択します。
3. 「Deploy to Cloud (クラウドにデプロイ)」アイコンをクリックして、適切なクラウド・グループを選択した後、「OK」をクリックします。

以上の操作で、IBM Workload Deployer は環境のデプロイメントを開始します。さらに環境をインストール、構成、および起動するためのスクリプトとしてプラグインのなかで定義されたライフサイクル・スクリプトを自動的に呼び出します。

デプロイされたアプリケーションを確認する

デプロイメント・プロセスをモニターするには、「Instances (インスタンス)」メニューを選択して、「Virtual Applications (仮想アプリケーション)」リンクをクリックします。デプロイメントに含まれる仮想マシンごとに、関連するステータスがあります。Web アプリケーション仮想マシンまたはエンタープライズ・アプリケーション仮想マシンの場合には、デプロイメントが RUNNING 状態になると、エンドポイント・リンクが表示されるはずです (図 8 を参照)。

エンドポイント・リンクをクリックすると、ポップアップ・ダイアログに、デプロイされたアプリケーションの URL が表示されます。その URL をクリックすれば、アプリケーションにアクセスすることができます。

上に戻る

まとめ

仮想アプリケーション・パターンは、アプリケーションを中心にしたクラウド・エクスペリエンスを促進するための大胆な措置です。仮想システム・パターンの例のように、IBM Workload Deployer の設計では、このデプロイメント成果物の広範なカスタマイズが可能となります。プラグインを作成し、仮想アプリケーション・パターンを細部までカスタマイズすることによって、自分の要求に合ったクラウド・ベースのデプロイメントを作成することができます。この連載の今後の記事もお見逃しなく。プラグインと仮想アプリケーション・パターンのカスタマイズ手法を拡張していきます！

参考文献

学ぶために

• IWD Plug-in Development Kit についてウィキで詳細を学んでください。
  
  
• developerWorks の IBM Workload Deployer コミュニティーに参加して、最新情報を入手してください。
  
  
• IBM Cloud でのタスクの実行方法についての詳細は、以下のリソースにアクセスしてください。
  • 「Windows インスタンスとの間でのファイルのアップロードとダウンロード」
  • 「Windows Server 2008 R2 に IIS Web サーバーをインストールする」
  • 「Linux のコマンド・ラインを使用して IBM Cloud インスタンスを作成する」
  • 「Create an IBM Cloud instance with the Windows command line」
  • 「Extend your corporate network with the IBM Cloud」
  • 「IBM Cloud での高可用性アプリケーション」
  • 「カスタム・インスタンスのクラウド・イメージをオンザフライでパラメーター化する」
  • 「Windows-targeted approaches to IBM Cloud provisioning」
  • 「Rapid Deployment Service を使用して製品をデプロイする」
  • 「Integrate your authentication policy using a proxy」
  • 「Linux Logical Volume Manager を構成する」
  • 「複雑なトポロジーをデプロイする: IBM Cloud でデプロイメント・ユーティリティー･ツールを使用する」
  • 「Provision and configure an instance that spans a public and private VLAN」
  
  
• developerWorks のクラウド開発者向けリソースで、クラウド開発プロジェクトを作成しているアプリケーションおよびサービス開発者たちの知識と経験を調べて共有してください。
  
  
• IBM SmartCloud Enterprise にアクセスする方法を調べてください。
  
  

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

• IBM Plugin Development Kit をダウンロードしてください。プラグインとパターン・タイプを作成するためのビルド・ライブラリーとビルド・スクリプト、サンプル・プラグインとパターン･タイプ、そしてユーザー・ガイドも付属しています。
  
  
• wasce_samples-version.zip サンプル・インストール・バンドルは、ここからダウンロードできます。
  
  
• IBM SmartCloud Enterprise に用意された製品イメージを調べてください。
  
  

議論するために

• IWD developerWorks コミュニティーのメッセージ・ボードを利用して質問を投稿してください。
  
  
• developerWorks のクラウド・コンピューティング・グループの一員になってください。
  
  
• developerWorks でクラウドに関する優れたブログのすべてを読んでください。
  
  
• 専門家のネットワークであるとともに、互いにつながりを持ち、共有、協力するためのコミュニティー・ツールが集められている developerWorks コミュニティーに加わってください。
  
  

著者について

Dustin Amrhein は、WebSphere Application Server 開発チームのメンバーとして IBM に入社しました。この開発チームに在籍している間、主にWeb サービス・インフラストラクチャーと Web サービス・プログラミング・モデルに取り組んでいました。さらにJava ランタイムを対象とした RESTful なサービス・フレームワークの開発にも携わっていました。現在の任務は、技術エバンジェリストとしてIBM WebSphere ポートフォリオの新しい技術を広めることです。

Ted Kirby は、ノース・カロライナ州リサーチ・トライアングルにある IBM で IBM Workload Deployer Pattern for Web Applications のプラグイン・サポートを開発しています。彼は現在、Apache Geronimo コミッターであり、WebSphere Application Server Community Edition の開発者でもありました。以前は大量トランザクション処理の WebSphere テクニカル・エバンジェリストとして、eCommerce Web サイトの拡張と保守、および Deep Blue マシンで使用されているシステムを含め、分散オペレーティング・システムの開発にも携わっています。

Brian Stelzer は、IBM Workload Deployer チームのソフトウェア・エンジニア兼チーム・リーダーです。現在は、IBM Workload Deployer、WebSphere Application Server、および VMware ベースの技術を重点としたクラウド環境のトレーニングおよびアーキテクチャー・ソリューションを提供する役割を果たしています。以前は、WebSphere Application Server および WebSphere Application Server Community Edition を対象としたマイグレーション・ソリューションを設計していました。

この記事を評価する

コメント

上に戻る

目次

• 仮想アプリケーション・パターンをカスタマイズする
• プラグインを作成するステップ
• カスタム・プラグインを作成する
• プラグインをインストールして使用する
• まとめ
• 参考文献
• 著者について
• コメント