仮想アプリケーション・パターンのワークロードで製品バイナリーを管理する

仮想アプリケーション・パターンは、IBM PureApplication System、IBM SmarterCloud Orchestrator、IBM Workload Deployer で使用されるクラウド・ワークロードのデプロイメント・モデルです。仮想アプリケーション・パターンのプラグインを開発すると、製品バイナリーの管理やインストールをしなければならない状況になります。この記事では、製品バイナリーを管理するさまざまな方法について学びます。

Bhadri Madapusi, Advisory Software Developer, IBM

Bhadri Madapusi is a Software Developer and currently focused on IBM PureApplication System pattern-type development. Bhadri has over 10 years of software development experience. Previously, he worked on cloud computing, Business Process Management, and WebSphere Commerce.



Valentina Birsan, Senior Software Developer , IBM

Valentina Birsan is a Senior Developer in WebSphere and currently focuses on IBM PureApplication System pattern-type development. Previously, Valentina was a technical lead on Rational Application Developer. She was one of the initial members of the Eclipse TPTP open source project, and served as the chair of the TPTP Architecture Group. Valentina was also the lead architect for the Cosmos Service Modeling Eclipse open source project and a member of the Service Management Language open standard.



2014年 4月 24日

はじめに

IBM PureApplication System、IBM SmarterCloud Orchestrator、または IBM Workload Deployer 上にインストールする仮想アプリケーション・パターンのワークロードを開発した場合、そのプラグインでは製品バイナリーを管理しなければならない状況になります。製品バイナリーは、自分で開発したものである場合もあれば、IBM、SAP、Oracle などのサードパーティー・ベンダーが提供するものである場合もあります。この記事では、製品バイナリーを管理するために使用できるいくつかの方法と、プラグインから製品バイナリーにアクセスしてインストールする方法について説明します。さらに、これらの方法を使用するメリットとデメリットの比較も行います。


製品バイナリーを管理する方法

製品バイナリーを管理する方法は、以下の 2 つのカテゴリーに分類されます。

  • Storehouse リポジトリーを使用する方法
  • 共有サービス・リポジトリー・サーバーを使用する方法

Storehouse リポジトリーを使用する方法

Storehouse は、システムの成果物、仮想アプリケーション・パターンのワークロード成果物、仮想アプリケーション・パターンのデプロイメント・ランタイム成果物、仮想アプリケーション・パターンのトラブルシューティング成果物を含むリポジトリーです。Storehouse リポジトリーに格納されている成果物は Storehouse ブラウザーで表示することができます。

IBM Workload Deployer と IBM PureApplication System の場合は、「Workload console (ワークロード・コンソール)」 > 「System (システム)」 > 「Storehouse Browser (Storehouse ブラウザー)」の順にナビゲートすると Storehouse ブラウザーを利用することができます。IBM SmarterCloud Orchestrator の場合は、「SmartCloud Orchestrator console (SmarterCloud Orchestrator コンソール)」 > 「Administration (管理)」 > 「Storehouse Browser (Storehouse ブラウザー)」の順にナビゲートすると Storehouse ブラウザーを利用することができます。Storehouse ブラウザーを表示できるのは「System (システム)」メニュー (または「Administration (管理)」メニュー) を利用できるユーザーのみです。図 1 に Storehouse ブラウザーに表示される典型的な内容を示します。

図 1. Storehouse ブラウザー
Storehouse ブラウザーのスクリーン・キャプチャー

クリックして大きなイメージを見る

図 1. Storehouse ブラウザー

Storehouse ブラウザーのスクリーン・キャプチャー

