目次


PureApplication System の共有サービス・ワークロードをナビゲートする

他のワークロードに共通の機能を提供するワークロードとしての共有サービスを作成する方法を学ぶ

Comments

「共有サービス」とは、クラウド内にデプロイされた複数のクライアント・アプリケーション (仮想アプリケーション、仮想システム、仮想アプライアンスなど) によってデプロイされて共有される、事前に定義されたパターンです。共有サービスはエンド・ユーザーに対し、複数のアプリケーションを提供する代わりに、複数のアプリケーションやサービスに対する特定のランタイム・サービスを提供します。一般に、共有サービスへの参照は、クラウド・グループ (クラウドを定義するハードウェアの物理グループ) ごとに 1 つしか見当たりません。その共有サービスは、クラウド・グループ内のあらゆるデプロイ済みアプリケーションによって使用することができます。これはつまり、共有サービスは、マルチテナント・アクセスを提供しなければならないことを意味します。

図 1. 共有サービスは、複数のデプロイ済みアプリケーションによってデプロイされて共有される、事前定義されたパターンです
共有サービスは、複数のデプロイ済みアプリケーションによってデプロイされて共有される、事前定義されたパターンです
共有サービスは、複数のデプロイ済みアプリケーションによってデプロイされて共有される、事前定義されたパターンです

この記事では、共有サービスを、他のデプロイ済み仮想アプリケーション (デプロイ済みクライアント) が利用できる単一のデプロイ済みパターンとして定義します。1 つ以上のデプロイ済みクライアントが単一のデプロイ済み共有サービスに接続して、共通データ・リポジトリーにアクセスできるという前提です。

この記事では、PDK (Plug-in Development Kit) からサンプル共有サービスをインポートしてカスタマイズする手順を説明します。サンプル共有サービスのことは、メディア・サービスと呼ぶこともあります。

この記事を補完する優れた学習リソースについては (このトピックに関する経験のレベルによっては、記事を読むにあたっての前提条件となる場合もあります)、囲み記事を参照してください。

メディア共有サービスの概念

多くの場合、仮想アプリケーションをデプロイするには、あらかじめ何らかの形のバイナリー・メディア (例えば、ビルド・サーバーのバイナリーや ISO DVD イメージ) をインストールしなければなりません。前提条件となるバイナリーがアプリケーション・パターンやコンポーネント・プラグインにパッケージ化されていない理由には、ライセンスの問題やコード配布の問題、あるいはバイナリーをアプリケーション・パターンとは別に更新しなければならないことなどが考えられます。

クラウド環境では、複数のデプロイ済みアプリケーションが同じメディア・ファイルを参照しなければならないことがあります。しかし、必要なファイルがクラウド外部の速度の遅い (おそらくリモートの) ネットワークに置かれているとしたら、デプロイ済みの各仮想アプリケーションにファイルをダウンロードするのに、相当な時間がかかる可能性があります。

これらの問題を解決するために私たちが提案する方法は、新しいメディア共有サービスを作成して、このサービスでクラウド・グループに属するすべての仮想アプリケーションが使用するバイナリー・ファイル・リポジトリーをホストすることです。このようなメディア・サービスをデプロイすることで、仮想アプリケーションやプラグインとは別に、前提条件となるファイルをロードできるようになります。

新しいアプリケーションのデプロイを開始するたびにクラウドの外部からファイルをコピーする代わりに、メディア・サービス仮想マシン (VM) にファイルを一度コピーすれば、これらのファイルをクラウド内でローカルに使用することができます。こうすることで管理者は、共通のフレームワークを持たない個々の独立した VM に対し、サービスをより一元化された様式で管理することができます。

ファイルのコピーはラック (つまり、PureApplication System) とクラウド・グループの内部で行われるため、メディア・サービスから仮想アプリケーションにファイルをコピーする時間は遥かに短縮され、デプロイ済みアプリケーションからデータへのアクセスが迅速に行われるようになります。

メディア・サービスの典型的なフローは、例えば以下のようになります。

  1. 共有サービス/メディア・サービスをデプロイします。

  2. メディア・サービス VM が起動されると、クラウド・グループで NFS を介して共有するバイナリー・ファイルがロードされます。

  3. メディア・サービスを使用する仮想アプリケーション (パターンに含まれるコンポーネント・フラグまたはポリシー) をデプロイします。

  4. デプロイされたアプリケーションが、メディア・サービスにバイナリー・ファイルの場所や接続情報を問い合わせます。

  5. この情報により、仮想アプリケーションはメディア・サービス VM のファイル・リポジトリーを NFS にマウントできるようになります。

  6. デプロイする複数の仮想アプリケーションに対して、上記のステップを繰り返します。デプロイされたそれぞれの仮想アプリケーションには、メディア・サービスを介して共有ファイルへアクセスできる権限が付与されます。

