IBM Pattern Development Kit を使用して仮想アプリケーション・パターンを作成する: 第 1 回 Tomcat と HTTP Server をインストールするための仮想アプリケーション・パターン・プラグイン・プロジェクトを作成する

IBM PureApplication System の仮想アプリケーション・パターンは、Platform as a Service パターンを作成するために簡単に使用できる強力な機能を提供します。この全 3 回からなる連載記事では、IBM Pattern Development Kit を使用して、いくつかの昔ながらの Web プラットフォーム・トポロジーを導入するための仮想アプリケーション・パターンを作成する方法を紹介します。仮想アプリケーション・パターンの機能を実演するために、このパターンには、オープンソース・ソフトウェアの Apache Tomcat、Apache HTTP Server、および LiveJournal memcached を組み込みます。

Qi Liu, Software Engineer, IBM

Photo of Qi LiuQi (Colin) Liu は、IBM Pattern Development Kit (PDK) の開発にバージョン 1.0.1.0 から携わっているソフトウェア・エンジニアです。以前は、Composite Application Pattern (CAP) プロジェクトの主要開発者や、BPM Process Server プラグイン開発のリーダーを務めていました。



Scott Walden, Software Engineer, IBM

Photo of Scott WaldenScott Walden は、IBM PureApplication System イネーブルメント・チームで働いています。このチームの設立趣旨には、さまざまなチームのカスタマー・イネーブルメントおよびインターナル・イネーブルメントが含まれています。このチームで働く以前の彼は、初期設計プログラム、ベータ・プログラム、カスタマー・アクセラレーション・プログラム、スキル・トランスファーなどを管理する AIM Early Programs チームで IBM Business Monitor のテクニカル・リーダーを務めていました。


developerWorks 貢献著者レベル

Qiang Wang, Software Engineer, IBM

Photo of Qiang WangQiang (Ace) Wang は、IBM Software Group の PureApplication Pattern Enablement and Pattern Development Kit チームに所属するスタッフ・ソフトウェア・エンジニアです。彼は、デジタル・メディア、銀行、医療などの業界を始めとする、数多くの業界ソリューションに参加してきました。彼は現在、クラウド・コンピューティング分野で働いています。



Wei Feng Li, Software Engineer, IBM

Photo of Wei Feng LiWei Feng (Banny) Li は、PureApplication System Pattern Development Kit の主要開発者です。パターン開発での豊富な経験がある彼は、現在主に PDK Eclipse ユーザー・インターフェース部分を担当しており、Application Delivery Pattern (ADP) や Composite Application Pattern (CAP) といったプロジェクトの主要なコントリビューターでもあります。さらに、Digital Media Management (DMM) および Knowledge Driver Application (KDA) アクセラレーターの開発にも参加しています。



2014年 2月 20日

はじめに

2013年 6月、IBM PureApplication System V1.1 と一緒に IBM Pattern Development Kit V1.0.1.0 がリリースされました。IBM Pattern Development Kit パッケージには、以下の場所からアクセスすることができます。

  • IBM PureApplication System のウェルカム・ページで、「Download Tooling (ツールのダウンロード)」 > 「Download IBM Pattern Plug-in Development Kit (IBM Pattern Plug-in Development Kit のダウンロード)」の順にクリックします。
  • IBM Workload Plugin Development Kit サイト

IBM Pattern Development Kit (PDK) パッケージには、Eclipse プラグイン・ツールのインストール・ファイル、仮想アプリケーション・パターン開発者用ドキュメント、および Hello/WASCE サンプル・プロジェクトが含まれています。Eclipse 用の IBM PDK は、Eclipse で使用する 2 つのパースペクティブを提供しています。以下にその 2 つを記載します。

  • 「Workload Plug-in Development」パースペクティブ: このパースペクティブには、仮想アプリケーション・パターン・プラグイン・プロジェクトのビルド、パッケージ化、インストールを支援するウィザード、エディター、ユーティリティーが含まれています。
  • 「Workload Plug-in Runtime」パースペクティブ: このパースペクティブには、インスタンス実行ログの表示、スクリプト・ファイルのアップロード、保留中インスタンスの再開を行うためのビューおよびユーティリティーが含まれています。

Apache Tomcat、Apache HTTP Server、および LiveJournal memcached は、中小規模の Web プロジェクトで幅広く使用されており、Java 開発者や学生の間で好評を博しています。これらのソフトウェアで構築された Web プラットフォーム・トポロジーは、馴染みがあって理解しやすいため、仮想アプリケーション・パターンの作成方法について学びやすくなります。この連載は、全 3 回の記事でパターンの機能を実演します。

  • 第 1 回: この (今、皆さんが読んでいる) 記事では、ユーザーが構成してデプロイすることが可能な個々のコンポーネントを作成します。
  • 第 2 回: この記事では、コンポーネント・リンク、スケーリング・ポリシー、およびインテント・ポリシーを作成する方法を説明し、第 1 回で作成したコンポーネントに適用可能なリンクとポリシーを作成して、デプロイメント時に有効にします。
  • 第 3 回: この記事では、memcached を共有サービスとして作成する方法を説明し、複数の Tomcat サーバー・インスタンスで共有できるシングルトン memcached サーバー・プールを作成します。