製品バイナリーを格納するには、Storehouse リポジトリーを使用することができます。ワークロードをデプロイする際には、仮想アプリケーション・パターンは Storehouse からこのバイナリー・ファイルをダウンロードし、仮想マシン上にインストールして構成することができます。製品バイナリーを Storehouse にアップロードするには、以下の方法のいずれかを使用することができます。

  • cURL を使用してバイナリー・ファイルをアップロードする方法
  • 自分で作成したパターン・タイプを使用してバイナリー・ファイルをアップロードする方法
  • バイナリー・ファイルをアップロードするためのパターン・タイプを別に用意し、そのパターン・タイプを使用してバイナリー・ファイルをアップロードする方法

これらの方法には、それぞれメリットとデメリットがあります。以下のセクションでは、上記 3 つの方法について説明します。ここでは、rhel_rpm.tgz というバイナリー・ファイルを Storehouse リポジトリーの /admin/files/Sample/Common/ という場所にアップロードする例を用いて説明します。

cURL を使用してバイナリー・ファイルをアップロードする方法

この方法では、cURL ユーティリティーを使用して Storehouse リポジトリーにバイナリー・ファイルをアップロードします (リスト 1)。リスト 1 のコードは図 2 の場所にファイルをアップロードします。

図 2. Storehouse ブラウザーに表示された、ファイルのアップロード場所
Storehouse ブラウザーに表示された、ファイルのアップロード場所のスクリーン・キャプチャー

クリックして大きなイメージを見る

図 2. Storehouse ブラウザーに表示された、ファイルのアップロード場所

Storehouse ブラウザーに表示された、ファイルのアップロード場所のスクリーン・キャプチャー

この方法には以下のメリットがあります。

  • 他の 2 つの方法に比べて比較的単純です。
  • バイナリー・ファイルをアップロードするために成果物やコードを追加で用意する必要がありません。

この方法には以下のデメリットがあります。

  • cURL のバリエーションのなかには、アップロードするファイルのサイズが制限されるものがあります。
  • PureApplication System では使用できません。

また、Storehouse リポジトリーにファイルをアップロードするには管理者権限が必要になります。

リスト 1. cURL を使用して製品バイナリーをアップロードする
#Upload file to storehouse under /admin/files/Sample/Common.
curl -v -u <user>:<password> -k -X PUT --data-binary @rhel_rpm.tar.tgz -H "Content-Type:
application/octet-stream" https://<server_name>/storehouse/admin/files/Sample/Common/ rhel_rpm.tgz

#Give full access to the current user and group Everyone to download the file.
curl -v -i -u <user>:<password> -k -X POST -H "Content-Type: application/json" 
-X POST -d "{\"AccessRights\":{\"$USER\":\"F\",\"_group_:Everyone\":\"
F\"}}" https://<server_name>/storehouse/admin/files/Sample/Common/rhel_rpm.tgz?meta

この方法を PureApplication System で使用する場合、Storehouse にファイルをアップロードすることはできますが、ファイルのグループ・アクセス制御を (上記の 2 番目の curl コマンドのように) Everyone に設定することができないため、Storehouse から仮想アプリケーション・パターンにファイルをダウンロードすることができません。

自分で作成したパターン・タイプを使用してバイナリー・ファイルをアップロードする

この方法では、仮想アプリケーション・パターン・プラグインが含まれるパターン・タイプとバイナリー・ファイルをパッケージ化します。ビルド済みパターン・タイプのアーカイブ・ファイルをアーカイブ解凍ツールで開くと、図 3 のような内容であることがわかります。アーカイブは、patterntypes フォルダー (アーカイブ・フォーマットのパターン・タイプ・プロジェクトが含まれます) と plugins フォルダー (アーカイブ・フォーマットのプラグイン・プロジェクトが含まれます) で構成されています。このパターン・タイプを Workload Deployer、PureApplication System、または SmarterCloud Orchestrator にインストールすると、patterntypes フォルダーの中身は Storehouse リポジトリーの /admin/patterntypes に格納され、plugins フォルダーの中身は Storehouse リポジトリーの /admin/plugins に格納されます。