この記事ではまず、Plug-in Development Kit に付属のサンプル共有サービスを取り上げ、このサービスに用意されている要素を詳しく調べてから、サンプル共有サービスを IBM PureApplication System または IBM Workload Deployer 製品にインポートしてクラウドにデプロイします。これより、汎用共有サービスを追加する方法を大まかに理解できるはずです。

次に、サンプル共有サービス・プラグインに変更を加えてメディア共有サービスにする方法を説明し、新しい共有サービスをいかに簡単に追加できるかを明らかにします。このセクションに続いて、その手順とコード・スニペットを記載するので、提供されている共有サービスを基に、独自のメディア共有サービスや将来のカスタム共有サービスを簡単に作成できるようになるはずです。

PDK、サービス、クライアント仮想アプリケーションを作成およびインストールする

PDK v1.0.0.4 に用意されているサンプル共有サービスは、カスタマイズした共有サービスを作成する際に絶好のスケルトンとなります。このサンプル共有サービスは、必要なファイル構造と、以下を定義するコア・スクリプトをセットアップします。

  • REST API 管理インターフェースを備えたサンプル共有サービス。

  • サンプル共有サービスを使用して REST API 管理インターフェースを呼び出すクライアント仮想アプリケーション・コンポーネント。

まずはサンプル・コードをインポートするところから始めます。その後、カスタム機能を追加していきます。

PDK v1.0.0.4 をダウンロードしてください。プラグインをデプロイするための最小要件は、IBM Workload Deployer 3.1.0.2 または IBM PureApplication System v1.0 です。PDK の使用方法については、囲み記事で紹介している参考文献を参照してください。

以下の点に注意してください。

  1. 必ず、共有サービスと共有サービス・クライアントを含むすべてのプロジェクトをインポートしてください。

  2. plug-in.depends プロジェクトに進み、ANT を使用して build.xml を実行します。ターゲットのクリーンアップ、ターゲットのパブリッシュの順に実行してください。これにより、共有サービスと共有サービス・クライアントを含むすべてのプラグイン・プロジェクトがビルドされます。

  3. patterntype.hello に進み、ANT を使用して build.patterntype.xml を実行します。ターゲットのクリーンアップ、ターゲットのパブリッシュの順に実行してください。これにより、plug-in.depends の出力がインポート対象の 1 つのパターンにパッケージ化されます。

次は、Workload Deployer または PureApplication System にパターン・タイプをインストールします。

IWD または IBM PureApplication System にパターン・タイプをインストールする

以下の手順に従って、サンプル共有サービス・プラグインが収容されたパターン・タイプをインストールします。

  1. IBM Workload Deployer コンソールまたは PureApplication System の「Workload Console (ワークロード・コンソール)」で、「Cloud (クラウド)」 > 「Pattern types (パターン・タイプ)」の順に選択します。

  2. 既存の pattnertype.hello パターン・タイプがある場合は、それを選択して「Delete (削除)」をクリックします。

  3. 注: このパターン・タイプのプラグインを使用して実行中のデプロイ済みアプリケーションがないことを確認してください。そのようなアプリケーションが 1 つでもあると、パターン・タイプを削除することができません。また、プロセスが完了してページが最新の表示になるまで待ってください。

  4. 新しいパターン・タイプをインポートするために、緑色の「+」記号をクリックします。

  5. Eclipse ワークスペースから、patterntype.hello/export/ptype.hello-2.0.0.2.tgz ファイルをインポートします。

  6. インポートが完了したら、patterntype.hello パターンを選択し、ライセンスを受け入れてパターンを使用可能にします。

注: 共有サービスを再デプロイすることなく、クライアントに変更を加えて再デプロイできるようにしたい場合は、クライアントを別個にパッケージ化してバージョン番号を変更し (一意のバージョンのみがインポート可能です)、「Cloud (クラウド)」 > 「System Plug-ins (システム・プラグイン)」の順に選択して表示されるページからこのパッケージをアップロードします。

次は、サンプル共有サービスをデプロイします。

サンプル共有サービスをデプロイする