この第 1 回の記事には、パターン・タイプ・プロジェクトおよびいくつかのプラグイン・プロジェクトを含め、サンプル・プロジェクトのコードが付属しています。連載で使用するプロジェクトは、仮想アプリケーション・パターンの機能を明らかにして、プラグイン・プロジェクトの作成方法を実演するのを目的としていること、またその一方で、PureApplication System でこれらのオープンソース・ソフトウェアを有効に利用するための最初のステップであることを頭に入れておいてください。


ターゲット・シナリオ

Apache Tomcat (略称 Tomcat) は、オープンソースの Java Web サーバー兼サーブレット・コンテナーです。Apache HTTP Server (略称 HTTPD) は、Subversion で利用することのできる強力なネットワーク・サーバーです。LiveJournal memcached (略称 memcached) は、ハイパフォーマンスの分散型メモリー・オブジェクト・キャッシュ・システムです。昔ながらのトポロジーでは、Tomcat サーバーはワーカーとして HTTPD サーバーに登録し、Tomcat セッション・データを memcached に保管することで、障害が発生した Tomcat ノードをクラスター環境内でリカバリーできるようにします。この連載で取り上げるトポロジーには、単純なものから複雑なものまで、以下の 3 つのタイプがあります。

  • 開発用 (本記事と第 3 回の記事): Tomcat サーバー、HTTPD サーバー、memcached サーバーがそれぞれ独立した形で配備されており、サーバー同士は接続されていません (図 1 を参照)。
    図 1. 開発用配備
    開発用配備
  • テスト用 (第 2 回第 3 回の記事): 1 つの HTTPD サーバー、それに接続された 2 つの Tomcat サーバー、そして 2 つの Tomcat サーバーに接続された 1 つの memcached サーバーが配備されています (図 2 を参照)。
    図 2. テスト用配備
    テスト用配備
  • 本番用 (第 2 回第 3 回の記事): デフォルト設定を使用して、2 つの HTTPD サーバー、そのそれぞれに接続された 4 つの Tomcat サーバー、そして 4 つの Tomcat サーバーに接続された 1 つの memcached サーバーが配備されています (図 3 を参照)。
    図 3. 本番用配備
    本番用配備

パターン・タイプ・プロジェクトの作成

「パターン・タイプ・プロジェクト」とは、複数のプラグイン・プロジェクトが含まれるグループ定義です。パターン・タイプ・プロジェクトによって、プラグイン・プロジェクトとそれらのプラグイン・プロジェクトで使用されるインストール・ファイルのすべてを格納する 1 つの完全なパッケージを生成することができます。パターン・タイプ・プロジェクトでは、以下の要素を定義します。

  • patterntype.json 内のパターン・タイプ属性: これらの属性には、名前、短縮名、バージョン、説明、(パターン・タイプとバージョンの) 前提条件、(パターン・ビルダー・パレット内でコンポーネントをグループ化して表示するための) カテゴリー、および (製品の使用を追跡するための) ライセンスがあります。
  • ライセンス宣言ファイル
  • バージョン情報ファイル
  • 国際化対応メッセージ用 JSON ファイル: Web ページに表示される名前、短縮名、説明などの属性を国際化対応にするために使用されます。

サンプル・パターン・タイプ・プロジェクトの作成手順

IBM Pattern Development Kit がインストールされた Eclipse を起動します。まず、新規パターン・タイプ・プロジェクトを作成します。

  1. 「File (ファイル)」メニューから、「New (新規)」 > 「Project… (プロジェクト…)」 > 「IBM Workload Plug-in Development」 > 「IBM Workload Pattern Type Project」の順に選択します。
  2. 「New Project (新規プロジェクト)」ウィザードで、プロジェクト名として「patterntype.samples.apache」と入力します。パターン・タイプ名も同じ名前にします。
  3. 「Finish (完了)」をクリックします。これで、ウィザードによって新規パターン・タイプ・プロジェクトのスケルトンが生成されます。

次に、patterntype.json 内の属性を構成します。

  1. patterntype.json をダブルクリックしてパターン・タイプ・ページを開きます。このページには、「Overview (概要)」「patterntype.json」という 2 つのタブがあります。「Overview (概要)」タブはフォーム・エディターであり、「patterntype.json」タブはソース・エディターです。
  2. 「Overview (概要)」タブでは、基本情報を設定することができます。このフォーム・エディターは、名前に禁止された文字が含まれていないかどうか、バージョンのフォーマットが正しいかどうかなどの検証を含め、設定内容を即時に検証します。
  3. 「Prerequisite (前提条件)」セクションで「Add (追加)」をクリックし、「Name (名前)」属性と「Version (バージョン)」属性の値をそれぞれ「foundation」「*」に設定します。これにより、前提条件として foundation パターン・タイプの任意のバージョンが指定されます。
  4. 「Categories (カテゴリー)」セクションで「Add (追加)」をクリックし、「ID」属性、「Label (ラベル)」属性、「Description (説明)」属性の値をそれぞれ「samples.apache」「Apache」「Apache」に設定します。
  5. 名前と説明の各属性を国際化に対応させるために、まず、message.json ファイルに JSON フォーマットでキーと値のペアを定義します。次に、patterntype.json 内の name 属性と description 属性の値を、それぞれに関連するキーで置き換えます。例として、リスト 1 とリスト 2 を参照してください。このサンプル・パターン・タイプでサポートする言語は英語だけなので、「locales/en/messages.json」ファイルのみを更新します。
    リスト 1. locales/en/message.json ファイル
    {
    "PATTERN_TYPE_NAME":"Samples with OpenSources",
    "PATTERN_TYPE_DESC":"This pattern type includes Apache tomcat,
    http server and memcached, which are used as samples. No license/responsibility
    for these"
    }
    リスト 2. patterntype.json
    {
       "name": "PATTERN_TYPE_NAME",
       "shortname": "patterntype.samples.apache",
       "version": "1.0.0.0",
       "description": "PATTERN_TYPE_DESC",
       "status": "",
       "prereqs": {
          "foundation": "*"
       },
       "categories": [
          {
             "id": "samples.apache",
             "label": "Apache",
             "description": "Apache"
          }
       ]
    }
  6. パターン・タイプ・プロジェクトは、これで完成です。次に、「Window (ウィンドウ)」 > 「Preferences (設定)」 > 「IBM Pattern Toolkit」の順に選択し、PureApplication System で使用しているホスト名、ユーザー ID、パスワードを入力して「OK」をクリックします。そして、完成したプロジェクトを右クリックします。
  7. ポップアップ・メニューで、「IBM Toolkit」 > 「Install/Update to Deployer (デプロイヤーへのインストール/更新)」の順に選択します。これで、ツールによってプロジェクトが作成されて、ターゲット・システムにインストールされます。現時点では、このパターン・タイプ・プロジェクトには、プラグイン・プロジェクトが含まれていないため、このプロジェクトは、何もデプロイすることができない単なるパターン・タイプ定義でしかありません。