図 3. ビルド済みパターン・タイプのアーカイブ・ファイルを展開した内容
ビルド済みパターン・タイプのアーカイブ・ファイルを展開した内容のスクリーン・キャプチャー

上記の説明で Storehouse リポジトリーがどのように使用されるかを理解できたことと思います。バイナリー・ファイル rhel_rpm.tgz を /admin/files/Sample/Common に配置するには、ビルド済みパターン・タイプのアーカイブ内に rhel_rpm.tgz ファイルが含まれる files/Sample/Common というフォルダーを作成する必要があります (図 4 を参照。訳注: 図 4 では「SAP」というフォルダー名と「rhel_rpm.tar.gz」というファイル名になっていますが、これを「Sample」というフォルダー名と「rhel_rpm.tgz」というファイル名に読み替える必要があります。図 5、6 でも同様です)。この変更されたパターン・タイプをインストールすると、Storehouse リポジトリーの /admin/files/Sample/Common にバイナリー・ファイルが格納されます (図 2)。

図 4. バイナリー・ファイルが含まれるように変更された、パターン・タイプのアーカイブ・ファイルを展開した内容
バイナリー・ファイルが含まれるように変更された、パターン・タイプのアーカイブ・ファイルを展開した内容のスクリーン・キャプチャー

図 4 のようにバイナリー・ファイルをパッケージ化できるように、この記事の「ダウンロード」セクションには addStorehouseFiles.xml という Ant ビルド・ファイルを用意してあります。このユーティリティーは IBM Workload Deployer の Eclipse PDK 環境で実行することができます。このユーティリティーを使用するには、IBM Workload Deployer の Eclipse PDK 環境を開き、この Ant ファイルをパターン・タイプ・プロジェクトの下に配置します。また、図 5 のように storehouse/files というフォルダーを作成する必要もあります。このサブフォルダー内のファイルが図 4 に表示される files フォルダーにマッピングされます。

「IBM Pattern Toolkit」 > 「Build (ビルド)」の順に選択してパターン・タイプをビルドしたら、addStorehouseFiles.xml ファイルを右クリックし、「Run As (実行)」 > 「Ant Build (Ant ビルド)」の順に選択します。この Ant スクリプトは、パターンのビルド・ステップで作成されたアーカイブ・ファイル /patterntype_project/export/built_pattern_type_version.tgz を解凍します。そして /patterntype_project/storehouse 配下のフォルダーとファイルを再度 tar で圧縮します。このサンプル Ant スクリプトを使用する前に、addStorehouseFiles.xml を編集して patternTypeFile プロパティーの値を変更し、パターン・タイプの名前とバージョンが反映されるようにします。

図 5. パターン・タイプの PDK プロジェクトと addStorehouseFiles.xml ユーティリティー
パターン・タイプの PDK プロジェクトと addStorehouseFiles.xml ユーティリティーのスクリーン・キャプチャー

クリックして大きなイメージを見る

図 5. パターン・タイプの PDK プロジェクトと addStorehouseFiles.xml ユーティリティー

パターン・タイプの PDK プロジェクトと addStorehouseFiles.xml ユーティリティーのスクリーン・キャプチャー

この方法には以下のメリットがあります。

  • 任意のサイズのファイルをアップロードすることができます。ワークロード・コンソールのユーザー・インターフェースを使用してパターンをインストールする場合には、2 GB の制限があります。ファイル・サイズが 2 GB を超える場合には、ワークロード CLI 環境を使用します。
  • バイナリー・ファイルと関連プラグインを 1 つのエンティティーとして、パッケージ化して提供することができます。

この方法を使用する場合、そのパターン・タイプがシステムから削除されると Storehouse リポジトリーからバイナリー・ファイルが削除されます。そのため、以下のデメリットがあります。

  • バイナリー・ファイルのサイズが大きい場合、一緒にパッケージ化されているパターン・タイプの機能要素を更新するたびに、大量の時間とネットワーク・リソースが必要になります。
  • 同じバイナリー・ファイルを複数のパターン・タイプで共有する場合、バイナリー・ファイルをアップロードするために使用したパターン・タイプが不要になった場合でも、システム内にそのパターン・タイプを保持し続ける必要があります。