サンプル共有サービスをクラウド・グループにデプロイして、サンプル共有サービスを使用可能な状態にします。

  1. Workload Deployer コンソールまたは PureApplication System の「Workload Console (ワークロード・コンソール)」で、「Cloud (クラウド)」 > 「Shared Services (共有サービス)」の順に選択します。

  2. Sample Shared Service (サンプル共有サービス)」という見出しの下にある「Sample Shared Service (サンプル共有サービス)」を選択します。

  3. Deploy (デプロイ)」をクリックします。

  4. デプロイメントに必須の以下のパラメーターを入力します。

    1. Enable REST API on All VMs (すべての VM で REST API を使用可能にする): チェック・マークを付けます。

    2. Management VM Number (管理 VM 数): 1

    3. Service VM Number (サービス VM 数): 0

    図 2. サンプル共有サービスのデプロイメント・パラメーター
    サンプル共有サービスのデプロイメント・パラメーター
    サンプル共有サービスのデプロイメント・パラメーター
  5. OK」をクリックします。

  6. 次の画面では、環境に応じた適切なデプロイメント・パラメーターを指定して、「OK」をクリックします。

  7. 「Instances (インスタンス)」 > 「Shared Services (共有サービス)」の順に選択して、デプロイ済みアプリケーションを確認します。

デプロイ済みのサンプル共有サービスが緑色になって、使用できる状態になるまで待ってから、次のステップに進みます。次のステップでは、共有サービス・クライアントをデプロイします。

共有サービス・クライアントをデプロイする

これから、サンプル共有サービスを使用する共有サービス・クライアントのパターンを作成します。共有サービス・クライアントを正常にデプロイするためには、サンプル共有サービスが実行中になっていなければならないことに注意してください。

  1. Workload Deployer コンソールまたは PureApplication System の「Workload Console (ワークロード・コンソール)」で、「Patterns (パターン)」 > 「Virtual Applications (仮想アプリケーション)」の順に選択します。

  2. ドロップダウン・リストから「patterntype.hello」を選択し、「+」記号を選択して新規パターンの作成に取り掛かります。

  3. 「Pattern Editor (パターン・エディター)」で、左側の枠内から「Shared Service Client Sample (共有サービス・クライアント・サンプル)」を選択し、中央までドラッグします。

    図 3. 共有サービス・クライアントのパターンを作成する
    共有サービス・クライアントのパターンを作成する
    共有サービス・クライアントのパターンを作成する
  4. Save (保存)」をクリックして、新しいアプリケーションの名前を入力します。この例では、「SharedServiceClient」という名前を付けます。

  5. アプリケーション・ビルダーのウィンドウを閉じて、仮想アプリケーション・パターンの画面を最新の表示にします。

  6. 新規に作成したクライアント「SharedServiceClient」を選択します。

  7. Deploy (デプロイ)」をクリックします。

  8. 環境に応じた適切なデプロイメント・パラメーターを指定して、「OK」をクリックします。

  9. 「Instances (インスタンス)」 > 「Shared Services (共有サービス)」の順に選択して、デプロイメントを確認します。

デプロイされたクライアント・パターンが緑色になり、使用できる状態になるまで待ってから、次のステップに進みます。次のステップでは、デプロイされた VM を操作するための管理操作コンソールを表示します。

管理操作コンソール画面を表示する

デプロイされた VM をユーザーが操作するには、管理操作画面を使用します。デプロイ済みのサンプル共有サービスの管理操作画面と、同じくデプロイ済みの共有サービス・クライアント・アプリケーションの管理操作画面があります。

サンプル共有サービスの管理操作画面を表示する方法は以下のとおりです。

  1. 「Instances (インスタンス)」 > 「Shared Services (共有サービス)」 > 「Sample Shared Service (サンプル共有サービス)」の順に選択して、デプロイ済みのサンプル共有サービスを表示します。

  2. 実行中になったら、「Manage (管理)」リンクをクリックします。

  3. Operation (操作)」タブをクリックします。

  4. SharedService-Management.ServiceSample」ロールをクリックします。このリンクは、操作を追加するまでは表示されないことに注意してください。操作の追加は、もう少ししてから行います。

共有サービス・クライアントの管理操作画面を表示する方法は以下のとおりです。

  1. 「Instances (インスタンス)」 > 「Virtual Applications (仮想アプリケーション)」の順に選択して、デプロイ済みの仮想アプリケーションを表示します。

  2. 実行中になったら、「Manage (管理)」リンクをクリックします。

  3. Operation (操作)」タブをクリックします。

  4. SharedService-Client.ServiceClient」ロールをクリックします。

図 4. 共有サービス・クライアントの管理操作ページ
共有サービス・クライアントの管理操作ページ
共有サービス・クライアントの管理操作ページ

サンプル・コードでは、クライアントの管理操作を使用して、サンプル共有サービスの REST API を操作することができます。操作を見るには、「Operation (操作)」画面を使用して、共有サービスの REST 呼び出しを実行します。以下はその一例です。

  1. REST Calls (REST 呼び出し)」セクションを展開します。

  2. 以下の内容を入力します。

    URL:  test
    REST METHOD:  PUT
    JSON:  {}
  3. Submit (送信)」をクリックします。

これにより、共有サービスの REST API が呼び出されますが、現時点ではこの呼び出しによって有用な操作は行われません。