必要な追加作業

パターン・タイプ・プロジェクトには、パターン・タイプを特徴付けるものをいくつか追加する必要があります。

  1. ライセンス宣言ファイルを追加します。最初に、プロジェクトのルート・フォルダー内に licenses フォルダーを作成し、そこにライセンスに関するコンテンツ・ファイルを [言語コード].html という名前で追加します。例えば英語の場合、ファイル名は「en.html」となります。
  2. 製品ライセンスを追跡するための製品 ID を追加します。それにはまず、製品 ID を patterntype.json 内で宣言します。次に、JSON の「vm-templates」という部分でプラグイン・プロジェクトにおけるライセンス使用について設定します。リスト 3 に、Hello サンプル・プロジェクトでの構成例を記載します。
    リスト 3. patterntype.json 内での製品 ID と VM テンプレート
    # Declaration in patterntype.json
    "license": {
        "pid": "5725D65",
        "type": "PVU"
    }
    
    # Usage in VM template which can use more than one license in one VM
    {
        "vm-templates": [
            {
                "name": "${prefix}-HVM",
                "packages": [
                    "Hello",
                    "HCUtils"
                ],
                "roles": [
                    {
                        "plugin": "$provider.PluginScope",
                        "type": "Hello",
                        "name": "Hello",
                        "parms": {
                            "Hello_Sender": "$attributes.sender"
                        }
                    }
                ],
              "licenses": [
                    {
                        "ptype.hello": "2.0"
                    }
                ]
            }
        ]
    }
  3. パターン・タイプのバージョン情報を追加します。まず、プロジェクトの下に about フォルダーを作成して、そこにパターン・タイプのバージョン情報に関するコンテンツ・ファイルを「[言語コード].html」という名前で追加します。

Tomcat プラグイン・プロジェクトの作成

このプラグイン・プロジェクトは、以下の処理

  • Tomcat サーバーをインストールします。Tomcat インストール・ファイルをダウンロードして、指定された場所にインストールします。
  • サーバーを構成して起動します。実行中の Tomcat サーバーには、JAVA_HOME および CLASS_PATH などの環境変数が必要です。また、ユーザー、ポート、パスワードなどの設定で構成を更新します。
  • パターンの作成時に、ユーザーから要求されている場合にはアプリケーションをデプロイします。
  • インスタンスのデプロイ後に、コンソール・ページで実行可能な管理操作を提供します。例えば、新規アプリケーションのデプロイやサーバーの再起動などの操作です。

このプラグイン・プロジェクトに含める Tomcat インストール・バイナリーは、Linux 用の apache-tomcat-7.0.40.tar.gz です。次のセクションで、このプロジェクトの作成手順を説明します。

ステップ 1: プラグイン・プロジェクトのスケルトンを作成する

PDK では、プラグイン・プロジェクトのスケルトンを生成するためのウィザードを提供しています。

  1. Eclipse の「File (ファイル)」メニューから、「New (新規)」 > 「Project… (プロジェクト…)」 > 「IBM Workload Plug-in Development」 > 「IBM Workload Plug-in Project」の順に選択します。
  2. プロジェクト名に値「plugin.com.ibm.samples.tomcat」を入力します。プラグイン名も同じ名前にし、「Next (次へ)」をクリックします。
  3. 「Select the pattern type in workspace (ワークスペース内のパターン・タイプを選択)」オプションをクリックします。現在のワークスペースに存在するパターン・タイプがすべてリストアップされるので、そこから「patterntype.samples.apache」を選択します (図 4 を参照)。
    図 4. パターン・タイプを選択する
    パターン・タイプを選択する
  4. 「Finish (完了)」をクリックします。これで、プラグイン・プロジェクトのスケルトンが生成されます。

    以下に、生成されたプロジェクトのスケルトンの構造を記載します。次の 3 つのフォルダーは更新することが可能であり、エクスポートされる .tgz ファイルにパッケージ化されます。

    • src: Java コードを格納するためのフォルダーです。
    • META-INF、OSGI-INF: OSGI コンポーネントの定義が格納されるフォルダーです。
    • plugin: プラグイン構成ファイル、ロケール・メッセージ・ファイル、画像、スクリプトなどが格納されるフォルダーです。

    以下のフォルダーは、ビルド、バリデーション、クラス・パス・ライブラリーに使用されます。

    • build: スクリプトおよび関連ライブラリーがビルドされるフォルダーです。
    • lib: Java ライブラリーが格納されるフォルダーです。
    • build.xml: パッケージ・タスクを提供します。