パターン・タイプのアップロードには管理者権限が必要です。この方法を使用するユーザーは、管理者グループに属している必要があります。

バイナリー・ファイルをアップロードするためのパターン・タイプを別に用意し、そのパターン・タイプを使用してバイナリー・ファイルをアップロードする方法

上記のデメリットに対処するには、仮想アプリケーション・パターンの機能成果物を含むパターン・タイプからバイナリー・ファイルを分離する方法があります。この方法では、バイナリー・ファイルと仮想アプリケーション・パターンのプラグインの両方を 1 つのパターン・タイプで処理するのではなく、2 つのパターン・タイプを使用して処理します。一方のパターン・タイプにはバイナリー・ファイルのみが含まれ、もう一方のパターン・タイプには仮想アプリケーション・パターンのプラグインが含まれます。パターン・タイプの作成方法は、前のセクションでパターン・タイプを作成したときと同じ方法です。唯一の違いは、このパターン・タイプには仮想アプリケーション・パターンのプラグインが含まれないことです。図 6 は、バイナリー・ファイルのみが含まれるパターン・タイプの例を示しています。仮想アプリケーション・パターンのプラグインからバイナリー・ファイルを分離すると、機能成果物とは別にバイナリー・ファイルを管理できるようになります。

図 6. バイナリー・ファイルのみが含まれるパターン・タイプのアーカイブ・ファイルを展開した内容
バイナリー・ファイルのみが含まれるパターン・タイプのアーカイブ・ファイルを展開した内容のスクリーン・キャプチャー

この方法には以下のようなメリットがあります。

  • 複数のパターン・タイプでバイナリー・ファイルを共有することができます。
  • バイナリー・ファイルとパターンの機能的な側面を別々に更新して管理することができます。

この場合も、パターン・タイプのアップロードには管理者権限が必要です。この方法を使用するユーザーは、管理者グループに属している必要があります。


Storehouse リポジトリーからバイナリー・ファイルをダウンロードする

ここまでで Storehouse リポジトリーにバイナリー・ファイルをアップロードする方法を説明したので、今度は仮想アプリケーション・パターンのインスタンスによって作成された VM にこれらのファイルをダウンロードする方法を見ていきましょう。Storehouse リポジトリーからファイルをダウンロードするには、parts ライフサイクル・スクリプトの中で仮想アプリケーション・パターンの maestro フレームワークを使用します。仮想アプリケーション・パターンの maestro フレームワークと parts ライフサイクル・スクリプトの詳細については、この記事の「参考文献」セクションを参照してください。

リスト 2 は Storehouse リポジトリーからバイナリー・ファイルをダウンロードする方法を示しています。maestro.filesurl を呼び出すと、/admin/files の場所が HTTP の URL フォーマットで返されます。これにより、この URL にファイルの場所を追加し、maestro.downloadx メソッドを使用して適切な場所にファイルをダウンロードして解凍することができます。仮想アプリケーション・パターンで作成された仮想マシンにバイナリー・ファイルがダウンロードされたら、それらのバイナリー・ファイルをインストールして構成することができます。

リスト 2. Storehouse リポジトリーからファイルをダウンロードする
def downloadBinaries():
	logger.debug("enter downloadBinaries")
	fileName = 'Sample/Common/rhel_rpm.tgz'
	installerUrl = urlparse.urljoin(maestro.filesurl, fileName)   
	downloadPath = '/home/virtuser'    
	logger.debug('download ' + installerUrl)
	maestro.downloadx(installerUrl, downloadPath)
	logger.debug("exit downloadBinaries")