この方法は、デプロイメントの管理者がクライアントに共有サービスを操作させる 1 つの方法です。この方法とは別に、クライアントは、ユーザーからの要求がなくてもライフサイクル・スクリプトによって自動的に共有サービスが呼び出されて、アクションが実行されるようにすることもできます。こうしたことはすべて、クライアントが共有サービスに対してどのような形で操作を行うかに依存します。以降のセクションでは、後者の方法を実装する例を説明します。

それでは、サンプル共有サービスを変更してメディア・サービスにする共有サービスのコードを調べてみましょう。

サンプル・サービスとクライアントのコードの説明

PDK には、共有サービスを作成および管理するためのライフサイクル・スクリプトと事前定義されたパターンを備えた、plug-in.com.ibm.sample.sharedservcie.service という名前のサンプル共有サービス・プラグインが用意されています。このプラグインは 1 つ以上の VM を作成し、クライアントが使用する REST API を実行します。この後、このサンプル共有サービス・プラグインをカスタマイズして、メディア・サービスを作成します。

PDK から取得するプラグイン・パッケージには、以下のファイルも含まれています。

  • src/com.ibm.service.internal/SampleRegistryProvider.java: これは、この共有サービスのレジストリー・レスポンス情報を定義するファイルです。例えば、クライアント・コードが getRegistry を呼び出すと、このメソッドはこの共有サービスの IP を返します。返されるレジストリー・オブジェクトは JSON オブジェクトであるため、ここに IP 以外のデータを含めることもできます。このコードは、システムの管理プロセス (例えば、IBM Workload Deployer アプライアンスや PureApplication System のマネージャー・ノードなどでの管理プロセス) で実行されます。このファイルの名前とパッケージをカスタマイズすることはできますが、その場合、OSGI-INF ファイル (OSGI-INF/serviceRegistryProvider.xml) でも同じようにファイル名を更新する必要があります。

  • OSGI-INF/serviceRegistryProvider.xml: このファイルは、バンドルの OSGI の詳細を格納し、他のバンドルがこのバンドルを呼び出して適切に実行するための参照を作成します。このフィルの名前はカスタマイズ可能です。カスタマイズする場合、プラグインのマニフェスト・ファイル (META-INF/MANIFEST.MF) に、そのカスタム名を指定する必要があります。

  • plug-in/appmodel/metadata.json: このファイルは、ユーザーが共有サービスをデプロイする際のデプロイメント・パラメーターを定義します。したがって、ユーザーはこのファイルを使用して REST API を使用可能または使用不可にしたり、管理 VM とサービス VM として作成する VM の数を設定したりすることができます。このファイルの名前をカスタマイズすることはできません。

    サンプル共有サービスには、複数の VM (1 つの管理 VM と 1 つ以上のサービス VM) をデプロイするための機能があります。これは、フェイルオーバーを可能にしたり、必要に応じて追加のリソースをプロビジョニングしたりするために、サービス VM をスケーリングできるという概念です。

    • 管理 VM は、メインの REST API をホストして、REST API スクリプトを実行します。

    • サービス VM も REST API をホストしますが、これは冗長性を持たせるためです。

    つまりユーザーは、通信するためのインターフェースとデータ冗長性ロジックをサービス VM に実装できると同時に、動的にサービス VM を作成または削除するためのスケールイン、スケールアウトのメトリックを設定できるということです。これらのトピックは高度なものなので、この記事では説明しません。

    この記事では、1 つのサンプル共有サービス VM、つまり管理 VM のみをデプロイすることを前提とします。サービス VM については、混乱を避けるために無視します。

  • plug-in/templates/servicesample.vm: これは、作成する VM を定義する VM テンプレート・ファイルです。このファイルには、以下の 2 つの VM タイプが定義されています。

    • 管理 VM としての SharedService-Management

    • サービス VM としての SharedService-Service

    ファイル内で参照される属性は、ユーザーがデプロイ時に直接 metadata.json にマッピングすることによって指定されます。例えば、servicesample.vm には、metadata.json の "id":"managementNum" に定義された ${attributes.managementNum} が格納されます。

    VM テンプレートは Apache Velocity をベースとしているため、このテンプレートにロジックを追加することで、最終的に生成されるトポロジーを動的に変更することができます。見てのとおり、#if (${attributes.serviceNum} > 0) という #if ロジックは、ユーザーがデプロイ時に 0 より大きい数値を入力した場合にだけ、SharedService-Service VM を定義します。この記事では SharedService-Service VM をデプロイしないので、attributes.serviceNum は 0 となります。

  • plug-in/nodeparts/servicesampleapi/common/install/7_servicesampleapi.py: VM のインストール時には、REST API をセットアップするために、このスクリプトが実行されます。nodeparts の実行時にこのスクリプトが期待される順番で実行されるようにするには、スクリプトの名前が数値で始まっている必要がありますが、アンダーバーの後の名前 (servicesampleapi.py) はカスタマイズすることができます。

  • plug-in/nodeparts/servicesampleapi/servicesampleapi/properties/servicesampleapi.json: この JSON ファイルは、公開する REST API メソッドを定義します。

  • plug-in/parts/servicesample.scripts/scripts/ServiceSample/restapi.py: REST API が呼び出されると、この Python スクリプトが実行されます。それぞれの REST API 呼び出しについて、このスクリプトが servicesampleapi.json 内で参照されます。ファイル名はカスタマイズ可能ですが、servicesampleapi.json が正しくカスタム名を使用するようにしなければなりません。