: 現在のワークスペースに、lib フォルダーと build フォルダーを参照先として提供する plugin.depends プロジェクトが含まれている場合、新しく作成されるパターン・プラグイン・プロジェクトのスケルトンには、これらのフォルダーは含まれません。その場合、build.patterntype.xml によって、plugin.depends プロジェクト内の関連するタスク定義ファイルがインポートされるはずです。

ステップ 2: プラグイン・プロジェクトを構成する

このステップでは、属性を構成して、スクリプトを仮想アプリケーション・パターン・フレームワークに取り込むためのコード・スケルトンを設定します。パターン・プラグイン・プロジェクトは、さまざまな機能を定義するために多数の構成ファイルを提供します。例えば、config.json、config_meta.json、metadata.json、operation.json、tweak.json、monitoring_ui.json、OSGI 定義ファイル、VM テンプレートなどのファイルがあります。このうち、最も一般的に使用されるファイルは config.json、metadata.json、OSGI 定義ファイル、および VM テンプレートです。このプロジェクトの場合、管理操作を定義する operation.json も必要になります。

metadata.json でコンポーネントと属性を定義する

metadata.json ファイルでは、PureApplication System コンソール内の仮想アプリケーション・ビルダーでパターンを作成するために使用される、コンポーネント、ポリシー、リンクといった可視要素を定義します。開発者はまた、仮想アプリケーション・ビルダーでパターンを作成する際にユーザーが設定できるように公開される属性も定義します。

このプロジェクトでは、コンポーネントを 1 つ定義します。そのコンポーネントは、Tomcat サーバーのインストールを実行するコンポーネントです。

  1. plugin/appmodel/metadata.json ファイルをダブルクリックします。すると、エディターが起動します。この複合エディターでは、複数の一般的な構成ファイルがそれぞれ別々のタブに表示されます。
  2. 「Metadata (メタデータ)」セクションで「+」をクリックします。すると、自動的に「Application Model (アプリケーション・モデル)」タブに切り替わります。ポップアップ・ダイアログが表示されたら、コンポーネント・タイプを選択して「OK」をクリックします。
  3. ID、ラベル、説明の各属性を入力します。「Category (カテゴリー)」には、上記のパターン・タイプ・プロジェクトで定義したカテゴリーを選択します。「Image (画像)」と「Thumbnail (サムネイル)」は、仮想アプリケーション・ビルダー内で Tomcat サーバーを表すために使用されるアイコン画像です。画像を参照して選択するか、デフォルトの画像をアイコンに使用することができます。
  4. Tomcat サーバーでは、ユーザーが設定できるように、ポート、管理者パスワード、アプリケーション・パッケージの各属性が公開されます。「Attributes (属性)」セクションで「Add... (追加…)」をクリックしてタイプを選択し、すべての属性を入力します (図 5 を参照)。リスト 4 に、属性定義の詳細を記載します。
    図 5. Tomcat サーバーの「Application Model (アプリケーション・モデル)」タブ
    Tomcat サーバーの「Application Model (アプリケーション・モデル)」タブ
    リスト 4. metadata.json ソースの属性部分
          "attributes": [
             {
                "id": "tomcat.port",
                "type": "string",
                "required": true,
                "label": "TOMCAT_PORT_LABEL",
                "description": "TOMCAT_PORT_DESC",
                "regExp": "[0-9]+",
                "sampleValue": "8080"
             },
             {
                "id": "tomcat.admin.password",
                "type": "string",
                "required": true,
                "displayType": "password",
                "label": "TOMCAT_PASSWORD_LABEL",
                "description": "TOMCAT_PASSWORD_DESC"
             },
             {
                "id": "web_apps",
                "type": "file",
                "required": false,
                "label": "Web Application File (.war or .zip)",
                "description": "For a single application, a .war file is required;
                 For several applications, a .zip file with all .war files is required.",
                "extensions": [
                   "war",
                   " zip"
                ]
             }
          ],

パート、ロール、パッケージ、および config.json を定義する