この記事では、バイナリー・ファイルのみが含まれるパターン・タイプ (patterntype.binaryonly) の作成方法と、バイナリー・ファイルと機能プラグインの両方が含まれるパターン・タイプ (patterntype.storehouseupload と plugin.storehouseupload) の作成方法を示すためのサンプル・コードを提供しています。


共有サービス・リポジトリー・サーバーを使用する方法

共有サービスは、あらかじめ定義されている仮想アプリケーション・パターンであり、同じクラウド・グループにデプロイされる複数のワークロード (仮想アプリケーション、仮想システム、仮想アプライアンスなど) で共有することができます。1 つのクラウド・グループに許可される共有サービスのインスタンスは 1 つのみです。共有サービスと共有サービスの作成方法についての詳細は「参考文献」セクションを参照してください。

共有サービスのためのリポジトリー・サーバーを作成すれば、ワークロードに必要なバイナリー・ファイルをそのサーバーでホストすることができます。この共有サービス・リポジトリー・サーバーは、必要なインターフェースを公開できるため、バイナリー・ファイルを必要とする仮想アプリケーション・パターンのワークロードは、公開されているインターフェースを使用して、リポジトリー・サーバーに接続し、適切なファイルをダウンロードすることができます。

この記事では、NFS サーバーとして動作する共有サービス・リポジトリー・サーバーのサンプルと、NFS マウントを使用してバイナリー・ファイルをダウンロードする仮想アプリケーション・パターン・ワークロードのクライアントを提供しています。この共有サービス・リポジトリー・サーバーは、デプロイ時に、バイナリー・ファイルの格納に必要なディスク・サイズでプロビジョニングされます。共有サービス・リポジトリー・サーバーには、デプロイ後の操作も用意されており、この操作によって外部システムから HTTP プロトコルを使用して必要なバイナリーをアップロードすることができます。図 7 は、このデプロイ後の操作を示しています。

図 7. 共有サーバーの操作画面
共有サーバーの操作画面のスクリーン・キャプチャー

クリックして大きなイメージを見る

図 7. 共有サーバーの操作画面

共有サーバーの操作画面のスクリーン・キャプチャー

Workload Deployer、PureApplication System、SmarterCloud Orchestrator の共有サービス・インフラストラクチャーには、デプロイされた共有サービスに関する情報を含むレジストリーがあります。クライアントは、このレジストリーを照会し、利用する必要がある共有サービスに関する情報を得ることができます。サンプルでは、レジストリーを通じてリポジトリー・サーバーがホスト名と NFS マウントのエンドポイントをクライアントに公開します。リスト 3 は、この情報を RegistryProvider インターフェースを使用して共有サービスのレジストリーに提供する方法を示しています。共有サービス・リポジトリー・サーバーを利用するリポジトリー・クライアントは、ライフサイクル・スクリプトの中で maesro.registry フレームワークを使用することにより、共有サービス・サーバーのホスト名と NFS エンドポイントをレジストリーから取得し、NFS エンドポイントから必要なバイナリー・ファイルをコピーすることができます。リスト 4 はサーバーが公開するレジストリーからリポジトリー・クライアントが詳細情報を取得する方法を示しています。

リスト 3. 共有サービス・リポジトリー・サーバーの情報をレジストリーに提供するためのコード
public class SampleSharedServiceRegistryProvider implements RegistryProvider {
  private static final String CLASS_NAME =
   SampleSharedServiceRegistryProvider.class.getCanonicalName();
  private static Logger logger = Logger.getLogger(CLASS_NAME);
  public final String LOCAL_BINARIES_REPOS_PATH="/shared_repository";