共有サービス・クライアント・プラグインは、plug-in.com.ibm.sample.sharedservcie.client です。このプラグインをデプロイすると、デプロイ済みクライアントが共有サービスを操作できるようになります。このプラグイン・パッケージには、以下のファイルも含まれています。

  • src/com.ibm.service.internal/SampleServiceProvisioner.java: これは、クライアント・サービス・プロビジョナーです。このファイルは、クライアントのデプロイ時に、クライアント VM が作成される前に実行されます。このファイルを見ると、共有サービスへの参照を取得して共有サービスの REST API を呼び出す方法がわかります。

    プロビジョナーの使用例の 1 つは、共有サービスに、別のクライアントをプロビジョニング中であることを通知することです。例えば REST API の使用により、共有サービスは新しいユーザー名/パスワードを作成し、クライアントがその新しいユーザー名/パスワードを使用して接続できるように、そのデータをクライアントに返すことができます。必須ではありませんが、クライアントのデプロイ時に、そのデプロイメントにとってこの共有サービスが適切でない場合には、グレースフルにデプロイメントを失敗することができます。プロビジョナーの別の使用例として、サービスの要求が適切でない場合には、クライアントのデプロイメントを停止することができます。その場合、ユーザーは共有サービス管理者と協力し、アプリケーションのデプロイメントが失敗した VM 上でリソースが無駄に使用される前に共有サービスを修正する必要があります。

  • plug-in/appmodel/operation.json: この JSON ファイルは、デプロイメントの際に管理操作コンソール画面で使用可能な操作を定義します。これにより、クライアント・デプロイメントの管理者は操作をしやすくなります。このファイルの名前をカスタマイズすることはできません。このファイルは操作の実行時に、"script": "action.py call" で定義された action.py スクリプトを呼び出します。

  • plug-in/parts/clientsample/scripts/ServiceClient/action.py: ユーザーが管理操作コンソールから操作を実行するときには、このスクリプトが実行されます。このスクリプトは、共有サービスに対する REST 呼び出しを生成した後、maestro.pcurl コマンドを使用して HTTP の呼び出しを実行します。

共有サービス・シナリオでのクライアントとサービスの関係を構成するファイルについて十分に理解できたところで、次はサンプル共有サービスをカスタマイズしてメディア・サービスにする方法を見て行きましょう。ここでは、カスタム・メディア・サービスを作成するために必要となる単純な変更内容について説明します。

メディア・サービスの詳細