パッケージ、パート、およびロールの構造は、仮想アプリケーション・パターン・フレームワークによって定義されます。デプロイメントで使用される単位はパッケージです。1 つのパッケージには多数のパートを含めることができ、1 つのパートには複数のロールを含めることができます。通常、デプロイメントと構成を実装するには、ロール内でライフサイクル・スクリプトが使用されます。このプロジェクトの場合、PKG_TOMCAT_INSTALL パッケージに tomcat.install パートが含まれており、このパートに TOMCAT_INSTALL が含まれています。

  1. parts フォルダー内の tomcat.scripts を tomcat.install という名前に変更します。次に、アンインストール操作は不要なので、tomcat.install から uninstall.py を削除します。
  2. tomcat.install/scripts フォルダー内の TOMCAT を TOMCAT_INSTALL という名前に変更します。新規パートまたは新規ロールを追加するために、metadata.json のエディターで「Overview (概要)」タブに切り替えます。「Package (パッケージ)」セクションで、パートを追加するために「Parts (パート)」ノードを選択するか、ロールを追加するために特定のパートを選択してから、「Add (追加)」をクリックします。あるいは、「File (ファイル)」メニューから、「New (新規)」 > 「Others… (その他…)」 > 「IBM Workload Plug-in Development」 > 「Plug-in Part (プラグイン・パート)」または「Plug-in Role (プラグイン・ロール)」の順に選択するという方法もあります。
  3. config.json でパッケージ定義を更新し、part 属性が parts/[パート・フォルダー名].tgz というパターンと一致するようにします。
  4. config.json で、必須の OS およびインストール・ファイルを設定します (リスト 5 を参照)。
    リスト 5. config.json ファイルのソース部分
       "packages": {
          "PKG_TOMCAT_INSTALL": [
             {
                "requires": {
                   "arch": "x86_64"
                },
                "parts": [
                   {
                      "part": "parts\/tomcat.install.tgz",
                      "parms": {
                         "installDir": "$INSTALL_DIR"
                      }
                   }
                ]
             }
          ]
       },
       "parms": {
          "INSTALL_DIR": "\/opt\/apache"
       },
       "files": [
          "\/apache\/apache-tomcat-7.0.40.tar.gz"
       ]

仮想マシン (VM) テンプレートを定義する

