目次


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

Comments

はじめに

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 ブラウザーのスクリーン・キャプチャー
Storehouse ブラウザーのスクリーン・キャプチャー

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

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

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

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

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

図 2. Storehouse ブラウザーに表示された、ファイルのアップロード場所
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 ユーティリティーのスクリーン・キャプチャー
パターン・タイプの 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. 共有サーバーの操作画面
共有サーバーの操作画面のスクリーン・キャプチャー
共有サーバーの操作画面のスクリーン・キャプチャー

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 を使用して作成された仮想アプリケーションのスクリーン・キャプチャー
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 を使用して作成された仮想アプリケーションのスクリーン・キャプチャー
sample.installsharedservice を使用して作成された仮想アプリケーションのスクリーン・キャプチャー

まとめ

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

謝辞

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


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


関連トピック


コメント

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing
ArticleID=969111
ArticleTitle=仮想アプリケーション・パターンのワークロードで製品バイナリーを管理する
publish-date=04242014