plug-in.com.ibm.sample.sharedservcie.service プロジェクトに、以下の変更を加えてください。

  1. 共有サービス・レジストリーに、情報を少し追加します。src/com.ibm.service.internal/SampleRegistryProvider.java ファイルを編集し、getRegistry コマンド内でレジストリーが返される直前に以下の行を追加してください。

    registry.put("mountPoint", "/shared_repository");

    上記の追加情報は、作成している NFS マウント・ポイントのファイル・パスです。クライアント・コードはこの値を読み取って、NFS がリポジトリーをマウントする方法を認識する必要があります。

  2. 共有サービスに REST API を追加します。plug-in/nodeparts/servicesampleapi/servicesampleapi/properties/servicesampleapi.json ファイルを変更して、GET セクションに listRepository という新しい関数を追加します。

    { "resource":"listRepository", 
    "clientdeploymentexposure":true, 
    "role":"SharedService-Management.ServiceSample", 
    "script": "restapi.py listRepository", 
    "timeout" : 60000},

    上記のコードが定義する内容は以下のとおりです。

    • listRepository に対する GET 呼び出し。

    • この操作は、(コアとなる IBM Workload Deployer/IPAS コードだけでなく) これ以外のクライアントのデプロイメントでも使用可能であること。

    • この操作を実行する VM ロール・タイプが SharedService-Management.ServiceSample であること。

    • 操作が呼び出されると、restapi.py スクリプトが実行され、パラメーターして listRepository が渡されること。この新しいパラメーターを使用するように restapi.py スクリプトを更新する作業は、この後すぐに行います。

    • レスポンス・タイムアウトが 60 秒に設定されること。

  3. このサービスを管理操作画面に公開するために、同じ操作を追加します。listRepositoryimportFile という 2 つの操作を定義してください。

    plug-in/appmodel/operation.json という名前の新規ファイルを作成します。このファイルの内容は以下のとおりです。

    {
         "ServiceSample": [
              {
                   "id": "listRepository", 
                   "label": "List repository", 
                   "description": "List files in the repository", 
                   "script": "action.py listRepository"               
              },
              {
                "id": "importFile",                
                "label": "Import file via HTTP", 
                "description": "Import a single file into the repository via http url.", 
                "script": "action.py importFile", 
                "attributes": [                         
                        {
                             "label": "URL to import", 
                             "type": "string", 
                             "id": "url", 
                             "required": true, 
                             "description": "HTTP URL of a single file to import into 
                                             the repository."
                        },                                   
                   ]
              }
         ]
    }
  4. これらの操作の実行時に実行される Python メソッドを作成します。parts/servicesample.scripts/scripts/ServiceSample/action.py という名前の新規ファイルを作成します。このスクリプトは、管理操作ページから操作が実行されると呼び出されます。このスクリプトには、2 つの新しいメソッドと、これらのメソッドを実行するために必要なフレームワーク・ロジックを含めます。

  5. parts/servicesample.scripts/scripts/ServiceSample/restapi.py スクリプトを更新して、新しい REST API を追加します。以下のように、スクリプトに新規メソッドを追加してください。

    def listRepository():
        logger.debug('Called listRepository in restapi')
        ret = os.listdir(SHARED_REPOSITORY_PATH)
        #create JSON string out of return value
        ret = '{"fileList":"'+str(ret)+'"}'
        logger.debug('return value = ' + str(ret))
        maestro.operation['return_value'] = ret

    新規メソッドを呼び出すようにメインとなる run() メソッドを更新します。

    def run():
         ...
        elif mode == "listRepository":
            listRepository()
  6. NFS 共有を実際に作成する start.py ライフサイクル・スクリプトに、ロジックを追加します。

以上の変更によって、メディア・サービスはビルドおよびデプロイメントの準備ができた状態になります。

現時点で、共有サービスをテストすることができます。パターン・タイプを作成し、共有サービスの再インストールと再デプロイを行ってください。デプロイメントが完了したら、「Operations (操作)」画面でファイルをインポートし、リポジトリーを一覧表示します。

この VM に対して、ファイルのインポート元 URL がネットワーク上で可視でなければならないことに注意してください。必要に応じて、scp コマンドや、あるいは NFS 共有を使ってインポートするように、操作パラメーターと Python スクリプトをカスタマイズしても構いません。Python スクリプトはシェル・スクリプトを呼び出すこともできます。このように、多くの可能性があります。

図 5. ファイルをメディア・サービスにアップロードした後の管理操作ページ
ファイルをメディア・サービスにアップロードした後の管理操作ページ
ファイルをメディア・サービスにアップロードした後の管理操作ページ

オプション: デプロイする前にファイルをロードする

これまでの演習は、デプロイした後にファイルをロードする場合には役立ちますが、デプロイ・ボタンをクリックする前にロードするファイルを指定したいという場合を考えてみてください。そのための操作はサンプル・コードに含まれていませんが、いくつかのアドバイスがあります。

metadata.json のデプロイメント・パラメーターに、ユーザーによって入力される以下のようなオプションのフィールドを追加することができます。

         {
            "id":"filesToLoad",
            "label":"URL listing of files to load",
            "description":"List one or more URLs of files to import into the repository.
                           Multiple URLs must be separated by a comma.",
            "required":false,
            "type":"string",            
         }

このユーザーによる入力を、トポロジー文書 templates/servicesample.vm に配置します。