VM トポロジーを定義するとともに各 VM 上で実行されるスクリプトも定義するためのパッケージおよびロールをユーザー入力と結合する JSON フラグメントが VM テンプレートです。VM テンプレートを作成する方法としては、2 つの方法が仮想アプリケーション・パターンには用意されています。それは、Java ベースの方法とテンプレート・ベースの方法です。このプロジェクトで VM テンプレートを生成する方法として選択するのは、複雑なロジックでも処理可能な Java ベースのトランスフォーマーです。

  1. 「File (ファイル)」メニューから、「New (新規)」 > 「Other… (その他…)」 > 「IBM Workload Plug-in Development」 > 「OSGI Service Component (OSGI サービス・コンポーネント)」の順に選択します。
  2. 「Service type (サービス・タイプ)」「Topology Provider (java based) (トポロジー・プロバイダー (Java ベース)」を選択して、属性を入力します。名前の値は、ターゲット・コンポーネントの ID と同じでなければなりません。
  3. 「OK」をクリックします。すると、OSGI フォルダー内の OSGI 定義ファイルと、TopologyProvider を継承する TomcatTransformer クラスが生成されます (リスト 6 および 7 を参照)。
    リスト 6. samplestomcat.xml の OSGI 定義ファイル
    <?xml version="1.0" encoding="UTF-8"?>
    <scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" name="samplesTomcat">;
    	<implementation class="com.ibm.vap.samples.tomcat.TomcatTransformer" />;
    	<service>
    		<provide interface="com.ibm.maestro.model.transform.TopologyProvider" />
    	</service>
    </scr:component>
  4. transformComponent メソッド内に、ターゲット JSON フラグメントを戻り値として作成します (リスト 7 を参照)。
    リスト 7. transformComponent メソッドからの抜粋
    JSONObject templates = new JSONObject();
    …
    roleTomcat.put(TplSysKeys.PLUGIN, getPluginScope());
    …
    #get attributes defined by users
    JSONObject attributes = (JSONObject) component.get(TplSysKeys.ATTRIBUTES);
    …
    //add storage template
    addStorageTpl(templates);
    addStorageToVM(vm);
    …
    return templates;

    TomcatTransformer メソッドは、プラグイン構成とユーザー設定を結合して、VM で使用される VM テンプレートとストレージ・テンプレートを表す JSON フラグメントを作成します (リスト 8 を参照)。

    リスト 8. TomcatTransformer メソッドから返される JSON フラグメント
    {
        "vm-templates": [
            {
                "packages": [
                    "PKG_TOMCAT_INSTALL"
                ],
                "roles": [
                    {
                        "plugin": "plugin.com.ibm.samples.tomcat/1.0.0.0",
                        "parms": {
                            "tomcat.admin.password": "<xor>PjsyNjE=",
                            "tomcat.port": "8080"
                        },
                        "type": "TOMCAT_INSTALL",
                        "external-uri": [
                            {
                                "Tomcat Console": "http://{SERVER}:8080"
                            }
                        ],
                        "name": "TOMCAT_INSTALL"
                    }
                ],
                "name": "Tomcat_Server-tomcat",
                "storage": [
                    {
                        "storage-ref": "TomcatStorage",
                        "device": "/dev/sdb",
                        "mount-point": "/opt/apache"
                    }
                ]
            }
    ],
        "storage-templates": [
            {
                "parms": {
                    "size": 10,
                    "format": "ext3",
                    "type": "auto"
                },
                "name": "TomcatStorage"
            }
        ]
    }

operation.json で操作を定義する

操作とは、インスタンスがデプロイされた後に実行できる管理機能です。このプロジェクトでは、「再起動」操作と「新規アプリケーションのデプロイ」操作を提供します。操作の定義は、特定のロールと、そのロールのフォルダー内にある実装スクリプト・ファイルに従います。

  1. metadata.json のエディターで「Operation (操作)」タブに切り替えます。
  2. 再起動操作を定義するために、「Add (追加)」ボタンをクリックして、ロール、ID、カテゴリー、スクリプトの各属性を入力します。ロール属性の値として入力するのは、既存のロール名である TOMCAT_INSTALL です。スクリプト属性の値には、スペースで連結した実装ファイル名とメソッド名を入力します。入力し終わったら「OK」をクリックします。
  3. 「新規アプリケーションのデプロイ」操作を定義するために、「Add (追加)」ボタンをクリックします。この操作を定義するには、同じくロール、ID、カテゴリー、スクリプトの各属性が必要です。ただし、これらの属性に加え、新規アプリケーション・パッケージをアップロードするためのファイル属性も必要になります。入力し終わったら「OK」をクリックします。
  4. TOMCAT_INSTALL ロール・フォルダー内に operation.py スクリプト・ファイルを作成します。リスト 9 に、操作定義の詳細を記載します。
    リスト 9. Tomcat プラグインの operation.json ファイル
    {
       "TOMCAT_INSTALL": [
          {
             "id": "tomcat_restart",
             "label": "Restart Tomcat Server",
             "description": "Restart Tomcat Server",
             "category": "Tomcat Operations",
             "script": "operations.py restart"
          },
          {
             "id": "deploy_apps",
             "label": "Deploy New Application",
             "description": "Deploy New Application",
             "category": "Tomcat Operations",
             "script": "operations.py deploy_apps",
             "attributes": [
                {
                   "id": "new_apps_pkg",
                   "type": "file",
                   "required": true,
                   "label": "New application",
                   "description": "New application",
                   "extensions": [
                      "war",
                      "zip"
                   ]
                }
             ]
          }
       ]
    }

ステップ 3: Tomcat のインストールおよび操作スクリプトを作成する

インストール・スクリプトや構成スクリプトには、パート・ライフサイクル・スクリプトとロール・ライフサイクル・スクリプトが組み込まれます。これらのスクリプトの実行コンテキストは、パートとロールで異なります。パート・ライフサイクル・スクリプトの属性パラメーターは config.json で定義されますが、ロール・ライフサイクル・スクリプトの属性パラメーターは、VM テンプレート内のロール定義から提供されます。パート・ライフサイクル・スクリプトが実行されてから、すべてのロール・ライフサイクル・スクリプトが実行されることに注意してください (図 6 を参照)。

図 6. TOMCAT_INSTALL ライフサイクル・スクリプト
TOMCAT_INSTALL ライフサイクル・スクリプト

仮想アプリケーション・パターンが提供する Python パッケージ maestro は、ライフサイクル・スクリプト内で仮想アプリケーション・パターン・フレームワークとやりとりするために使用されます。maestro パッケージには、ファイアウォール内のポート開閉といった機能を実行するユーティリティー・モジュールも用意されています。maestro パッケージの API ドキュメントは、PDK パッケージに含まれています。生成されるライフサイクル・スクリプトには、いずれも先頭に追加ドキュメントがあり、ここに、最もよく使われる maestro パッケージのメソッドを詳しく説明するためのコメントから成る大きなパラグラフが組み込まれます。

パート・ライフサイクル・スクリプト

同じ VM を構成するさまざまなパートは、トポロジー構成で定義された順に実行されます。あるパートが別のパートを待機するようにパート間の依存関係を設定することもできますが、この例で定義されているパートは 1 つしかありません。このプロジェクトでは、tomcat.install パート・フォルダー内に install.py スクリプトを用意します。アンインストール操作は必要でないため、uninstall.py ファイルは削除されています。install.py スクリプト (リスト 10 を参照) は、以下の機能を実行します。

  • パート・スコープからロール・スコープにパラメーターを渡します。
  • Tomcat インストール・ファイルをダウンロードします。
  • ロール・スクリプトをインストールします。これは、パートに、ライフサイクル・スクリプトが設定されたロールが含まれる場合に必要です。
リスト 10. install.py からの抜粋

リスティングを見るにはここをクリック

リスト 10. install.py からの抜粋

…
import maestro

…
download_dir = maestro.parms['installDir'] + '/download'
part_name = 'tomcat.install'
if not part_name in maestro.node['parts']:
    maestro.node['parts'][part_name] = {}
maestro.node['parts'][part_name]['installDir'] = maestro.parms['installDir']

#download tomcat binary
installer_url = urlparse.urljoin(maestro.filesurl, '/storehouse/admin/files/apache/apache-tomcat-7.0.40.tar.gz')
logger.debug('Download apache-tomcat-7.0.40.tar.gz...')
maestro.download(installer_url, download_dir + '/apache-tomcat-7.0.40.tar.gz')

#install scripts
maestro.install_scripts('scripts')

ロール・ライフサイクル・スクリプト

ロール・スクリプトは、install.py > configure.py > start.py の順に実行されます。異なるロールのライフサイクル・スクリプトは並行して実行されます。この例の場合、configure.py スクリプトは不要です。

  • install.py の内容は、Tomcat インストール、ポート構成、管理者パスワード、環境変数宣言、Web アプリケーションのインストールです。install.py スクリプトおよび configure.py スクリプトは、デプロイメント時にのみ実行されます。
  • start.py には、ロールのステータスを RUNNING に変更する機能、ポートを開く機能、および VM の起動時に必要なパラメーターを公開する機能が含まれます。
  • stop.py は、Tomcat サーバーのシャットダウンを処理します。

Python オブジェクトである maestro.role は、同じロールを持つ異なるライフサイクル・スクリプトのデータを保管したり、これらのスクリプト間でデータを送信したりすることができます。また、このロールの操作実装ファイルが maestro.role のデータにアクセスすることもできます。詳細については、この記事に付属のダウンロード可能なサンプル・コードに記載されています。

操作実装スクリプト

操作実装ファイルには、restart メソッドと deploy_apps メソッドの 2 つを組み込む必要があります。これらのメソッドは以下の機能を提供します。

  • restart: Tomcat ホームにアクセスして、Tomcat を再起動します。
  • deploy_apps: Tomcat ホームにアクセスして、新規アプリケーションのインストール・ファイルをダウンロードし、そのアプリケーションを Tomcat webapps に移動してから Tomcat を再起動します。

HTTPD プラグイン・プロジェクトの作成

今度は、HTTPD プラグイン構造の作成と構成を行います。HTTPD のインストールには、httpd-2.4.4 ソース・コードが使用されます。インストール・スクリプトは、このソース・コードから HTTPD をビルドしてインストールします。このプロジェクトでは、VM テンプレート定義としてテンプレート・ベースのトポロジー・プロバイダーを選択します (図 7 を参照)。

図 7. HTTPD プラグイン・プロジェクトの新規 OSGI コンポーネント
HTTPD プラグイン・プロジェクトの新規 OSGI コンポーネント

「Finish (完了)」をクリックします。OSGI コンポーネント定義の他、PDK は templates/sampleshttpd.vm に VM Velocity テンプレートの基本 JSON フラグメントを生成します (リスト 11 を参照)。JSON 構造は簡潔なので、maestro で指定された定義済みオブジェクトを使用して、このテンプレートを作成することができます。これは、Java ベースのテンプレートより単純でわかりやすいテンプレートですが、1 つの制約として、複雑なロジックに関しては、Java トラスフォーマー・コードほど簡単に処理することができません。

リスト 11. HTTPD プラグインの sampleshttpd.vm
{
    "vm-templates": [
        {
            "persistent":false,                 
            "name": "${prefix}-httpd",
            "roles": [
                {
                	"plugin" : "$provider.PluginScope",
                    "parms": {
                    },
                    "type": "HTTPD_INSTALL",
                    "name": "HTTPD_INSTALL",
                    "external-uri": [{"ENDPOINT":"http://{SERVER}"}]
                }
            ],
            "packages": [
                "PKG_HTTPD_INSTALL"
            ]
        }
    ]
}

パターン・タイプおよびプラグインのビルドとインストール

PDK は、パターン・タイプ・プロジェクトをビルドして直接 PureApplication System にインストールするためのメニューを提供します。最初のインストールでは、Tomcat および HTTPD のインストール・ファイルは PureApplication System の Storehouse にアップロードされていません。これらのインストール・ファイルは、パターン・タイプ・プロジェクトと一緒にパッケージ化できるので、一度アップロードするだけで済みます。

  1. パターン・タイプ・プロジェクト内で build.patterntype.xml ファイルを見つけます。このファイルを右クリックして、メニューを「Run As (実行)」 > 「Ant Build (Ant ビルド)」の順に選択します。「Main (メイン)」タブに切り替えて、Ant ビルドの storage.dir 引数 (ローカルの場合) または storage.url 引数 (リモートの場合) として、このパターン・タイプのすべてのプラグイン・プロジェクトに対して config.json で定義されたファイルが含まれるフォルダーまたは URL の値を設定します (例えば、Dstorage.dir=d:/files)。「OK」をクリックしてビルドします。パターン・タイプをビルドすると、パターン・タイプに含まれるプラグイン・プロジェクトも一緒にパッケージ化されます。

    : インストール・ファイルは、パターン・タイプの最初のビルド時にのみパッケージ化されます。

  2. パターン・タイプ・プロジェクトを右クリックして、「IBM Pattern Toolkit」 > 「Install/Update to Deployer (デプロイヤーへのインストール/更新)」メニューを選択します。
  3. このメニューを選択するのが初めての場合、デプロイヤーの接続プロパティーを設定するためのツールキット設定ページがポップアップ表示されます。PureApplication System 属性を設定し、「Deploy debugging plug-ins before deployment (デプロイメントの前にデバッグ・プラグインをデプロイする)」チェック・ボックスを選択します。こうすることで、後でデバッグに使用するデバッグ・プラグインとアンロック・プラグインがインストールされることになります。
  4. パターン・タイプ・プロジェクトと、Tomcat および HTTPD のプラグイン・プロジェクトとファイルが PureApplication System にインストールされます。
  5. 「Project Explorer (プロジェクト・エクスプローラー)」ビューのツールバーで、「Navigator to Deployer (デプロイヤーへのナビゲーター)」ボタンをクリックして外部ブラウザーを起動し、PureApplication System にログインします。

コンソールでパターン・タイプが使用可能になった後、パターン・タイプを使用してインスタンスをクラウドにデプロイします。


PDK を使用したデバッグ

PDK には、仮想アプリケーション・パターン開発にデバッグ機能を提供するデバッグ・プラグインが組み込まれています。このデバッグ・プラグインを使用して Tomcat プラグイン・プロジェクトをデバッグする手順は以下のとおりです。

  1. PureApplication System コンソールにログインして、「Patterns (パターン)」 > 「Virtual Applications (仮想アプリケーション)」の順にメニューを選択します。次に、「+」をクリックします。
  2. ポップアップ・ダイアログで、「patterntype.samples.apache」パターン・タイプを選択し、「Start building (ビルドの開始)」ボタンをクリックして仮想アプリケーション・ビルダーを開きます。
  3. コンポーネント・パレットから、Tomcat サーバー・コンポーネントとデバッグ・コンポーネントをキャンバスまでドラッグし (図 8 を参照)、Tomcat サーバー・コンポーネントの必須属性を設定します。
    図 8. 仮想アプリケーション・ビルダーでのパターンの作成
    仮想アプリケーション・ビルダーでのパターンの作成

    デバッグ・プラグインには、次の 2 つのデバッグ・モードがあります。

    • モック・デプロイメント: デプロイ済みインスタンスは、トランスフォーマー/プロバイダーを実行して topology.json を生成しますが、VM をデプロイすることはしません。
    • 手動デバッグ用デプロイメント: 「Resumable on script error (スクリプト・エラー発生時に再開可能にする)」チェック・ボックスを選択すると、スクリプトの実行中にエラーが発生した際に、インスタンスの一時停止が可能になります。この場合、スクリプトを更新してから、一時停止されたインスタンスの実行を再開することができます。デバッグ・プラグインを使用しない場合は、インスタンスを再デプロイしてからでないと、更新したスクリプトをテストすることはできません。
  4. 「Virtual Applications (仮想アプリケーション)」ページに戻ります。新しく作成したパターンを選択してから、「Deploy (デプロイ)」ボタンをクリックします。ポップアップ・ダイアログで、「Advanced (拡張)」セクションを展開して SSH 鍵を設定します。この鍵は、必ず秘密鍵として保持します。最後に、「OK」をクリックして、このパターンをデプロイします。

これで、Tomcat サーバー・プラグインを使用した 1 つのインスタンスが実行中の状態になります。PDK で「Workload Plug-in Runtime (ワークロード・プラグイン・ランタイム)」パースペクティブに切り替えて、以下の手順に従ってこのインスタンスの実行を追跡し、デバッグします。

  1. 「Deployment Runtime Explorer (デプロイメント・ランタイム・エクスプローラー)」で「+」をクリックします。
  2. ポップアップ・ダイアログで、「Add VM(s) from deployed instance (デプロイ済みインスタンスから VM を追加する)」ラジオ・ボタンを選択します。これは、インスタンス全体を追跡するためです。「Next (次へ)」をクリックします。
  3. すべての仮想アプリケーション・パターン・インスタンスがここにリストアップされるので、このリストから新しくデプロイしたインスタンスを選択します。次に、「SSH Configuration (SSH 構成)」ボタンをクリックし、SSH 属性を設定します。図 9 に示すように、「Key Mode (鍵モード)」を選択して SSH 鍵ファイルの場所を設定してから、「OK」をクリックします。
    図 9. 自動モニターが有効にされた SSH 構成
    自動モニターが有効にされた SSH 構成
  4. 「Finish (完了)」をクリックしてインスタンスを追加します。これで、インスタンスのモニターが開始されて、ログが自動的に収集されます。ログの収集は、デプロイメントが完了するまで、あるいはエラーが発生しない限り、続けられます。この例では、install.py ロール・スクリプトに 1 つのエラーが含まれているため、このエラーによって、インスタンスの実行は一時停止されます (図 10 を参照)。
    図 10. install.py の実行エラー
    install.py の実行エラー
  5. インスタンスの実行を続けるには、install.py のエラーを修正する必要があります。修正した後、「Deployment Runtime Explorer (デプロイメント・ランタイム・エクスプローラー)」のログ・ツリー・ビューでエラー・ノードを右クリックします。「Upload And Resume (アップロードおよび再開)」メニューを選択すると、VM 上の install.py が更新されて、インスタンスの実行が再開されます。このプロセスは、すべてのエラーが修正されてインスタンスの実行が完了するまで、何度でも繰り返すことができます。エラーのなかには、回復不可能なものもあります。これはつまり、プラグインを更新し、インスタンスを再デプロイしてデバッグしなければならないことを意味します。
  6. 仮想アプリケーション・インスタンスのコンソールで、TOMCAT_INSTALL エンドポイントをクリックします。すると、Tomcat サーバー管理コンソールが開くので、そこでインストールを検証することができます。

上記の手順に従って、今度は HTTPD サーバー・プラグインをテストして、HTTPD プラグインが正常にHTTPD サーバーをインストールできることを確認してください。

ダウンロード・ファイル

この記事に付属の samples.apache のサンプル・コードを参照してください。このパッケージをダウンロードして、「File (ファイル)」メニューから「Import… (インポート…)」 > 「IBM Workload Plug-in Development」 > 「IBM Workload Pattern Type Package」を順に選択することで、プロジェクトをインポートすることができます。


まとめ

この連載の第 1 回では、Apache Tomcat と Apache HTTPD サーバー用のプラグイン・コンポーネントを組み込んだ仮想アプリケーション・パターンを開発する方法を紹介しました。また、パターンをビルド、デプロイ、デバッグする方法も説明しました。

第 2 回では、コンポーネントのデプロイメントに適用されるリンクとポリシーを作成します。さらに第 3 回では、複数のTomcat サーバー・インスタンスで共有するシングルトン memcached サーバー・プールを提供するために、共有サービスを作成します。


ダウンロード

内容ファイル名サイズ
Code samplepatterntype.samples.apache-1.0.0.0.zip209KB

参考文献

コメント

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
ArticleID=962501
ArticleTitle=IBM Pattern Development Kit を使用して仮想アプリケーション・パターンを作成する: 第 1 回 Tomcat と HTTP Server をインストールするための仮想アプリケーション・パターン・プラグイン・プロジェクトを作成する
publish-date=02202014