  public JSONArtifact getRegistry(String clientVersion,
    Map<String, JSONObject> deploymentInfo) throws HttpException {
    String METHOD = "getRegistry";
    JSONObject registry = new JSONObject();
    JSONObject deploymentDoc = deploymentInfo.get
        (RegistryProviderConstants.DEPLOYMENT_DOC);
    logger.logp(Level.FINE, CLASS_NAME, METHOD, "enter getRegistry ");
    //get instance ip addresses and return in the registry
    if(deploymentDoc != null){
      JSONObject instances = (JSONObject) deploymentDoc.get("instances");
      if (null != instances) {
	for (Object key : instances.keySet()) {
	 String keystr = (String)key;
	 if(keystr.startsWith("SampleSharedService")){
           Object ipAddr = ((JSONObject) instances.get(key)).get("public-ip");
                       String ip = (String)ipAddr;
                       registry.put("serviceHost", ip);
	 }
        }
      }
     }
     registry.put("mountPoint", LOCAL_BINARIES_REPOS_PATH);
     logger.logp(Level.FINE, CLASS_NAME, METHOD,
         "getRegistry exit. Registry return="+registry);
     return registry;
  }
}
リスト 4. 共有サービス・リポジトリー・サーバーの情報をレジストリーから取得するためのクライアント・コード
# Retrieve info on SharedService (IP) so we know where to go
regInfo = maestro.registry.getRegistry("sampleMediaService", "1.0")
serviceHost = regInfo['serviceHost']
mountPoint = regInfo['mountPoint']

この方法を使用するメリットは、Storehouse を介してバイナリーを共有したくない場合には、独自のバイナリー・リポジトリー・サーバーを使用できることです。共有サービス・レジストリーは参照ディレクトリーとして使用されるため、バイナリーを必要とするクライアントとバイナリーを提供するリポジトリー・サーバーとのやりとりは疎結合になります。

共有サービス・リポジトリー・サーバーを使用することによる主なデメリットは、1 つのクラウド・グループには 1 つのタイプの共有サービスしか許可されないことです。そのため、そのクラウド・グループにデプロイされるものはすべて、同じリポジトリー・サーバーを共有することになります。また、共有サービス・サーバーの作成や保守にはオーバーヘッドが追加されます。共有サービス・サーバーをインストールしてデプロイするには、管理者権限が必要です。


サンプルを操作する

この記事には、以下のサンプル・パターン・タイプ (およびソース) が用意されています。

  • patterntype.binaryonly-1.0.0.0.tgz
  • patterntype.storehouseupload-1.0.0.0.tgz
  • ptype.installsharedservice-1.0.0.0.tgz

Storehouse リポジトリーのサンプルを操作する

patterntype.binaryonly-1.0.0.0.tgz または patterntype.storehouseupload-1.0.0.0.tgz をインストールすると、/admin/files/Sample/Common/ rhel_rpm.tgz というファイルが Storehouse に追加されます (図 2)。

また、patterntype.storehouseupload-1.0.0.0.tgz を使用すると、図 8 のような仮想アプリケーション・パターンのサンプルを作成することができます。この仮想アプリケーション・パターンをデプロイすると、このパターンは Storehouse にアップロードされたファイルを仮想マシン上の /home/virtuser/binaries にダウンロードして解凍します。この仮想アプリケーション・パターンはリスト 2 のコードを使用してファイルをダウンロードします。

大きなバイナリー・ファイルをアップロードする場合のヒント

Workload コンソールまたは SmarterCloud Orchestrator コンソールのユーザー・インターフェースを使用してパターン・タイプをインストールする場合には、2 GB を超えるパターン・タイプをインストールすることができません。つまり、コンソール・ブラウザーのインターフェースを使用して、大きなバイナリー・ファイルを Storehouse にインポートすることはできないということです。この制約を克服するには、CLI API を使用してパターン・タイプをインストールしなければなりません。以下の手順に従えば、コマンドラインからパターン・タイプをインストールすることができます。

  1. コマンド・プロンプトを開き、パターン・タイプのアーカイブ・ファイルが存在するディレクトリーにカレント・ディレクトリーを変更します。
  2. IBM Workload Deployer、IBM PureApplication System、または IBM SmarterCloud Orchestrator システムから CLI zip をダウンロードして、/pathToCli に解凍します。