SharedService-Management の vm-template で、以下のように roles ブロックを編集して parms セクションを追加します。

            "roles": [
                 {
                    "type": "ServiceSample", 
                    "name": "ServiceSample"
                    "parms":{
                        #if ( ${attributes.filesToLoad })
                        "filesToLoad":"${attributes.filesToLoad }",
                        #end                        
                      }
                }

上記の parms は、ServiceSample ロールのライフサイクル・スクリプトで使用することができます。以下は、parts/servicesample.scripts/scripts/ServiceSample/install.py での例です。

if 'filesToLoad' in maestro.parms:
     filesToLoad = maestro.parms['filesToLoad']

後は、スクリプトでユーザーの入力を構文解析して、該当するファイルをダウンロードする必要があります。この機能のテストは皆さんにお任せするとして、次はクライアントの構成について説明します。

メディア・サービス・クライアントの詳細

これまでの手順で作成したメディア・サービスを実際に使用する、クライアント・サイドのプラグインを作成します。まずは、plug-in.com.ibm.sample.sharedservcie.client プロジェクトに以下の手順で説明する変更を加えてください。

  1. クライアントのデプロイ時に真っ先に実行されるファイルの 1 つは、クライアント・プロビジョナー SampleServiceProvisioner.java です。このファイルには、リンクされた共有サービスに対する REST API 呼び出しのサンプルがいくつか含まれています。現時点では、これらの呼び出しは大した操作を行いませんが、メディア・サービス用に呼び出しを変更することができます。新しい呼び出しでは、新規 listRepository REST API をテストして、エラーが返された場合は例外をスローします。例外がスローされると (VM が作成される前に) 直ちにデプロイメントが停止され、例外の詳細がログに書き込まれるようにします。

    チェックする対象は呼び出しに対する HTTP レスポンスだけですが、レスポンスに含まれる特定のデータをチェックすることもできます。注意する点として、これはオプションのコードであり、完全に削除することができますが、VM を起動する前に欠落している前提条件を検出することで、デプロイ作業者の時間も、クラウド内のシステム・リソースも節約することができます。

    createService() メソッド内の既存の REST API 呼び出しに続けて、もう 1 つの呼び出しを追加します。

              // Make a call to the Shared Service, and throw an exception if a valid 
                 response is not returned.
              response = this.registrySvc.callOperationOnSharedService(serviceName,
                    clientCloudGroup, clientVersion, ip, "listRepository", "GET", null);
              logger.logp(Level.INFO, CLASS_NAME, METHOD_NAME, "Client Sample Service
                          Provisioner: Called example GET listRepository REST call to the
                          shared service: {0}  URL: {1}",
                        new Object[] { serviceName, "listRepository"});
              int statusCode = response.getStatusCode();
              JSONObject responseData = response.getOperationResponse();
              logger.logp(Level.INFO, CLASS_NAME, METHOD_NAME, "Client Sample Service
                       Provisioner: Response back from the REST call was response status
                          code: {0}  Data: {1}",
                   new Object[] { statusCode, responseData });
              if (statusCode!= HttpURLConnection.HTTP_OK) {
                // there was a problem with the REST call to the shared service. It may 
                      not be running.
                   // Throw an exception which will stop the deployment 
                   logger.logp(Level.SEVERE, CLASS_NAME, METHOD_NAME, "Client Service
                               Provisioner: There was a problem with the response.");
                   throw new Exception ("The required Shared Service did not return a
                                         valid response. Please ensure the Shared 
                                         Service is running.");
              }
  2. VM がメディア・サービスにあるファイルを把握できるように、クライアントのライフサイクル・スクリプト (install.py) で listRepository REST API を呼び出します。ServiceClient ロールをインストールするための別の install.py が必要なので、plug-in/parts/clientsample/scripts/ServiceClient/install.py という名前の新規ファイルを作成します。

  3. 共有サービス・レジストリー情報を取得するためのコードを追加します。

    regInfo = maestro.registry.getRegistry("sample", "1.0")        
    ipAddr = regInfo['ip']
    mountPoint = regInfo['mountPoint']
  4. REST API を呼び出すためのコードを追加します。

    # Drive pcurl method
    jsonResults = pcurlInvoke(ipAddr, "sample", method, sslOpts, url, str(json))
    # now use the results however you wish
    logger.debug('return value of listRepository = ' + str(jsonResults))
  5. メディア・サービスの共有リポジトリーをマウントして、すべてのファイルをコピーするためのコードを追加します。

    mountCommand = 'mount ' +ipAddr+":/"+mountPoint+" "+ localMountPoint
    logger.debug('mount command = ' + str(mountCommand))
    rc = maestro.trace_call(logger, mountCommand , shell=True)
    logger.debug('return value mount command = ' + str(rc))
    
    logger.debug('Copying all files')
    rc = maestro.trace_call(logger, 'cp -r '+ localMountPoint+"/* 
         " +localRepository, shell=True)
    logger.debug('return value from copy command = ' + str(rc))
  6. ソース・コード全体を見て、完全なファイル実装を確認します。

この例で、共有サービス・レジストリーを照会するために使用している共有サービス名 (この例では「sample」) は、共有サービスの plug-in/applications/servicesample/appmodel.json に、"servicename": "sample" として登録した名前です。共有サービス・レジストリーを照会することによって、SampleRegistryProvider.java の getRegistry メソッドで作成された JSON オブジェクトが返されます。この例の場合、共有サービスの IP アドレスとマウント・ポイントが返されます。この情報があれば、ファイルシステムをマウントして、そこにファイルをコピーすることができます。後は、スクリプトを変更して、コピーされたファイルを仮想アプリケーション内で使用するように (例えば、ファイルを解凍してインストーラーを起動するように) します。

以上の変更によって、メディア・サービスに対するクライアント・プラグインが完成しました。このプラグインは、ビルドおよびデプロイメントの準備ができた状態になっています。

これで、クライアント・プロジェクトを作成してテストすることができます。共有サービスとクライアント仮想アプリケーションを作成、再インストール、および再デプロイしたときと同じ手順に従ってください。

メディア・サービスをデプロイした後、管理操作コンソールを使用してファイルをメディア・サービスにアップロードし、それからクライアント仮想アプリケーションをデプロイします。共有サービスと共有サービス・クライアント両方のログ・ファイルをチェックすると、クライアントがメディア・サービスに接続して、そこからファイルをダウンロードしていることがわかるはずです。

改善案

このプロセスを改善するための案をいくつか記載しますが、それぞれの改善案を詳しく検討するのは読者の皆さんにお任せします。

  • 共有サービスの管理 VM からサービス VM にメディアをバックアップします。

  • メディア・サービスのサービス VM 上にスケーリング・ポリシーを作成し、データ複製を実装します。

  • REST API にインテリジェンスを加え、接続情報を取得できるようにします (各種のサービス VM へのラウンドロビン・ルーティングを使用することができます)。

  • 以下のようにして、代替接続またはよりセキュアな接続を使用します。

    • REST API 呼び出しでクライアントの IP アドレスを指定することで、許可された IP アドレスに対してのみ、メディア・サービスがファイアウォールのポートを開くようにします。

    • NFS や HTTP に代わるセキュア・マウントおよびファイル・コピーを使用します。

  • ロードされたメタデータに基づいてファイルを検証する、メディア・アップロード・メソッドを追加します。

  • メディア・サービスからクライアントへのファイル・コピーにフィルタリングを追加します。

  • ユーザーの入力を検証して、セキュリティーを強化します。望ましくないコマンドが実行されないように、ユーザー入力および REST API パラメーターの検証を追加します。サンプル・コードでは、メディア・サービスのファイル・インポート操作からの入力パラメーターは、コマンドラインに直接渡されるため、メディア・サービス VM 上で、ユーザーが悪意のあるコマンドを実行する可能性があります。

  • メディア・サービス・クライアントをメディア・サービスに接続するコードは密結合されて、クライアントに完全に統合されています。1 つのメディア・サービス・クライアント・パターンしかなければ、これでも問題ありません。けれども、複数の異なるクライアント・アプリケーション・パターンを作成して、そのすべてが同じメディア・サービスを使用する場合、同じメディア・サービス接続スクリプトをそれぞれのプラグインに繰り返しコピーすることになります。その場合に最善策となるのは、メディア・サービス・クライアント・ロジックを専用のプラグインに分けることです。この専用プラグインは、メディア・サービスに接続して必要なファイルをダウンロードするための接続ロジック・スクリプトだけが含まれる汎用プラグイン・フラグメントで構成されます。例えば、メディア・サービスに接続してファイルをダウンロードする install.py または configure.py ライフサイクル・スクリプトを使用します。この場合、新しいクライアントを作成するときに、メディア・サービス・クライアント・ロジックは必要なくなり、クライアントはこのメディア・サービス・クライアント・プラグインを参照するだけで済みます。新規仮想アプリケーションのデプロイ時には、メディア・サービス・クライアント・プラグインのスクリプトが、仮想マシンに挿入されて、アプリケーションと併せて実行されます。

まとめ

この記事では、IBM が提供するサンプル共有サービス・プラグインについて順を追って説明するなかで、共有サービスの概要と、この共有サービスが今後共有サービスを作成する上で非常に有用なスケルトンになることを説明しました。このスケルトンを基に、管理操作コンソースからファイルをロードできる共有リポジトリーをホストするメディア共有サービスを作成する方法を説明し、続いて、この共有サービスに対するクライアントを作成するために仮想アプリケーションをカスタマイズして、メディア・サービス共有リポジトリーに接続する方法を説明しました。起動時に、クライアント VM NFS はこのリポジトリーをマウントして、ファイルをコピーします。

クラウド内に、仮想アプリケーションが使用できる単純な共有リポジトリーをセットアップする方法を学んだ今、この共有リポジトリーに変更を加えてもっと複雑なものにし、セキュリティーやさらに異なるリポジトリーを追加したりするなど、思い付く限りの機能強化を加えることができます。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing
ArticleID=843220
ArticleTitle=PureApplication System の共有サービス・ワークロードをナビゲートする
publish-date=11012012