使用する IBM クラウド・ソリューションに応じて、コマンドラインから以下のコマンドを実行します。

/pathToCli/pure.cli/bin/pure -h IPAS_IP -u <user> -p <pwd>

または

/pathToCli/deployer.cli/bin/deployer -h IPAS_IP -u <user> -p <pwd>

CLI のプロンプトが表示されたら、以下のコマンドを実行します。

deployer.patterntypes.create('YourPatternType-1.0.0.0.tgz')
図 8. patterntype.storehouseupload を使用して作成された仮想アプリケーション
patterntype.storehouseupload を使用して作成された仮想アプリケーションのスクリーン・キャプチャー

クリックして大きなイメージを見る

図 8. patterntype.storehouseupload を使用して作成された仮想アプリケーション

patterntype.storehouseupload を使用して作成された仮想アプリケーションのスクリーン・キャプチャー

共有サービス・リポジトリーのパターン・タイプのサンプルを操作する

パターン・タイプ ptype.installsharedservice-1.0.0.0.tgz をインストールして有効にしたら、共有サービス Sample Shared Service をデプロイし、入力としてバイナリー・リポジトリー用にプロビジョニングするディスク・サイズを指定します。この共有サービスをデプロイしたら、仮想アプリケーション・コンソールに用意されているデプロイ後の操作を使用して、共有サービス・リポジトリーにバイナリー・ファイルを追加します。そのためには、共有サービスが実行状態になったら、その実行状態の共有サービスのインスタンスを選択し、「Manage (管理)」ボタンをクリックします。すると、仮想アプリケーション・コンソールが開きます。仮想アプリケーション・コンソールで、「Operations (操作)」 > 「MediaService (メディア・サービス)」の順に選択すると、図 7 に示すように実行可能な操作が 2 つ表示されます。2 番目の操作「Import file via HTTP (HTTP でファイルをインポート)」を使用して、バイナリー・リポジトリーにファイルを追加します。ファイルが複数ある場合は、この操作を複数回繰り返します。

共有サービス・リポジトリーをテストするには、パターン・タイプ sample.installsharedservice 1.0 をベースに仮想アプリケーション・パターンを作成してデプロイします (図 9)。先ほどのセクションで説明したように、この仮想アプリケーション・パターンは、共有サービス・リポジトリーに関する詳細として、共有サービス・リポジトリーの IP と NFS マウント・ポイントをレジストリーから取得します (リスト 4 のコードを参照)。クライアントはこのデータを使用してエンドポイントをマウントし、バイナリーをダウンロードします。

図 9. sample.installsharedservice を使用して作成された仮想アプリケーション
sample.installsharedservice を使用して作成された仮想アプリケーションのスクリーン・キャプチャー

クリックして大きなイメージを見る

図 9. sample.installsharedservice を使用して作成された仮想アプリケーション

sample.installsharedservice を使用して作成された仮想アプリケーションのスクリーン・キャプチャー

まとめ

この記事では、仮想アプリケーション・パターンのワークロードで使用するバイナリー・ファイルを管理するためのさまざまな方法と、そのメリットとデメリットについて説明しました。これらのメリットとデメリットを考慮すると、バイナリー・ファイルを管理する最善の方法は Storehouse リポジトリーを使用する方法であり、Storehouse リポジトリーへバイナリー・ファイルをアップロードする最善の方法はバイナリー専用のパターン・タイプを使用する方法であるといえます。

謝辞

共有サービス・リポジトリー技術の概念に関して助言をしてくださった IBM の Jim Riordan 氏に感謝いたします。


ダウンロード

内容ファイル名サイズ
Code samplecode_sample.zip76KB

参考文献

コメント

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=969111
ArticleTitle=仮想アプリケーション・パターンのワークロードで製品バイナリーを管理する
publish-date=04242014