パターン・カスタマイズ 1 それでは、パターンのカスタマイズのセッションを始めさせていただきます。 IBM PureApplication サマー・スクール

by user

on 15 сентября 2016

Category: Documents

>> Downloads: 4

views

Report

Comments

Description

Download パターン・カスタマイズ 1 それでは、パターンのカスタマイズのセッションを始めさせていただきます。 IBM PureApplication サマー・スクール

Transcript

パターン・カスタマイズ 1 それでは、パターンのカスタマイズのセッションを始めさせていただきます。 IBM PureApplication サマー・スクール

IBM PureApplication サマー・スクール
第３部応用実践編：PureApplication Systemにおけるパターン開発と運用･管理
パターン・カスタマイズ
ISE.PureSystemsソリューション今関靖一郎 ([email protected])
© 2013 IBM Corporation
それでは、パターンのカスタマイズのセッションを始めさせていただきます。
1
Disclaimer

この資料は日本アイ・ビー・エム株式会社ならびに日本アイ・ビー・エムシステムズ・エ
ンジニアリング株式会社の正式なレビューを受けておりません。

当資料は、資料内で説明されている製品の仕様を保証するものではありません。

資料の内容には正確を期するよう注意しておりますが、この資料の内容は2013年07
月現在の情報であり、製品の新しいリリース、修正などによって動作／仕様が変わる
可能性があるのでご注意下さい。
PureApplication
Summer School
2
© 2013 IBM Corporation
2
Agenda

§1.
§2.
§3.
§4.
パターンのカスタマイズ概要
仮想システム・パターンにおけるカスタマイズ
仮想アプリケーション・パターンにおけるカスタマイズ
まとめ
New
Update
： V1.1から追加になった機能等を示す
： V1.1から更新・変更になった機能等を示す
3
© 2013 IBM Corporation
本セッションは「パターンののカスタマイズ」についてのセッションです。
PureAppが提供する2種類のパターン・モデルそれぞれで利用できる機能・ツールおよ
びそれらのユースケースをご紹介し、どのようにしてお客様の要件に合わせてパターン
のカスタマイズをしていくのかをご説明するセッションになっております。
第１章でパターンのカスタマイズの概要をお話しした後、２章・３章でパターン別に具体
的にどうカスタマイズをするかのユースケースをご説明いたします。
3
§1 パターンのカスタマイズ概要
4
© 2013 IBM Corporation
それでは、まずパターンに対するカスタマイズの概要についてお話しいたします。
4
PureAppが提供するパターン・モデル
仮想システム・パターン
トポロジー視点
ノウハウの活用
9 ミドルウェアの構成要件から実行基盤を構築
9 ミドルウェアの導入・構成のノウハウが実装
9 従来型のマネジメント・モデル
5
仮想アプリケーション・パターン
ベスト・プラクティス
ワークロード視点
9 アプリケーションの要件から実行基盤を構築
9 要件に対し、基盤にベスト・プラクティスが実装
9 ポリシー主導のマネジメント・モデル
© 2013 IBM Corporation
第1部・第2部のセッションからの繰り返しの話にはなってしまいますが、PureAppでは
仮想システム, 仮想アプリケーションの２つの異なるパターン・モデルを提供しています。
仮想システム・パターンはトポロジー視点、すなわちミドルウェアの視点でシステム構
成を決定していくアプローチのパターン・モデルです。具体的には、ミドルウェアとして
はWASとDB2を使用する、WASはクラスター構成で、DB2はHADR構成でシステムを
組む、といった要件からシステム構成を決定し構築するパターン・モデルです。
一方、仮想アプリケーション・パターンはワークロード視点、すなわちアプリケーション
の視点でシステムを考えた場合に、必要なコンポーネントとアプリケーション実行環境に
対する非機能要件をもとに、システム構成を決定するアプローチのパターン・モデルで
す。具体的には、システムにはJavaのEARアプリケーションがあり、データベースとユー
ザー・レジストリーをアプリケーションとしては稼働のために必要としています、アプリ
ケーションを動かすノードに関しては耐障害性を保証するために冗長化します、という
情報をもとに、推奨かつ実績のあるシステム構成をPureAppか判断し、ユーザーに提供
するパターン・モデルです。
これら2種類のパターン・モデルに関しては後ほど第2，3章で再度ご説明いたします。
5
パターンを選択し、速やかに環境構築

PureSystems Centreを活用し、必要なソリューションに合うパターンを調査
http://www.ibm.com/software/brandcatalog/puresystems/centre/

提供されるパターンのトポロジーおよび機能を確認し、採用可否を判断

別途ライセンスの購入が必要なものもある
開発期間と実装難易度を考慮して採用を検討し、構築をスタート
Data Management
Solutions
Software Delivery
and Lifecycle
Asset and Facilities
Management
Business
Analytics & Data
Warehousing
Social
Collaboration
App
Infrastructure
Security, Risk
Management , Compliance
Business
Process
Mgmt
6
Mobile Development
and Connectivity
トポロジーや何ができるか
を把握して利用可否を判断
Connectivity,
Integration
and SOA
© 2013 IBM Corporation
仮想システム, 仮想アプリケーションともに現時点で様々なソリューションのパターンが
提供されております。それらはPureSystems Centreと呼ばれますサイトで公開されて
おります。パターンでシステム構築を行う際、まずはPureSystems Centreから提供した
いソリューションに合ったパターンを調査し、適切なパターンが存在する場合にはその
パターンがとりうるトポロジーが望ましいか、パターンとして何が機能として提供されてい
るかをさらに調査・確認します。トポロジー・機能ともに適切と判断した場合は、そのパタ
ーンをベースに速やかに環境構築を進めることが可能です。
但し、PureSystems Centreに掲載されているパターンは別途ライセンス購入が必要
なものも含まれる点には注意が必要です。パターンでデリバリーを行う場合は、環境構
築の期間やソリューションの実装難易度を考慮して、パターンを購入するのがよいか、
デリバリー・チームのスキルで一からパターンを開発するのが適切かを十分に検討する
ことが求められます。
6
パターンの開発・カスタマイズをしないのが理想だが・・・
パターンで提供される標準構成で速やかに環境構築
標準的な構成・設定のため多くの
システムの基盤として利用可能
運用管理ツール
の組み込み
構築担当者
仮想システム・パターン
ギャップ
が発生
ODR
OS
ODR
OS
DB2
OS
WAS
OS
DB2
OS
WAS
OS
アプリの前提となる
OS・ミドルウェアの設定
ギャップの解消は
どうすれば・・・
DM
OS
WAS
OS
セキュリティー対応
カスタマイズしてくれるよね!!
運用担当者&アプリ担当者
各企業 / システム毎にカスタマイズの必要性が存在
7
© 2013 IBM Corporation
適切なパターンを選択した後、インフラ構築担当者はパターンからデプロイのボタンを
押すだけで必要なミドルウェア稼働環境を速やかに提供することができます。しかしな
がら、実際に利用・運用を行うアプリケーション/運用担当者の期待する稼働環境とギャ
ップが生じる可能性があります。
パターンが提供する構成はあらゆるお客様のシステム基盤として採用しやすい形で汎
化された標準構成になります。そのため、運用管理のためのツールの組み込みやアプ
リケーションの稼働のための要件など、お客様によってカスタマイズの要件が発生しま
す。「カスタマイズの要件数」＝「パターンでのシステム構築に対するギャップ」となり、ギ
ャップが大きいほどカスタマイズにかける作業が多く発生してしまいますので、パターン
から構築を行う場合にはなるべくこのギャップを最小限に抑えることを検討する必要があ
ります。
では、どのようにギャップの解消を考えていけばよいでしょうか?
7
ギャップを解消していくために

構築する環境の引き渡し先（アプリ / 運用担当者）にヒアリング実施

ヒアリング結果で得た要件の実現性・実装の難易度を整理

ベースとするパターンの取るトポロジーの情報はきちんと伝達
その上で、何がアプリ開発 / 運用を行う上で最低限必要かを確認
パターン化の基本は自動化の実装
GUIではなく、コマンドライン前提で実装可能かを検討
開発期間・再利用性を考慮して、パターンへの組み込み可否を検討

無理に自動化の作りこみをすることは作業工数を肥大化させる要因となる
開発期間が短い場合は、繰り返し利用可能な操作を優先して作りこみ

OSのセキュリティ設定など、すべてのVMに共通して行う操作が対象
・何でも無理に開発しようとしない
・繰り返し使うものから先に開発
が開発工数を抑えるポイント!!
8
© 2013 IBM Corporation
ギャップを解消していくための1つの方法として、「早期にアプリケーション/運用担当者にヒアリ
ングすること」が挙げられます。
近年、DevOpsという近年のITシステムのムーブメントを表す用語が登場してきておりますよう
に、ITシステムはやはり構築する側, 利用/運用する側一体となって考えていかなければなりませ
ん。構築担当者だけで何をカスタマイズすべきかを考えるのではなく、早期にアプリケーション/
運用担当者など引き渡し先と会話を持ち、パターンで構築する場合のインフラはどのようなもの
なのかを伝えた上で、何がアプリケーション/運用として必要なのかヒアリングの実施をご検討く
ださい。パターンで構築されるシステムは容易にデプロイできますので、場合によっては環境を
一旦デプロイし、何が足りないかを実機で確認いただくのもよいかと考えます。「ギャップを正しく
認識すること」、それが最重要です。
ヒアリング結果をもとに、次に自動化(スクリプト化)の容易性・実現性を考慮して要件の優先順
位付けを考えます。要件上自動化が難しい項目の場合は、アプリケーション/運用担当者から対
応必須か否かを再度確認いただいたうえで、工数を割いてでも自動化が必要かどうかを検討し
ます。
要件の優先度がある程度定まった時点で、あとは開発期間等プロジェクトとしての期間を考慮
して、パターンに組み込むか否かを検討します。例えば手動で3分程度で行える操作に関し、3
時間程度かけてスクリプトを開発するのは、規模によっては工数に対する実益はあまり得られな
い場合もあり得ます。実装するか否か迷った場合は、他のシステム環境でも繰り返し利用可能
(Reusable)な操作かどうかで実装を優先すべきかを検討します。
以上のステップを踏み、パターンとしてどこまで実装するかを明確化すれば、パターンの開発・
カスタマイズの無駄は最小限に抑えられるかと考えます。
8
パターンのカスタマイズはどう進める?

パターンのカスタマイズの流れはパターン・モデルにより異なる

開発する粒度が異なるため、進め方も変わることに注意が必要
仮想システム・パターン [VSP] の場合
MW
OS
仮想イメージの開発
実行スクリプトの開発
仮想アプリケーション・パターン [VAP] の場合
パターン・タイプ / プラグインの開発
9
© 2013 IBM Corporation
先のページで何をパターンとして組み込むかを明確にし、カスタマイズの要件を整理
したうえで、実際にどのようにパターンをカスタマイズしていくかが次に話題として挙がり
ます。
PureAppが提供するパターン・モデルは冒頭で2種類あると申し上げました。それぞれ
実装が異なりますので、カスタマイズの流れも実装に合わせて変わっていきます。
詳細については2, 3章で述べますが、仮想システム・パターン(Virtual System
Pattern, 省略してVSPとも記載されます)においては仮想イメージ(仮想マシンのテンプ
レート)とデプロイ時に実行するスクリプトが開発対象であり、仮想アプリケーション・パ
ターン(Virtual Application Pattern, 省略してVAPとも記載されます)の場合はシステム・
プラグインおよびその論理セットであるパターン・タイプが開発対象となります。
9
パターンのカスタマイズに利用するPureAppの機能&ツールは？

PureAppが提供する機能

[VSP(*1)] スクリプト・パッケージ

[VSP] アドオン

[VSP] 仮想イメージの複製（Clone）, 拡張（Extend）, 収集（Capture）

仮想マシンに対して任意のカスタマイズを行うためのスクリプト群
デプロイメント時に、仮想マシンに対してハードウェア構成変更するためのスクリプト群
仮想イメージに対しカスタマイズ（機能拡張）を行うための機能
パターンのカスタマイズの支援ツール

[VSP] IBM Image Construction and Composition Tool (ICCT)

[VAP(*2)] IBM Workload Plug-in Development Kit (PDK)

仮想イメージに対するカスタマイズ・ツール
仮想アプリケーション・パターンの開発ツール
次章より利用ケース・指針をご説明
10
(*1) 仮想システム・パターン
(*2) 仮想アプリケーション・パターン
© 2013 IBM Corporation
仮想システムおよび仮想アプリケーション・パターンそれぞれの開発対象を開発して
いくために、PureAppは複数の機能と支援ツールを提供しています。これらに関して、
次章より各機能・ツールの説明とユースケースをご説明いたします。
10
§2. 仮想システムにおける
パターンのカスタマイズ
11
© 2013 IBM Corporation
それでは、実際にどうカスタマイズしていけばよいのか、機能&ツールの説明とユースケ
ースを踏まえて説明していきます。まずは、仮想システムにおけるパターンのカスタマイ
ズです。
11
仮想システム・パターン

トポロジー（ミドルウェア構成）を意識したパターン・モデル

使用するミドルウェアおよび構成に対する要件をもとにシステムを設計・構築
ユーザーのオーダー通りにアプリケーション実行基盤を提供
□ 使用するミドルウェアの要件
・WebSphere Application Server V8.5
・DB2 Enterprise Server Edition HV V10.1
WAS
OS
ODR
OS
ODR
OS
□ ミドルウェアに対する構成要件
・WASの動的クラスター構成
・WASの自動スケーリング有効化
・DB2のHADR構成 etc…
WAS
OS
WAS
OS
DM
OS
DB2
OS
DB2
OS
指定した通りに実行環境を提供
ミドルウェア構成を意識してパターンを作成
12
© 2013 IBM Corporation
再度、仮想システム・パターンについてご説明します。
仮想システム・パターンはトポロジー視点、すなわちミドルウェアの視点でシステム構
成を決定していくアプローチのパターン・モデルです。具体的には、ミドルウェアとして
はWASとDB2を使用する、WASはクラスター構成で、DB2はHADR構成でシステムを
組む、といった要件からシステム構成を決定し構築するパターン・モデルです。
ミドルウェア導入済みの仮想マシン・テンプレートである仮想イメージをもとに、目的に
合わせて必要な仮想イメージを選択し、後にご紹介いたしますスクリプト・パッケージと
アドオンでデプロイに合わせて動的に設定変更を行うようにパターンに規定します。そ
のように定義されたパターンに対し、デプロイを実施すると、仮想イメージから必要な役
割の仮想マシンが生成され、パターンに定義されたスクリプトが自動で実行されて、必
要とする実行基盤ができあがります。
12
仮想システム・パターンの裏側

パターンに合わせて仮想イメージとスクリプトを組み合わせて構築
ユーザー視点
パターンの裏側
パート別に実行
パターンの作成
デプロイ
必要な機能に対する
スクリプトを使用
① 仮想イメージ
② アドオン
ディスク追加 / NIC追加 etc..
③ ビルトイン・スクリプト
動的クラスターの作成 etc..
④ スクリプト・パッケージ
ユーザー独自の設定
13
© 2013 IBM Corporation
開発・カスタマイズを行う上で、パターンからどのようにシステムが生成されるか、その
裏側を把握することが重要です。これから仮想システムにおけるパターンのデプロイの
裏側をご説明いたします。
ユーザーの視点としては、必要なパターンをパターン・エディターで作成し、デプロイ
を実行すると必要がシステムができあがるというシンプルなものですが、その裏ではまず
パターン・エディターで選択したパートが定義された仮想イメージ(仮想マシン・テンプレ
ート)から仮想マシンが生成されます。仮想マシンが生成され、OSとしての構成が完了
すると、パート別に用意された構成用のスクリプトが実行されます。その後で主に仮想マ
シンのハードウェア構成変更用のアドオン、パターンでクラスター構成など拡張オプショ
ンとして設定した場合に呼び出されるビルトインのスクリプト、ユーザー・カスタマイズた
めのスクリプト・パッケージが呼び出され、必要な実行環境ができあがる仕組みになって
おります。
13
仮想システム・パターンの開発対象と使える機能&ツール

仮想システム・パターンでの開発対象

仮想イメージ
MW
OS

デプロイ時に生成される仮想マシンのテンプレート
IBMの主要MW製品はHypervisor Editionとして提供される
実行スクリプト
デプロイ時に実行されるスクリプト
OSの設定変更やミドルウェアの設定変更を実施するために必要

開発で利用できる機能&ツール

14
スクリプト・パッケージ
アドオン
仮想イメージの複製（Clone）, 拡張（Extend）, 収集（Capture）
IBM Image Construction and Composition Tool (ICCT)
© 2013 IBM Corporation
前ページでご紹介いたしましたように、仮想システムにおけるパターンはしかるタイミン
グで実行される仮想イメージと実行スクリプトで構成されています。したがって、「仮想シ
ステムにおけるパターンの開発・カスタマイズ」=「仮想イメージと実行スクリプトの開発」と
いうことになります。これらを開発・カスタマイズするために利用可能な機能&ツールとし
て、スクリプト・パッケージ、アドオン、仮想イメージの複製(Clone), 拡張(Extend), 収集
(Capture)、IBM Image Construction and Composition Tool(ICCT)が提供されていま
す。
まずは、パターンのカスタマイズにおいて一番汎用性が高く、現場で最もよく使われる
機能である、スクリプト・パッケージについてご説明いたします。
14
スクリプト・パッケージ

生成した仮想マシンのカスタマイズを行うためのスクリプト実行の仕組み
.zip or .tgz (.tar.gz)で実行ファイルおよび関連ファイルをパッケージング
cbscript.json, extendedattributes.jsonと呼ばれる特殊なファイルで実行動作を定義
Update スクリプトで導入するミドルウェアのライセンス情報を追跡する機能を提供
主な開発言語: .bash(Linux), .ksh(AIX), .bat(Windows) など

デプロイ毎に動的に変わる環境情報を変数としてスクリプトを実行可能

他のパートの環境情報も${part-name.property-name}の形で取得可能
4種類の実行タイプを提供
1.
仮想システムの作成時（デフォルト)
2.
仮想システムの削除時

3.
4.
仮想システム・インスタンスおよび
仮想マシン個別の削除時に実行
デプロイ
1,4
デプロイ後任意のタイミングで実行
仮想システムの作成時および開始時

2,4
MW
OS
MW
OS
開始時

New
デプロイ、および仮想マシンの複製時に実行
パターンのデプロイ時および任意のタイミングで実行
15
1
メンテナンス等
複製
MW
OS
3
削除
© 2013 IBM Corporation
スクリプト・パッケージは、デプロイした仮想マシンのカスタマイズを行うためのスクリプト実行の
仕組みになります。スクリプト実行の定義を記載したcbscript.jsonやV1.1より新規に追加された
補助用の定義ファイルであるextendedattributes.jsonにしたがってスクリプトを実行します。実
行ファイルの詳細は補足資料P.65-67をご参照ください。
このスクリプト・パッケージはデプロイ時に動的に変わる環境情報(ホスト名など)を変数としてス
クリプトを実行したり、実行する先の仮想マシンに依存せずスクリプト・パッケージのレベルで実
行順序を指定する機能を有しています。これらを用いることで、仮想マシン間の連携のために行
わなければならない設定や設定の依存関係・実行順を表現できますので、複雑な設定の自動
化(オーケストレーション)を実現することが可能になります。また、V1.1よりスクリプト・パッケージ
で導入するミドルウェアのライセンスを追跡するための機能が追加され、W1500においては
Windowsサポートに合わせてWindows環境での実行もサポートされるようになりました。
このスクリプト・パッケージには4種類の実行タイプがあります。
1つ目は「仮想システムの作成時」でデプロイのタイミング、あるいはデプロイ後のパターン・イ
ンスタンス(パターンの枠組みで管理される仮想マシン群)に対するスケール・アウト時(仮想マシ
ンに対する複製操作の実行時)に呼び出されます。
2つ目は「開始時(任意のタイミング)」で、実行者の好きなタイミングでスクリプト・パッケージの
実行が可能なタイプになります。特徴として、何度も好きなタイミングで実行可能なので、運用の
自動化もこのタイプを用いてパターンに組み込むことが可能です。
3つ目は「仮想システムの削除時」で、パターン・インスタンスの一部である仮想マシンを削除し
た場合に呼び出されます。
4つ目は「仮想システムの作成時および開始時」で、1つ目および3つ目を合わせたタイプにな
ります。V1.1より追加になりました。
15
[Info] スクリプト・パッケージの設定例
1. スクリプト・パッケージを選択
2. ドラッグ&ドロップ
4. 実行順序を指定
3. プロパティー値を設定
16
詳細は参考資料[4],[5]を参照
© 2013 IBM Corporation
スクリプト・パッケージはPureApp上でどのように操作して利用するかをまとめました。
パターン・エディターでスクリプトを実行させたいパートにドラッグ&ドロップして、必要に
応じてプロパティー値を変更、スクリプト・パッケージの実行順を指定する操作を実施す
ることになります。詳細に関しては参考資料[3],[4]に詳しくまとめられておりますので、ご
参照ください。
16
スクリプト・パッケージの実装（1/3）：仮想システムの作成時

利用ケース

ミドルウェアの構成変更や運用管理エージェントの導入
実装方針

実行スクリプトの実装

スクリプト・パッケージとしての実装

ミドルウェアの設定変更, 運用管理エージェントの導入スクリプトを作成
実行タイプは「仮想システムの作成時」を選択
デプロイ毎に変わるホスト名等を引数にする場合は環境変数を利用（補足P.68 ）
パターン構成
IH
S
WA
S
DM
DB2(P)
デプロイ
DB2(B)
ミドルウェアの設定変更
運用管理のエージェント導入
17
APサーバーの設定変更
IHS
運用
OS
IHS
運用
OS
WAS
運用
OS
WAS
運用
OS
WAS
運用
OS
運用管理エージェント導入
DM
運用
OS
DB2
運用
OS
DB2
運用
OS DBの設定変更
© 2013 IBM Corporation
これより3ページにわたり、スクリプト・パッケージのユースケースをご説明します。
スクリプト・パッケージのユースケースの1番目ですが、例えばパターンからデプロイさ
れる標準構成の実行基盤に対して、アプリケーションの前提条件を満たすために、アプ
リケーション・サーバーやデータベースに対してシステム個別の設定変更を行いたい、
あるいは運用管理のためにエージェントを導入したい、というようなケースがあるとします。
この場合、シンプルにパターンに対してカスタマイズを行いたいのであれば、スクリプト・
パッケージでの実装がお勧めです。
実行タイプは「仮想システムの作成時」を選択します。実装としては、ミドルウェア個別
に設定変更ロジック、運用管理のエージェントの導入のロジックをスクリプトに組み込む
流れになります。
より発展的な使い方として、例えばアプリケーション・サーバーからデータベースを同じ
パターン内で定義し、デプロイしたとして、アプリケーション・サーバーからデータベース
に対して連携設定を行いたい場合を想定します。この場合、環境によってデプロイ時に
可変するホスト名をどのように取得してアプリケーション・サーバーの設定時に利用する
か実装に悩まれるケースが発生するかと思います。スクリプト・パッケージの場合、他の
仮想マシンのホスト名等の環境情報を変数として取得することが可能になっていますの
で、その機構を使うことで実装がよりシンプルになります。詳しくは補足資料P.68をご参
照ください。
17
スクリプト・パッケージの実装（2/3）：開始時（任意のタイミング）

利用ケース

OS/MWのセキュリティー設定および定期的な設定確認を実施する必要がある
実装方針

実行スクリプトとしての実装

スクリプト・パッケージとしての実装

OSセキュリティーの設定および設定確認を行うスクリプトを作成
実行タイプは「開始時(任意のタイミング)」を選択
デプロイ時にも実行したい場合は「仮想システムの作成時および開始時」を選択
実行ログはPureApp上にも保管可能
各VMに個別にログインせず、実行・結果を確認
セキュリティー上
問題ないことを
定期的に確認
MW
OS
ファイルのパーミッション確認
18
XX.properties
オーナー： virtuser
パーミッション： -rw-r--r--
© 2013 IBM Corporation
運用の自動化・簡素化のためにスクリプト・パッケージを利用することも可能です。
例えば、OSセキュリティー要件で、利用するミドルウェア製品個別にディレクトリーの
パーミッションやオーナーのチェックをこまめに設定し、チェックする必要性が課せられ
る場合があります。この操作は手動であれスクリプトであれ、設定・確認の実行には時間
がかかる恐れがありますので、(特に自動スケール・イン/アウトを考慮する場合は)デプロ
イ時ではなくデプロイ後に任意のタイミングで行いたい場合があります。また、セキュリ
ティー要件は定期的に見直され、時に変更が必要になりますので、定期的な保守期間
に合わせて定期的に確認作業を行うことが望まれます。
こうした「任意のタイミングで実行したい」要件のカスタマイズにおいては、実行タイプと
して「開始時」としたスクリプト・パッケージでの実装を考えます。
スクリプト・パッケージとして実装すれば、PureAppのワークロード・コンソール上からス
クリプトを任意のタイミングで実行できますし、スクリプトの標準/エラー出力および実行ロ
グはPureAppのコンソール上からダウンロードできるようにも設定可能ですので、わざわ
ざ仮想マシンに1台1台ログインしての作業は不要になります。
このように、パターンに対しちょっとした運用の自動化の組み込みも、スクリプト・パッ
ケージを利用することで可能になります。
18
スクリプト・パッケージの実装（3/3）：仮想システムの削除時

利用ケース

WAS HVの自動スケーリング(Elasticityモード)実装時のログ管理

自動スケール・イン時に仮想マシンのログ・ファイル等を退避する必要性がある場合など
実装方針

実行スクリプトとしての実装

退避が必要なログ・ファイルをNFS, SCP, FTPなどを利用して転送するスクリプトを作成
スクリプト・パッケージとしての実装

実行タイプは「仮想システムの削除時」を選択
ログの退避にNFSを利用する場合は、「NFSマウント」のアドオンの併用で実装を簡素化
WAS
OS
ファイル転送
ODR
OS
WAS
OS
スケール・イン
ODR
OS
削除・・・
19
WAS
OS
ログ等
NFS
仮想マシン削除時に
必要なファイルを転送
© 2013 IBM Corporation
最後に、実行タイプが「仮想システムの削除時」のスクリプト・パッケージの利用ケース
をご説明いたします。
仮想システム・パターンでWAS HVを利用する場合、Elasticityモードと呼ばれる自動
スケーリング機能を使用することが可能です。Elasticityモードを用いることで、負荷に応
じて仮想マシンを追加・削除するスケール・アウト/インを人手を介さず実施でき、負荷に
応じて常に最適なシステム・リソースでアプリケーションの実行基盤を運用していくことが
可能になります。
こうした自動スケーリング機能を利用するときの課題として、スケール・イン時に削除さ
れる仮想マシンが持つ重要な情報、特にログ・ファイルが仮想マシンと一緒に削除され
てしまい、情報が失われてしまうことが挙げられます。
ログ・ファイル等重要な情報を失わないようにするためには、スクリプトで仮想マシン削
除をトリガーにNFSサーバーなどのファイル・サーバーに転送してデータを保管する対
応を実装することが考えられますが、スクリプト・パッケージでは「仮想マシンの削除時」
のタイプでログの退避ロジックを組み込むことで対応できます。特に、NFSを前提とする
場合、V1.1より追加になったNFSマウントのアドオンを利用すれば、NFSマウントの処理
ロジックの実装の省力化も可能です。場合によってはそのアドオンを利用する前提での
実装も検討します。
以上のように、スクリプト・パッケージは様々なユースケースで利用できる、汎用的なカ
スタマイズ機能であることがご理解いただければと思います。
19
スクリプト・パッケージで大抵のことは実現できるが… ①

仮想マシンのハードウェア構成を変更したい要件が生じる

環境に合わせて複数のセグメントに仮想マシンが接続する必要がある場合

各仮想マシンに対してサービスLANと運用LANに対する接続が必要になる、など
ミドルウェア要件上、ディスク容量がデプロイ時に不足する可能性がある場合
サービスLAN
MW
OS
各マシンに対し
空きXX GB必要
管理LAN
運用管理のために
管理LANにも接続
20
ハードウェア構成は
どう変更すればよい?
© 2013 IBM Corporation
スクリプト・パッケージは非常に汎用性の高いカスタマイズ機能になっていますので、
スクリプトで表現できる・自動化できる処理に関して大抵のことは実現可能です。しかし
ながら、スクリプト・パッケージでは充足できない、あるいは考慮が必要になるケースも存
在します。
例えば、パッチ管理系の運用ツールを組み込む際に仮想マシン上にテンポラリとして
ある程度のディスク領域を確保しておきたいという要件がある場合やミドルウェアの導入
のための前提としてのディスク・スペースの確保を行わなければならない場合など、仮想
マシンに対するハードウェア構成を変更したい場合は、スクリプト・パッケージでは実現
できません。
同様に、複数ネットワーク・セグメントがあり、仮想マシンが複数のネットワーク・セグメン
トに所属する必要がある場合もスクリプト・パッケージでは対応できません。
そうした仮想マシンに対するハードウェア構成の設定変更を行うための機能として、ア
ドオンと呼ばれるカスタマイズ機能が提供されています。
20
アドオン

主に仮想マシンのハードウェア構成を変更するための特殊なスクリプト

デプロイ時に1度のみ実行される
アドオンの種類 ( W1500 V1.1の場合)

ディスクの追加

Default add disk: 追加する仮想ディスクをGB単位で指定, フォーマット実施
Default add raw disk: 追加する仮想ディスクをGB単位で指定, フォーマットしない
NICの追加

Default add NIC：一般の仮想マシンに対しNICを追加
Default configure NIC： DataPowerなどの仮想アプライアンス用
New NFSマウント
Default add NFS: NFSマウントを実施

仮想ディスク
ユーザーの追加

Default add user: OSのユーザーを追加
ユーザー
仮想NIC
MW
OS
NFS
NFSマウント
21
© 2013 IBM Corporation
アドオンはディスク追加など、主に仮想マシンのハードウェア構成変更を行うための機
能になります。アドオンの種類(タイプ)として、ディスク追加, NIC追加, NFSマウント,
ユーザー追加の4種類が提供されています。特にV1.1よりNFSマウントのアドオンが追
加されており、ログの退避などでNFSマウントを利用するのであれば、NFSマウントのア
ドオンを利用することを想定してのカスタマイズを検討すると、NFSマウントの実行ロジッ
クの作成にかける工数を削減できます。
ハードウェア構成が要件上変更になる場合は、アドオンを使用することをご認識いた
だければと思います。
21
[Info] アドオンの設定例
2. ドラッグ&ドロップ
1. 利用したいアドオンを選択
3. 必要によりプロパティー値を指定
22
© 2013 IBM Corporation
アドオンはPureApp上でどのように操作して利用するかをまとめました。
P.16のスクリプト・パッケージと同様、パターン・エディターでアドオンを実行させたい
パートにドラッグ&ドロップして、必要に応じてプロパティー値を変更することになります。
スクリプト・パッケージと違い、アドオンの場合は実行順序の指定は不要です。
22
スクリプト・パッケージで大抵のことは実現できるが… ②

デプロイ時に実行するスクリプトが多いとデプロイに時間がかかる

ミドルウェアの導入をスクリプトで実行すると1時間弱かかる製品もある
スケール・アウトを考慮したとき、時間がかかることがネックになり得る
自動化が難しい操作に対してスクリプト・パッケージでの実装は困難

OSの細かい設定変更、GUI前提のミドルウェア
スクリプトでは導入
に時間がかかる・・・
自動化しにくい操作も
ある程度自動化したい
導入・構成
OS
MW
OS
デプロイ時にある程度作業を省力化できないか?
23
© 2013 IBM Corporation
仮想マシンのハードウェア構成の変更はスクリプト・パッケージではなくアドオンで対応すると
いうことをご説明いたしました。それ以外にもスクリプト・パッケージでは実現が難しい、あるいは
実装を考慮するケースがございます。
例えば、OS設定の標準化対応や追加でミドルウェアを導入するようなケースを想定します。自
動化は可能であっても、ミドルウェアによっては導入に時間のかかるものもありますし、行うべき
設定が多くなれば多くなるほど実行すべきスクリプトの実行時間や本数が増えていくことになりま
す。スクリプト・パッケージは基本的にシリアルに実行されていくため、結果として規模やカスタマ
イズ内容によってはデプロイに時間がかかってしまう可能性が考えられます。もちろん初回の構
築時に多少実行に時間がかかることに問題はないように思われる方も多いかと思いますが、もし
デプロイ後負荷に応じてマニュアルあるいは自動スケーリングを実施するのであれば、致命的
になるケースが発生しえます。処理に計30分かかるスクリプトがあるとして、あるタイミングで高負
荷となり10-20分程度でサーバーをもう一台追加したいケースでそのスクリプトがデプロイ時に実
行されると、仮想マシンの作成+30分程度の時間がかかってしまうことになり、これでは望むスケ
ーリングが物理的に実現できないことになってしまいます。スクリプトの実行時間に対する配慮
は重要です。
また、自動化の実装難易度が高いあるいはそもそもGUI前提のため自動化ができないミドルウ
ェアの導入を行わなければならない場合は、スクリプト化が難しいということですので、スクリプト・
パッケージでの対応は困難です。
このようにデプロイ時に設定する項目等が多く実行に時間がかかるケースや、そもそも自動化
が難しいケースに関してはスクリプト・パッケージでの対応ではなく、仮想イメージの開発・カスタ
マイズを検討します。仮想イメージに定義されている仮想マシンに必要な設定を事前に行って
おくことで、デプロイ時に設定する項目は削減できますし、事前導入が許されるのであれば、自
動化が難しい操作もデプロイ時に行わなくて済みますので、デプロイに対する迅速性と自動化
が難しい部分の設定の省力化の実現が期待できます。
23
仮想イメージの複製(Clone), 拡張(Extend), 収集(Capture)

カタログに登録されている仮想イメージのカスタマイズを行う機能

複製 (Clone)

仮想イメージの複製を行う機能
複製のオプションとして、ハードウェア構成(ディスク・サイズ)の編集が可能
z

rootパーティション以外のディスクが対象
拡張 (Extend)
仮想イメージが定義する仮想マシンの設定変更を実施するための機能
対象の仮想イメージを複製し、そのイメージから仮想マシンがデプロイされる
収集 (Capture)

拡張時に生成された仮想マシンから仮想イメージを生成する機能
仮想イメージのロック（編集禁止）を行うまで何度でも実施可能
MW
拡張（Extend）
MW
OS
パーティション拡張
設定変更対応
OS
収集（Capture）
MW
MW
OS
OS
拡張（Extend）
MW
複製（Clone）
24
OS
OS設定変更
ディスク・サイズ
の変更が可能
© 2013 IBM Corporation
仮想イメージの開発・カスタマイズのために、仮想イメージに対して複製(Clone), 拡張
(Extend), 収集(Capture)の3つの操作が提供されています。仮想イメージの開発の流
れはこれらの機能と絡めて下段のフローチャートで表されます。
まず、ベースとなる仮想イメージを選択します。選択した仮想イメージに対し拡張操作
を行うことで、仮想マシンが1台生成されます。その仮想マシンにログインし、手動ないし
はスクリプトを用いて設定変更を行います。そして、設定変更を行った仮想マシンをテン
プレート元として、収集操作を実施することで新しい仮想イメージができあがります。この
ように、仮想イメージの拡張⇒仮想マシンの編集⇒仮想イメージの収集の流れが仮想イ
メージの開発の流れになります。
仮想イメージには予め仮想マシンの構成が定義されていますが、例えば既に定義さ
れているディスクの拡張を行いたい要件もあるかと思います。例えばWAS HVにおいて、
稼働させるアプリケーションのプロファイル・ディレクトリー(仮想マシン上で稼働する
WASのJVMの構成が定義されているディレクトリー)のサイズを拡張したい場合は、仮
想イメージの複製操作を利用します。複製操作はベースとなる仮想イメージのコピーを
作成するだけでなく、rootパーティション以外のディスク・サイズの変更を行うことが可能
です。ディスクの拡張を行いたい場合は複製操作を利用する、ということをご認識いただ
ければと思います。
(参考) Extending partition and file system sizes
http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm
.ipas.doc%2Fiwd%2Fpct_extend_fs.html
24
仮想イメージの操作例 (1/3) ：複製
MW
1. 仮想イメージを選択
OS
2. [複製]をクリック
MW
3. ディスクサイズを変更
OS
ルート・パーティションはPureApp
の機能では拡張できないことに注意
25
ディスク・サイズが変更された
イメージが作成される
© 2013 IBM Corporation
P.25-P.27の3ページで、PureAppのワークロード・コンソール上での仮想イメージの各操作を
まとめました。いずれの操作に関しても仮想イメージのカタログ画面でベースとなるイメージを選
択した状態で、実施したい操作のアイコンをクリックすることで行います。詳細な操作に関しては
、参考資料[5]をご参照ください。
本ページは仮想イメージの複製操作を行う場合の操作の流れをまとめたページです。
25
仮想イメージの操作例 (2/3)：拡張
MW
4. 複製した仮想イメージを選択
OS
5. [拡張]をクリック
テンプレート
VMのデプロイ
MW
OS
6. デプロイに必要な情報を入力
26
7. VMにログインし、
カスタマイズを実施
© 2013 IBM Corporation
本ページは仮想イメージの拡張操作を行う場合の操作の流れをまとめたページです。
26
仮想イメージの操作例 (3/3)：収集
MW
8. 拡張した仮想イメージを選択
OS
9. [収集]をクリック
MW
MW
OS
仮想イメージの収集
（再テンプレート化）
OS
カスタマイズした仮想マシン
新しく生成された仮想イメージ
でパターンの開発を実施
収集の操作時にリセットされる項目があるため、
事前にOS設定などカスタマイズする場合は要注意
27
© 2013 IBM Corporation
本ページは仮想イメージの収集操作を行う場合の操作の流れをまとめたページです。
なお、収集操作時にホスト名やロケール設定など環境固有情報をもとに設定されているOS設
定は次回のデプロイのためにリセットされる仕様となっていますので、事前にOS設定をカスタマ
イズする場合には注意が必要です。できあがった仮想イメージをベースにデプロイを行い、どこ
の項目がリセットされたかを確認し、リセットされた項目をスクリプト・パッケージで設定するか等
検討する必要があります。
27
仮想イメージの操作の利用ケース

利用ケース

事前にマウントされるディスクのサイズが明らかに不足する場合

導入に時間のかかる or 導入の自動化が難しいミドルウェアの事前導入の実施

ルート(root)・パーティション以外のディスクが対象
ミドルウェアが仮想マシンの複製展開を許容していることが前提
実装（作業）方針
必要に応じて仮想イメージの複製操作で導入に必要なディスク・スペースを確保
仮想イメージの拡張操作でテンプレートとなる仮想マシンをデプロイ
ミドルウェアの導入を実施後、仮想イメージの収集を実施

MW
OS
PureAppが導入
しないMWを追加したい
28
複製・拡張
MW
OS
MWの導入など
カスタマイズ実施
収集
MW MW
OS
ホスト名に依存する
MWの場合は注意が必要
© 2013 IBM Corporation
仮想イメージの各操作のユースケースとして、導入に時間のかかる、あるいは導入の自動化が
難しいミドルウェアを事前に導入してデプロイ後の作業を省力化したい、OS設定を事前に行い
たいというケースが挙げられます。
この場合、P.25-27で記載いたしましたように、ベースとなる仮想イメージを選択し、必要によっ
て仮想イメージの複製でディスク・サイズの変更を行った後、拡張操作で仮想マシンを生成して、
追加でミドルウェアを導入するなどの作業を行い、仮想マシンに対して収集操作を行うことで必
要とする仮想イメージを作成する流れになります。
考慮事項として、事前導入するミドルウェアが仮想化環境をサポートしているかどうか、特に仮
想マシンの複製展開を許容し、複製展開した場合に行う作業が明確になっているかどうかが挙
げられます。事前にミドルウェアを導入したとしても、環境固有の情報(ホスト名など)をミドルウェ
アの構成情報として持ってしまう場合は、導入済みの仮想イメージでデプロイを行ったとしても、
収集前の環境固有の情報がミドルウェアの構成情報に含まれているために稼働できない、とい
うケースが発生する可能性があります。したがって、事前に追加導入したいミドルウェアに対して、
複製展開時に環境固有情報を書き換える操作の必要性とその方法を事前に調査したうえで、
仮想イメージに導入するかどうかをご検討ください。
また、仮想イメージによっては、収集時に初期化されるディレクトリ/ファイルが存在します。例え
ばWAS HVの場合、プロファイル・ディレクトリ(/opt/IBM/WebSphere/Profiles)は収集時に初期
化される仕様となっているため、WASの上に導入するパッケージ製品で、導入時にプロファイル
が作成されてしまう製品に関しては事前導入はできません。ベースとなる仮想イメージの仕様を
確認した上で、事前導入ができるかどうかも検討が必要になることをご認識おきください。
28
より効率的に仮想イメージを開発・管理するには

仮想イメージの開発を進めると、以下の2点に直面する恐れがある：

仮想イメージの管理が煩雑になる懸念
MW1: 2.0.0.1
MW2: 1.0.0.?
MW3: ???

MW1
OS
各製品の正確なバージョン管理は困難
各ミドルウェアのバージョンの
組み合わせが古いので再構成が必要
再開発時のスキルセットに対する懸念
MW
OS
再作成する必要があるが
どうやって作るんだろう・・・
複数人で開発
極力運用管理を容易にしつつ、
メンテナンスも容易にできないか
29
© 2013 IBM Corporation
仮想イメージを開発・カスタマイズしていくことで、デプロイの迅速性や自動化の難易度を抑え
ることが可能にはなりますが、開発を続けていくと、2点運用上の懸念が生じます。
1点目は「仮想イメージの管理が煩雑になる懸念」です。1つの仮想イメージに複数のミドルウ
ェアが追加で複数導入されている場合、PureAppからみて仮想イメージに対し何が導入されて
いるのかの管理が難しいです。管理する数が少なければよいですが、例えばフィックスが適用さ
れる毎に定期的に仮想イメージを開発するようなケースの場合には、管理する対象が増えてい
きますので、何がどのように導入され、カスタマイズされているかの管理が複雑化していき、運用
担当者の交代等で運用の引き継ぎも困難になる懸念が生じます。
2点目は「再開発時のスキルセットに対する懸念」で、実際に運用担当者が仮想イメージの再
開発を行うことになった時に、前任の開発者と同じスキルを有していないケースが発生しうるかと
思います。単純にミドルウェアを導入するだけであれば難しくはないかもしれませんが、カスタマ
イズが複雑化すればするほど運用担当者のスキルだけでは対応しきれなくなる可能性が高まり
ます。そのため、運用を引き継ぐためにも、前任の開発者が詳細に仮想イメージの開発手順を
文書化しておく必要があり、前任の開発者に余計な手間と時間を強いてしまうことになります。ま
た、仮に手順書があったとしても、運用担当者がそれを見て作業をしなければならないので、オ
ペミスの心配等再開発に対する不安感は払拭できず、非常に引き継ぎにくい状況が発生します
。
自動化ができない操作に関してであれば、これらの懸念に対し「仮想イメージの再開発はしな
い」など運用の仕方で回避を検討する必要があります。もし、自動化ができる操作であれば、
IBM Image Construction and Composition Tool(ICCT)を用いることで、定期的に仮想イメー
ジのメンテナンスを行いつつも仮想イメージの運用管理を容易し、なおかつデプロイの迅速性
の確保が狙えます。
29
IBM Image Construction and Composition Tool (ICCT)

仮想イメージのカスタマイズをサポートするIBM ミドルウェア製品

主な機能

独自のカスタム仮想イメージを作成するためのツール
稼働中のVMをベースに仮想イメージを作成
仮想イメージに対しソフトウェア・バンドルの単位でスクリプトを組み込み、管理
PureAppをはじめとし、様々な環境の仮想イメージを作成・管理が可能

ソフトウェア・バンドルの共有で各環境で同等の設定を展開
③OSイメージの選択
バンドルの追加
Image Creater
ESX or ESXi
SmartCloud
Enterprise
Software Specialist ②バンドルの作成
IWD
連携可能
OS Specialist
30
①ベースとなる
OSイメージの作成
PureApp
ICCT
© 2013 IBM Corporation
IBM Image Construction and Composition Tool (以降ICCTと略記します)は、仮想
イメージをカスタマイズし管理することに特化したIBMミドルウェア製品になります。サー
バーに導入してWeb経由で利用するカスタマイズ・ツールになります。
自動化が前提にはなりますが、仮想イメージに対するカスタマイズをソフトウェア・バン
ドルという単位で管理し、必要なソフトウェア・バンドルを仮想イメージに紐づけることで
仮想イメージのカスタマイズを行います。また、カスタマイズした仮想イメージに関して、
どのようなカスタマイズを行ったのかを管理し、必要に応じてカスタマイズ内容を追跡す
ることが可能となっています。ソフトウェア・バンドルに関しては次のページでご説明いた
します。
ICCTはPureAppに同梱された仮想イメージのカスタマイズ・管理ツールになりますが、
機能としては他の環境とも連携できます(*1)。ソフトウェア・バンドルを共有することで
PureApp外の環境においても同等の仮想イメージを作成することが可能になっていま
す。
(*1)
ICCTの導入方法として、仮想アプリケーション・パターンとして導入する方法と、モ
ジュールをPureAppからダウンロードして、サポートされるOSに手動で導入する方法の
2通りあります。前者を以後VAP版のICCT、後者をスタンドアローン版のICCTと本セッ
ションでは表記いたします。後者はPureAppと連携できません。
30
機能①: 仮想イメージの作成 - Windowsイメージの作成

PureAppで利用可能な以下のエディションのイメージを新たに作成可能に：

Windows Server 2008 R2 SP1 (64 bit)

Windows Server 2012 (64 bit)

Update
ESX 4.x, ESXi 4.x および ESXi 5.0 Update 1 Fix 4以上のVMware環境が必要(*)
ESXi 5.0 Update 1 Fix 4以上のVMware環境が必要(*)
Windowsライセンスは別途用意する必要あり
稼働中のVMを
インポート
仮想イメージを
エクスポート
WIN
ESX (i)
VMware環境
（PureApp外）
WIN
仮想イメージをイ
ンポート
ICCT
PureApp
Windowsを利用する場合はICCTの利用が必須
31
*) ESXi 5 1は2013年7月時点で未サポト
© 2013 IBM Corporation
ICCTの持つ機能として、稼働している仮想マシンをベースに仮想イメージを作成する
機能がまず挙げられます。この機能はPureApp外にVMware ESX/ESXi環境があり、そ
の上で稼働していることが利用の前提になります。
V1.1よりW1500に関してはWindowsのサポートが追加されました。Windowsのデプロ
イ環境を作成するためにはICCTの利用が必須で、この機能を使用して仮想イメージを
作成する必要がある点にご注意ください。サポートされるOSはWindows Server 2008
R2 SP1(64bit)以上あるいはWindows Server 2012(64bit)以上となります。各OSの種
類によりサポート前提となるVMware ESX/ESXi環境にも制限がございますのでご注意
ください。
31
機能②: 仮想イメージの編集 - ソフトウェア・バンドル

仮想イメージのカスタマイズを自動化するためのスクリプト群
主にインストール / リセット / 構成タスク時に実行されるスクリプトで構成

必要に応じて軽量の導入モジュールやサブスクリプトも合わせてパッケージ可
その他導入する製品の定義や実行の前提条件などを定義
ソフトウェア・バンドルの各タスクの実行タイミング
インストール
（同期）
仮想イメージの
選択と編集
構成
(デプロイ)
リセット
（収集）
設定確認と微修正
仮想イメージの選択
とパターン作成
MW
OS
バンドル
MW
OS
32
OS
リセット・タスク実行
イメージの
同期
インストール・タスク実行
デプロイ
イメージの
収集
OS
スクリプト
パッケージ
の実行
MW
OSMW
OS
構成タスク実行
© 2013 IBM Corporation
ICCTの機能として仮想イメージの編集も可能です。編集はソフトウェア・バンドルと呼ばれる単
位で考えます。
ソフトウェア・バンドルとは、仮想イメージのカスタマイズを行うためのスクリプト群です。主にイン
ストール / リセット / 構成タスクと呼ばれる3つのタイミングで実行されるスクリプトとそのソフトウェ
ア・バンドルで何を導入するのか、前提条件は何か、などの情報を規定したメタデータで構成さ
れています。
下の図はICCTでの仮想イメージの開発のフローを表しています。まず、開発者はベースとな
る仮想イメージを選択し、カスタマイズしたい内容に合わせて事前に用意したソフトウェア・バンド
ルを組み合わせます。その後で仮想イメージの同期という操作を行い、仮想マシンがデプロイさ
れます。その後、インストール・タスクで定義されたスクリプトが実行されます。インストール・タスク
後に開発者は生成された仮想マシンの状態を確認し、問題がなければ収集の操作を行います。
収集時にリセット・タスクが呼び出され、仮想マシンのテンプレート化が行われる前に不要なファ
イルの消し込みなどを行うスクリプトをこのタイミングで実行できます。収集完了後、新しい仮想イ
メージができあがり、そのイメージをパターンに含めてデプロイすると、仮想マシンのデプロイに
合わせて構成タスクで定義されたスクリプトが実行されます。構成タスクは確かにデプロイ時に
実行されるので、スクリプト・パッケージで実装する場合と同様デプロイの迅速性を失わせてしま
うのではないかと思われるかもしれません。しかしながら、スクリプト・パッケージはシリアルに実
行されるのに対し、構成タスクは複数の仮想マシンに対しそれぞれのタイミングでパラレルにス
クリプトを実行させることが可能です。したがって、仮想マシン共通でデプロイ時に実施すべき項
目が多くある場合は、それらを構成タスクで実装することで、パラレルに実行できる分デプロイが
迅速化できます。
このようにして、先にご紹介した仮想マシンの各操作で仮想イメージを開発するよりも、よりシス
テマティックに仮想イメージの開発が可能になります。
32
機能③: 仮想イメージの作りこみ - パーソナリティー

仮想システムで利用するパートを作成するための機能

1つの仮想イメージで複数の目的の仮想マシンを定義可能

パーソナリティーごとに実行する構成スクリプトを分けて定義することで差別化
目的別に複数仮想イメージを作成することを回避し、管理対象を削減
MW1の導入・設定
MW2の導入・設定
MW1
OS
MW1のパートとしてデ
プロイ
OS
MW2
MW2のパートとしてデ
プロイ
OS
ユーザーにはMW1のイメージとMW2の
イメージがあるように表示
33
© 2013 IBM Corporation
さらにICCTでは仮想イメージの作りこみのために、パーソナリティーと呼ばれるソフト
ウェア・バンドルのグルーピングの仕組みを提供しています。このパーソナリティーは仮
想イメージのパートを作成するための機能です。
例えば、MW1およびMW2の導入・設定のためのスクリプトがそれぞれ手元にあるとし、
各ミドルウェア用にソフトウェア・バンドルを作成したとします。それぞれ別々にソフトウェ
ア・バンドルを用いて各ミドルウェア専用の仮想イメージを作成することもできますが、
パーソナリティーでソフトウェア・バンドルをグルーピングし、MW1用のパートとしてMW1
のソフトウェア・バンドル、MW2用のパートとしてMW2のソフトウェア・バンドルを用いるよ
うに設定することで、1つの仮想イメージでそれぞれのミドルウェア用の仮想マシンをデ
プロイすることが可能となります。
33
ICCTでの仮想イメージの作成手順 (概要)

ICCTコンソール上 [イメージおよびバンドル] > [イメージのビルドおよび管理]を選択
ベースとなるイメージを複製し、同梱したいソフトウェア・バンドルを選択
右上の実行したいタスクのアイコンを選択し、仮想イメージをビルド

同期(Synchronize)：仮想イメージの複製操作を実施
収集（Capture）：仮想イメージの収集操作を実施
操作に応じてアイコンをクリック
収集
同期
必要に応じてパーソナリティーを定義
カスタマイズ内容に応じてバンドルを追加
詳細な操作は参考資料[5]を参照
イメージの作成に複雑な手順はない
34
© 2013 IBM Corporation
このページでは、ICCT上で仮想イメージをどのような操作で開発するかを説明してい
ます。基本的には、ICCTのコンソール上仮想イメージの管理画面を開き、カスタマイズ
対象の仮想イメージに対してソフトウェア・バンドルを追加し、同期・収集アイコンを適時
クリックして実行するだけで仮想イメージを開発可能です。仮想イメージの各操作のよう
に、一旦デプロイされた仮想マシンにログインして手動で作業する必要性はありません。
手順としてシンプルに仮想イメージの開発が可能になりますので、初回こそソフトウェ
ア・バンドルを構成する手間はかかりますものの、運用を引き継いだ担当者にICCTの操
作を引き継げば、後の仮想イメージの開発はそう複雑なことをしなくても実施できます。
ゆえに、ICCTを利用すれば、仮想イメージの管理の考慮点で挙げた、スキルセットの懸
念を最小限まで緩和することができると考えます。
詳細な操作に関しては、参考資料[5]をご参照ください。
34
ICCTでの発展的な仮想イメージ実装例 (1/2)

想定ケース

処理に時間がかかるミドルウェアの導入までは事前に実施
デプロイ時にフィックス・レベルを選択し、デプロイ実施可能としたい
実装の方針

ミドルウェアの導入はインストール・タスク、フィックス適用は構成タスクで実施

フィックスはNFSサーバー等に配置

フィックス・レベルは構成タスク時に実行するスクリプトの引数で指定させるように実装
構成タスク時にフィックス適用ロジックを実行
MW FIX2
OS
MW
ソフトウェア・バンドル
の追加
OS
構成
OS
MW FIX1
OS
インストール
&リセット
環境依存のない処理までは
インストール・タスクで実施
FIX2
FIX1
NFS
事前にフィックスを配置
35
イメージ1つで
異なる環境を
作成可能
構成タスクのスクリプト
からダウンロード
フィックス毎の仮想イメージ開発
を回避するアプローチを実現
© 2013 IBM Corporation
ICCTでは、カスタマイズ手順が自動化できるのであれば、構成タスクを利用して発展
的な仮想イメージを作成することが可能です。その例を2つご紹介いたします。
例えば、あるミドルウェアにおいて、導入に一番時間がかかるので仮想イメージには事
前に導入しておきたいが、デプロイ時にはフィックス・レベルを指定してデプロイをしたい
という要望があったとします。この場合、フィックス・レベルごとに仮想イメージを作成する
ことも案としてありますが、管理すべき仮想イメージが増加していきますので、徐々に運
用負荷が高まってしまいます。しかし、ICCTを用いて、インストール・タスク時に製品を
導入し、構成タスク時にフィックス・レベルを引数として指定してデプロイ時にNFSサー
バーなどのファイル・サーバーから指定したレベルのフィックスをダウンロードするように
実装すれば、1つの仮想イメージで複数のフィックスの仮想イメージであるかのように使
える仮想イメージを開発することが可能になり、不要に仮想イメージ数を増やすことを避
けられます。
もちろん、スクリプト・パッケージで特定のフィックス・レベルのミドルウェア環境を構成
することも考えられます。スクリプトの実行に関しては、P.32でも申し上げましたように、ス
クリプト・パッケージはシリアル、構成タスクではパラレルに実行される違いがあることを
考慮したうえで、どちらで対応するのがよいかをご検討ください。
35
ICCTでの発展的な仮想イメージ実装例 (2/2)

想定ケース

仮想イメージの作成数は抑えつつ、複数の用途に応じた柔軟なイメージを作成
実装の方針
用途に応じてソフトウェア・バンドルを作成
仮想イメージに対するパーソナリティーを定義

構成タスク時に実行するソフトウェア・バンドルをグループ化
パターン・エディターで利用できるパートを1つの仮想イメージに対し複数定義
用途別にバンドルを用意
MW1
OS
用途毎に別々の
スクリプトを
実行可能
構成
ソフトウェア・バンドルの追加
&パーソナリティーの定義
OS
OS
バンドルに定義された
インストール / リセットのタスクは
全て実行される点に注意
36
MW2
OS
インストール&リセット
MW1
MW2
NFS
構成タスクのスクリプト
から取得し導入
管理対象を増やさずに複数の
目的に応じたイメージ開発が可能
© 2013 IBM Corporation
次に、追加導入するミドルウェアは複数あるので、それらを導入する仮想イメージは用意した
いが、できるだけ管理する仮想イメージを減らしたいという要望があったとします。この場合も
ICCTを用いて要望に合わせた仮想イメージを提供することが可能です。
ICCTでの仮想イメージの作成時にパーソナリティーの仕組みを活用して、ミドルウェアの導
入・設定スクリプトを構成タスクに設定し、実行するスクリプトを分けることで、1つの仮想イメージ
で複数の仮想イメージであるかのようにユーザーに見せることが可能になります。
このようにICCTを利用すれば、1つの仮想イメージで複数の使い分けを定義できるので、管理
すべき仮想イメージを削減するアプローチが取れます。これにより、管理の煩雑性の軽減が見
込めます。
36
カスタマイズした仮想イメージの管理

ICCTの管理コンソールより開発した仮想イメージの一覧を取得可能
カスタマイズの概要を確認可能

イメージに導入されているソフトウェア・バンドルおよび製品情報のリストを表示

何が導入されるか、どのようにカスタマイズしたかのトラッキングが可能
IBM Storage Resource Adapter
が導入されることを示す
PureApp上では管理できない細かな
仮想イメージ情報を管理・閲覧可能
37
© 2013 IBM Corporation
こうして開発・カスタマイズした仮想イメージはICCTの管理コンソールから管理可能で
す。選択した仮想イメージの製品(products)の項目に、この仮想イメージには何が導入
されている(あるいは構成タスク時に導入される)のかが確認可能です。この例では、IBM
Storage Resource Adapterが仮想イメージに対して導入されることを表しています。
また、開発した仮想イメージに対して、ICCT上でその製品をどのソフトウェア・バンドル
で導入したかも確認できます。もし、運用担当者が初回構築時と同様の仮想イメージを
再開発しなければならない場合、開発に使用したソフトウェア・バンドルを確認可能です
ので、それに合わせて同様にバンドルを組み合わせて仮想イメージを開発をするといっ
たことも容易にできます。そのため、ICCTを用いれば、運用引き継ぎ後の仮想イメージ
の再開発に対するスキルセットの懸念は最小限に抑えること期待できます。
37
ICCTの利用に対する考慮点

ICCTでのカスタマイズ可能範囲に対する考慮

ICCT自身に対する運用への考慮

ICCTだけではパターンのカスタマイズ全てを実施することは難しい
スクリプト・パッケージ, 仮想イメージの操作が適するケースもある
（次ページ以降の比較表参照）
運用から見ればICCTは1サーバーに過ぎない
運用要件にしたがった運用を考慮する必要がある
ソフトウェア・バンドルの管理に対する考慮

複数人で開発を進める場合、開発物に対する編集・削除には要注意

誰でもソフトウェア・バンドルの編集・削除が可能なため
バックアップをこまめに取得する、ICCTを複数立てるなどの考慮が必要
ICCTでの開発が常にベストな選択肢ではない
運用面も考慮して必要な機能・ツールを選択
38
© 2013 IBM Corporation
このようにICCTは非常に便利な仮想イメージの開発・管理ツールではあるのですが、
利用に関する考慮点ももちろんございます。
まず、自動化できない操作に関しては、ICCTにおいてはソフトウェア・バンドルが構成
できないこととイコールです。ICCTでの仮想イメージの開発において、イメージの同期
完了後から収集の開始までの間の期間で手動でミドルウェアの導入や設定変更を実施
することは可能です。しかしながら、ICCTの管理から逸脱し他操作になりますので、仮
想イメージのカスタマイズの平準化や追跡がICCTを利用しているにも関わらず難しく
なってしまいます。ICCTを用いる場合は、極力そうした手動でのカスタマイズは考えず、
はじめから全て手動でカスタマイズを実施する予定ならば仮想イメージの各操作で対応
するのが適切です。
また、ICCTはあくまでも1サーバーです。仮想イメージの管理がより柔軟に行える反面、
運用上管理すべきサーバーが増えることにご注意ください。
さらに、ソフトウェア・バンドルの管理に関してですが、複数人でICCTを共有して開発
を行う場合、現時点ではACL設定はICCTで設けられていないため、ICCTにログインで
きるのであれば誰の開発物であろうがロックされていない限り編集・削除できてしまいま
す。このような状況を解決するためにはICCTを人数分立てて管理を分けるなどの考慮
が必要になります。
以上のような考慮事項もあり、ICCTでの開発が常にベストな選択肢とは限りません。
要件に合わせて何をどのようにカスタマイズするのかを整理し、P.39-41に各機能・ツー
ルの比較表を参考情報として記載いたしましたので、こちらを参考に必要とする機能・
ツールを適時選択してカスタマイズしていくことをご検討ください。
38
[Info] スクリプト・パッケージ / 仮想イメージの各操作 / ICCTの比較
スクリプト・パッケージ
仮想イメージの
複製・拡張・収集
ICCT (ソフトウェア・バンドル)
開発の準備
カスタマイズ手順の確立
スクリプトの仕様検討
カスタマイズ手順の確立
カスタマイズ手順の確立
スクリプトの仕様検討
ICCTサーバーの構築（初回）
開発にかかる時間
変更内容に依存
スクリプト開発期間も考慮
変更内容に依存
変更内容に依存
スクリプト開発期間も考慮
ACLの設定
PureAppで設定可
PureAppで設定可
設定不可（2013年4月時点）
比較項目
開発性
再利用性
パターン内のパートに
繰り返し利用可能
カスタムした内容を
繰り返す機能はない
PureAppだけでなく、ICCTが
サポートするクラウドに対し、
バンドルの再利用が可能
必要スキル
スクリプト作成
特になし
スクリプト作成, ICCT操作
実行するスクリプトに依存
本数が多いほど時間は増加
事前に加えた変更分
削減可能
実行する構成タスクの
スクリプトに依存
PureApp
PureApp
ICCTサーバー, PureApp
導入するミドルウェアの
ライセンス管理は要考慮
仮想イメージの開発手順は
細かくドキュメント化する必要
あり
運用担当もICCTスキルが必須
サーバーとしての運用も考慮
デプロイの迅速性
デプロイにかかる
時間
管理の容易性
開発物の管理場所
運用考慮点
39
© 2013 IBM Corporation
39
[Info] スクリプト・パッケージ /仮想イメージの各操作 / ICCTの機能比較 (1/2)
スクリプト・パッケージ
仮想イメージの
複製・拡張・収集
ICCT
(ソフトウェア・バンドル)
Windowsイメージ
の作成
―
―
○
パート作成
―
×
パート数分手作業発生
○
パーソナリティ設定
ディスクの追加
―
○
ストレージ・ボリュームと併用
×
ディスクの拡張
―
○
boot領域以外変更可
×
自動化可能
―
△
拡張後に手動対応が必要
○
インストール・タスクで実装
再利用可
自動化困難
（OS再起動含む）
―
△
毎回手動対応が発生する
△
毎回手動対応が発生する
自動化可能
―
△
拡張後に手動対応
○
インストール・タスクで実装
再利用可
自動化困難
（OS再起動含む）
―
△
毎回手動対応が発生する
△
毎回手動対応が発生する
比較項目
仮想イメージのカスタマイズ
仮想イメージの作成&拡張
仮想イメージ拡張時のOS設定
仮想イメージ拡張時のSW導入・設定
40
© 2013 IBM Corporation
40
[Info] スクリプト・パッケージ /仮想イメージの各操作 / ICCTの機能比較 (2/2)
比較項目
スクリプト・パッケージ
仮想イメージの
複製・拡張・収集
ICCT
(ソフトウェア・バンドル)
パターンのカスタマイズ
パターン・デプロイ時のOS設定変更
自動化可能
○
スクリプトで実装, 再利用可
―
○
構成タスクで実装, 再利用可
自動化困難
（OS再起動含む）
×
拡張 & 収集で実装を
考慮する必要あり
―
△
インストール・タスクで実装を
考慮する必要あり
パターン・デプロイ時のSW導入・設定（仮想マシン内）
自動化可能
○
スクリプトで実装, 再利用可
―
○
スクリプトで実装, 横展開可
自動化困難
（OS再起動含む）
×
拡張 & 収集で実装を
考慮する必要あり
―
△
導入タスクで実装を
考慮する必要あり
パターン・デプロイ時のSW導入・設定（仮想マシン間の連携設定）
41
自動化可能
○
環境変数の活用
―
△
スクリプト実装で対応
自動化困難
×
手動での対応を検討
―
×
手動での対応を検討
© 2013 IBM Corporation
41
まとめ：仮想システムでのパターンのカスタマイズ

仮想システムに関連するカスタマイズ機能&ツールは以下の4種類

スクリプト・パッケージ

アドオン

仮想イメージのカスタマイズ機能
IBM Image Construction and Composition Tool (ICCT)

主に仮想NICおよび仮想ディスクの追加機能を提供
仮想イメージの複製（Clone）, 拡張（Extend）, 収集（Capture）

汎用的なパターンのカスタマイズ機能
仮想イメージのカスタマイズ・ツール
カスタマイズ項目を整理して、適切な機能 or ツールを選択

開発性・デプロイの迅速性・管理の容易性も考慮して適切な機能・ツールを利用

カスタマイズが少ない場合はスクリプト・パッケージのみでの開発がシンプル
細かなカスタマイズが頻繁に必要になる場合はICCTの使用を検討
思い通りのカスタマイズができるように
スクリプト開発スキルも強化しよう！
42
© 2013 IBM Corporation
以上、仮想システムにおけるパターンのカスタマイズについてご説明いたしました。カ
スタマイズにはスクリプト・パッケージ, アドオン, 仮想イメージの複製・拡張・収集操作,
IBM Image Construction and Composition Tool (ICCT)の4種類の機能&ツールが提
供されており、カスタマイズする項目を整理したうえで適切な機能・ツールを選択してパ
ターンのカスタマイズを行うことが重要だということをご説明いたしました。
なお、仮想イメージの複製・拡張・収集操作以外のカスタマイズ機能・ツールは基本的
に導入・設定手順のスクリプト化が求められます。効率よく思い通りのパターンのカスタ
マイズができるようになるためにも、是非ともスクリプトの開発スキルを磨くことを心がけて
いただければと思います。
42
§3. 仮想アプリケーションにおける
パターンのカスタマイズ
43
© 2013 IBM Corporation
続きまして、仮想アプリケーションにおけるパターンのカスタマイズについてご説明い
たします。
43
仮想アプリケーション・パターン
アプリケーションの特性に着目したパターン・モデル
アプリケーションの要件およびシステムに対する非機能要件をもとにパターンを設計
パターンに基づき、推奨・実績のある実行環境をPureAppが速やかに提供
□ アプリケーションの要件
・データベースとの連携
・ユーザー・レジストリーとの連携 etc…
デプロイの対象
Database
AP Srv.
Proxy
DB2
WAS
RHEL
RHEL
ELB
LDAP
RHEL
デプロイ
WAS
TDS
RHEL
RHEL
ELB
RHEL
Cache
WAS
RHEL
□ システムに対する非機能要件
・冗長性
・目標応答時間
etc…
アプリケーションの視点でパターンを作成
WXS
RHEL
共有サービスと連携
推奨・実績ある実行環境を速やかに利用可能
44
© 2013 IBM Corporation
再度、仮想アプリケーション・パターンについてご説明いたします。
仮想アプリケーション・パターンはワークロード視点、すなわちアプリケーションの視点
でシステムを考えた場合に、必要なコンポーネントとアプリケーション実行環境に対する
非機能要件をもとに、システム構成を決定するアプローチのパターン・モデルです。
具体的には、必要とするシステムにはJavaのEARアプリケーションがあり、データベー
スとユーザー・レジストリーをアプリケーションとしては稼働のために必要としています、
アプリケーションを動かすノードに関しては耐障害性を保証するために冗長化します、と
いう情報をもとに、推奨かつ実績のあるEARアプリケーションの実行環境をPureAppか
判断し、速やかにユーザーに提供します。このようなパターン・モデルが仮想アプリケー
ション・パターンです。
仮想アプリケーションのパターンの裏側

OSの設定からミドルウェアの導入までをプラグインの単位で実装
ユーザー視点
パターンの裏側
Baseイメージ
OS
パターンの作成
デプロイ
必要な機能の
プラグインを使用
パターン・インスタンス
45
OSの設定, ミドルウェア
の導入・設定 etc…
© 2013 IBM Corporation
仮想アプリケーション・パターンは、ユーザー視点から見ると、パターンを描いて、デプ
ロイ・アイコンをクリックすればパターンに沿った環境が提供されるという挙動しか見えま
せんが、その裏側を見ると、OSの設定やミドルウェアの導入・設定などの機能レベルで
プラグインと呼ばれる単位で管理されており、ユーザーがデザインしたパターンに対し、
必要な機能に合わせて適切なシステム・プラグインをベースとする仮想イメージに組み
合わせてデプロイすることで、必要なシステム構成を生成するアプローチがとられていま
す。
45
仮想アプリケーション・パターンの開発対象と使えるツール

仮想アプリケーション・パターンでの開発対象

プラグイン
仮想アプリケーションの実装単位
機能別に実装したい内容をJSONファイルあるいはスクリプトで記
載

パターン・タイプ
プラグインの論理セット
JSONファイルで定義を記載

開発で利用できるツール

IBM Workload Plug-in Development Kit (PDK)
仮想マシンのベースとなる仮想イメージは
基本的にBaseイメージを使用するため
仮想イメージの開発は考慮しない
46
© 2013 IBM Corporation
仮想アプリケーション・パターンの裏側をご紹介いたしました通り、仮想アプリケーショ
ンの実装単位はプラグインになります。したがって、カスタマイズを考える場合、開発対
象はプラグイン、ないしはプラグインの論理セットを定義するパターン・タイプとなります。
これらを開発に利用できるツールとしてIBM Workload Plug-in Development Kit(PDK)
と呼ばれますツールが提供されています。
なお、仮想アプリケーションにおいても、仮想システムと同様に仮想マシンのテンプレ
ートとして仮想イメージを利用しています。仮想アプリケーションのシステム要件として、
利用する仮想イメージには指定があり（W1500の場合はIBM OS Image for Red Hat
Linux Systems V2.0, W1700の場合はIBM OS Image for AIX Systems V2.0）、必要
によってそのBaseイメージをカスタマイズすることが許容はされていますが、基本的に
は実施しないため本セッションでは仮想イメージのカスタマイズは考慮しません。
Administering default virtual images for deployments（W1500）
http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.ipas.d
oc%2Fworkloadconsole%2Ft_mngdefaultdep.html
Administering default virtual images for deployments(W1700)
http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.puresy
stems.appsys.1700.doc%2Fworkloadconsole%2Ft_mngdefaultdep.html
46
[Info] プラグインの標準構成
スクリプトとメタ・ファイルの集合体
metadata.json : プラグインのモデル情報を定義
operation.json : デプロイ後の操作を定義
tweak.json : デプロイ後の構成変更対象を定義
パッケージ :
OSの拡張 / ミドルウェアの導入と構成を行うためのスクリプト群
ノード・パートおよびパートのコレクション
ノード・パート：
主に仮想マシンに対する共通設定を実行するためのスクリプト群
OSのファイアウォール設定や管理エージェントの導入などで使用
パート：
ミドルウェアの導入・設定などを実行するためのスクリプト群
ロールの状態に応じて実行するライフサイクル・スクリプトを含む
Velocity Macroテンプレート :
仮想マシンの構成の雛形を定
義
config.json: 所属するパターン・タイプおよびパッケージ情報を定
義
例) WAS プラグインの構成
47
monitoring_ui.json:
PureApp上でモニターする項目を定義
© 2013 IBM Corporation
開発対象のシステム・プラグインですが、標準的には上記のような構成になっています。
決めうちのディレクトリ構造で、予め用途が決まっているメタ・ファイルと実際にOSの設
定を変更したり、ミドルウェアの導入・設定を行ったりするスクリプトを含んだパッケージ
でシステム・プラグインは構成されます。
開発者は追加したい機能に応じて必要なファイルを編集し、システム・プラグインを作
成して機能追加していく流れで開発を行うことになります。
47
[Info] 仮想アプリケーションの実行の流れ(概略)
仮想アプリケーション・ビルダーでのパターン作成
パターン作成
パターンのデプロイ
Velocity Macro
テンプレート
モデル情報
metadata.json
パターン定義情報
カーネル・サービス
の拡張クラス config.json
変換の定義
運用
パッケージ
monitoring_ui.json
モニター
カーネル・サービス
によるトポロジー変換
：プラグインとして開発が必要なもの
topology.json
設定変更
deployment.json
状態を記録
プロビジョニング開始
パッケージの取得
スクリプトの実行
・・・
トポロジー変換でデプロイ
に必要な情報を構成
operation.json
tweak.json
パッケージ情報
VM定義情報
appmodel.json
48
アプリケーション・コンソールでのモニターおよび運用
パターン・インスタンス
© 2013 IBM Corporation
この図は、先ほどのプラグインの標準構成に合わせて、各ファイルがどのようなタイミン
グで読み込まれて利用されているのかを表したものです。図の真ん中にある赤字破線
部分がプラグインを構成する要素になります。しかるタイミングで決められたファイルをイ
ンプットに1つずつステップを踏んでデプロイや運用操作が行われることがポイントとして
挙げられます。
中でもカーネル・サービスによるトポロジー変換が仮想アプリケーションにおいては重
要になり、理解が必要になります。
48
カーネル・サービスによるトポロジー変換とは (1/3)

アプリケーション定義情報からデプロイメントに必要な情報を生成するための
変換サービス
仮想アプリケーション・ビルダー画面
appmodel.json
{
"model": {
"name": "AUTOSCALING TEST1",
"nodes": [
{
"attributes": {
"archive": "artifacts/sample.war",
"ignoreFailedIfix": true
},
"id": "Web Application",
"type": "WAR",
"groups": {}
},
・・・
仮想アプリケーション・ビルダーで作成したパターンは
appmodel.jsonとして保管されている
appmodel.jsonだけではデプロイは困難
デプロイに必要な情報を埋めていく必要がある
49
"links": [
{
"source": "Extra Storage",
"target": "Web Application",
"attributes": {},
"type": "ADDSTORAGE",
"id": "ADDSTORAGE_1",
"groups": {}
}
],
・・・
}
© 2013 IBM Corporation
これから3ページにわたり、仮想アプリケーション・パターンのデプロイの核となるトポロ
ジー変換に関して説明いたします。
ユーザーは仮想アプリケーション・ビルダー画面でパターンを作成しますが、その情報
はappmodel.jsonと呼ばれるJSON形式のファイルで記録されています。このファイルに
パターンの構成要素として選択したコンポーネント, リンク, ポリシーの情報および構成
に必要なパラメーターの情報が含まれます。この時点では仮想マシンのスペックや何の
ミドルウェアをどの仮想マシンに導入すればよいのかの情報は整理されておらず、シス
テム構成が決められない状態です。
49
カーネル・サービスによるトポロジー変換とは（2/3）

appmodel.jsonからデプロイに必要な情報をカーネル・サービスが入力

appmodel.jsonからtopology.jsonが生成され、デプロイ可能な状況になる
topology.json
appmodel.json
ストレージ情報やスケーリ
ング条件などデプロイに必
要な情報が記載
カーネル・サービス
によるトポロジー変換
50
© 2013 IBM Corporation
このappmodel.jsonをインプットとして、デプロイ時にカーネル・サービスによるトポロジ
ー変換を通してtopology.jsonが生成されます。topology.jsonには、仮想マシンのスペ
ック(CPUコア数やメモリー)や追加するストレージ情報、どの仮想マシンにミドルウェアを
導入するかや自動でスケーリングするための条件など、システムをデプロイ・構成する上
で必要な情報がJSON形式で整理されています。このtopology.jsonにしたがい、
PureAppは実際にデプロイを行います。
50
カーネル・サービスによるトポロジー変換とは（3/3）

topology.jsonから生成するインスタンスの情報をカーネル・サービスで生成
環境情報や稼働状況を管理するためのdeployment.jsonが生成される
deployment.json（抜粋）
topology.json
カーネル・サービス
によるトポロジー変換
デプロイ
WAS
RHEL
51
生成されたインスタンス
インスタンスの構成と状態を
deployment.jsonで表現
適時更新が行われる
© 2013 IBM Corporation
PureAppはtopology.jsonから実際にデプロイを行いますが、生成されたパターン・イ
ンスタンスに対し、PureAppはdeployment.jsonと呼ばれるJSON形式のファイルで管
理をします。deployment.jsonには、デプロイでアサインされたIPアドレスの情報や各仮
想マシンのミドルウェアの稼働状況(正確にはミドルウェアに基づくロールの状況)、稼働
時間などが記録され、定期的に更新されています。
このように、PureAppでのデプロイの裏側で、ユーザーが作成したパターンの情報から
カーネル・サービスによるトポロジー変換を通してシステムを生成しています。
51
[Info] トポロジー変換の詳細なステップとカスタマイズ
デプロイメント・ステップ(DS)
カスタマイズ・ポイント（カーネル・サービスのサービス・タイプ）
appmodel.json
V
transform
*.vm
トポロジー断片
merge
未解決トポロジー
config.json
resolve
解決済みトポロジー
TopologyProvider
■ コンポーネント / ポリシー / リンクをトポロジー断片に変換
■ Velocity Macroテンプレート（*.vm）を利用する場合は
TemplateTransformerを指定（デフォルト）
TopologyProcessor
■ マージした未解決トポロジーを書き換え
ServiceProvisioner
■ 共有サービスとの連携に必要な情報をトポロジーに挿入
provision
topology.json
deploy
deployment.json
52
PostProvisioner
■ topology.jsonおよびdeployment.jsonを確認
カスタマイズ要件に応じてどこを
カスタマイズするかを選択© 2013 IBM Corporation
このトポロジー変換の詳細なステップをまとめたフローがこのページになります。カスタ
マイズの要件に応じて必要なステップでカスタマイズを行うことがトポロジー変換に対す
るカスタマイズでのポイントとなります。
以上細かくなりましたが、システム・プラグインの開発においては様々な構成ファイル
やトポロジー変換などの独自の機構が存在し、それらを必要な分だけカスタマイズして
利用する、それが仮想アプリケーションの場合のパターン・カスタマイズとなります。
52
IBM Workload Plug-in Development Kit (PDK)

PureAppで利用可能な仮想アプリケーション・パターンの開発支援ツール

IBM Workload Deployer (IWD), IBM SmartCloud Application Services (SCAS)でも利
用可能

クライアントPCに導入して利用

Java Standard Edition (SE) 6 (32 ビット)の導入が必須
Eclipseで使用するためのパッケージを提供

汎用性の高いEclipseインターフェースと連携し、より快適にプラグインの開発が可能
新規パターンタイプの追加
PDK
・新規にパターンの作成
・既存のパターンの機能拡張
53
新機能の追加
既存パターンタイプ
© 2013 IBM Corporation
こうした仮想アプリケーションの構成単位であるプラグインの開発を支援するツールと
して、IBM Workload Plug-in Development Kit(PDK)が提供されています。PDKは、
既存のパターンのカスタマイズにも利用できますし、仮想アプリケーションの枠組みで新
規に全てを作りこむことにも利用可能です。
このツールはICCTとは違い、クライアントPC側に導入して使用するタイプの開発ツー
ルです。EclipseのプラグインとしてPDKを利用する場合、Eclipse上でプラグインの開
発が可能になります。
53
Eclipse上でPDKが提供する機能
PDKによりディレクトリ構造が補完される
適切なファイルにロジックを追加していく
54
© 2013 IBM Corporation
こちらはEclipse上でPDKを利用する場合の開発画面になります。大きく分けて4つ機
能が提供されております：
①プラグインのスケルトンの生成
②パッケージの構成の視覚的な表示
③ 主要ファイルに対する構成エディターの提供
④ プラグインのビルド
特に③の機能に関して、主要ファイルについてコーディング内容に関して文法チェック
を行う機能も提供されていますので、開発時に非常に役立ちます。
この4つの機能を駆使し、カスタマイズ内容に合わせてプラグイン内の適切なファイル
にロジックを追加していく流れで、PDKでのプラグイン開発を行うことになります。
54
PDKで何が開発できる? / スキルは何が必要?

基本的にあらゆるものを開発可能

ミドルウェアの導入・構成

但し、全ての手順を自動化できることが条件
企業標準のOS設定や監視エージェントの導入・設定
自動スケーリング（水平/垂直スケーリング）の実装

あらゆるミドルウェアに対して自動スケーリングを実装可能
CPU使用率など基本的なOS状態や自作したモニター項目をベースに実装可能
開発に必要とするスキル

Javaスキル

デプロイに必要な仮想マシン情報を決められたフォーマットに書き換えるために必要
主にJSON ArrayやJSONオブジェクトの生成・変換をコーディングするだけ

Pythonスキル

実装したい対象・機能に対する知識

実際にミドルウェアを導入・設定するためのスクリプトの作成のために必要
ミドルウェアの導入・設定など、プラグインの開発に必要なスキルが必要
コーディングを徹底し、インフラを表現思い
通りに自動化できるスキルが必要
55
© 2013 IBM Corporation
「PDKで実際何が開発でき、スキルは何が必要なのか?」、よくそのような質問をいただ
きます。このページでは開発可能対象と必要なスキルセットに関してご説明いたします。
まず、開発可能対象に関してですが、このPDKでは仮想アプリケーション・パターンと
しての仕様に逸脱しない範囲で(*1)、あらゆる機構を作りこみ可能です。自動化ができ
る前提にはなりますが、ミドルウェアの導入・構成や運用監視のためのエージェントの導
入などはもちろんのこと、ミドルウェアとの相性はありますが、自動スケーリングや万が一
の場合のフェールオーバーの挙動など、より発展的な仕組みを組み込むことが可能とな
っております。
また、スキルセットに関してですが、カーネル・サービスにおけるトポロジー変換の作り
こみのためにJavaのスキル、実際のスクリプトを実行するスクリプトの作りこみのための
PythonスクリプトがPDKとして必要となります。あとは、何をしたいか、要件によって実装
したい対象・機能に対する知識が必要になります。
複数の開発言語が必要とはなりますが、PDKに慣れ、知識負荷が低くなってくるにつ
れて、最終的には「実装したい対象・機能に対する知識」および思い通りに自動化(スク
リプト化)できるスキルが重要になってきます。このことを念頭に置いたうえで、デリバリ
ーを行う場合の要員をご検討いただければと思います。
(*1) 例えば、仮想アプリケーションにおいては仮想システムのようなNIC追加の仕組み
は持っておりません。したがって、少なくともデプロイ時に接続したいネットワーク数に合
わせて必要分のNICを追加する操作はPDKではカスタマイズは現時点では行えません
。
55
仮想アプリケーションのカスタマイズ指針と考慮事項（1/2）

必要なものを整理し、必要なものから順々に開発していくことを徹底

ステップ・バイ・ステップでPDKに慣れつつ、開発するのがお勧め

アプリケーション開発と同様、全てを理解してからの開発は十分な期間がかかる恐れがある
カスタマイズの内容に合わせて必要な分だけ理解し、開発していくのが工数削減のポイント
定期的にベースとするパターンの機能を見直すことを忘れずに

リリース毎に徐々に機能が拡充されている
既存パターンの拡張を考慮する場合、機能の重複カスタマイズにならないように調査を実施
機能A～Dの追加
が最終目標
追加機能 B
追加機能 B
追加機能 A
追加機能 A
追加機能 A
提供機能
提供機能
提供機能
パターン提供者
56
追加機能 D
機能C追加
1.0.0.0
1.0.0.1
1.0.0.2
リリース1
リリース2
リリース3
© 2013 IBM Corporation
本セッションではプラグインの細かい実装の考慮事項には踏み入りませんが、仮想ア
プリケーション全体としてのカスタマイズ指針と考慮点をご説明いたします。
まず、プラグインのカスタマイズを行う場合には、リーン・スタートアップを実践し「必要
なものを整理し、必要なものから順々に開発していく」ことを徹底してください。通常の
javaアプリケーションの開発においても、Javaの全てを知っている方はそうはおらず、機
能の開発を行う場合にJavaDocなどを見て少しずつ必要な情報・スキルを集めて開発
を行っていく流れになるかと思います。プラグインの開発に関しても同様で、最初からプ
ラグインについてすべてを理解し開発を行うのは難しく、実際にそれを行うと大幅に時
間を費やしてしまう恐れがあります。したがって、プラグイン開発もアプリケーション開発
と同様、何を実装すればよいのかをきちんと精査したうえで、ステップ・バイ・ステップで
PDKに慣れつつ開発を進めていくのが適切な開発アプローチかと考えます。
また、ベースとなるパターンに関して定期的に機能の確認を行い、開発対象の見直し
を行うようにしてください。仮想アプリケーション・パターンはリリース・アップ時に機能拡
張が行われる場合があります。したがって、ある一時期は機能Cが実装されていない状
況であったとしても、次のリリースではl機能Cが実装されている、という状況は発生する
可能性があります。機能の重複開発を極力避けるためにも、定期的にパターンの持つ
機能を確認するように心掛けてください。
56
仮想アプリケーションのカスタマイズ指針と考慮事項（2/2）

サービス無停止での運用は「ブルー・グリーン・デプロイメント」で実現を考慮

ブルー・グリーン・デプロイメントとは

本番環境を2系統以上並行稼働し、1系統に「機能拡張」された新アプリをデプロイ
フロントエンドの負荷分散装置で新アプリへのアクセスを制御
新アプリが機能的に問題なければ、負荷分散装置でユーザーに開放、別系統も順次更新
機能拡張や自動リカバリー失敗時の復旧には積極的に「デプロイ」で対応
機能追加前の
アプリ実行基盤
パターンで構築
or PureApp外に構築
ELB
EAR
外部DB
接続
Routing
Scaling
外部DB
負荷分散
装置
クラウド・グループ #1
EAR
必要によってデプロイして負
荷分散装置で切り替え
外部DB
外部DB
Routing
ELB
Scaling
クラウド・グループ #2
57
© 2013 IBM Corporation
前ページのように、少しずつパターンとしてのインフラの機能追加を行っていくのはよ
いのですが、要件によってはサービス無停止でそうしたアップデートを行わなくてはなら
ない場合があります。もしサービス無停止でも機能拡張は順次行っていきたい場合は、
「ブルー・グリーン・デプロイメント」が可能な構成をご検討ください。
ブルー・グリーン・デプロイメントはアプリケーションを継続的に更新するためのデプロ
イの手法の1つで、本番系統を複数系設けてフロントエンドの負荷分散装置で
リクエストの制御を行える構成をインフラの前提とし、1系統で新しくビルドしたアプリケー
ションの稼働テストを行い、問題がなければ負荷分散装置で新しいアプリケーションへリ
クエストの送信先をスイッチする、といった操作を行います。こうすることで、万が一のア
プリケーションの更新の際のリスクを最小限に抑え、速やかにアプリケーションの更新を
行うことが可能になりますし、フェールオーバーに関しても容易に実現可能です。
こうしたアプリケーションの継続的デプロイの考え方を仮想アプリケーションの場合は
適用いただくと、柔軟かつサービス停止に強いシステムが構成可能です。デプロイで迅
速に同じ構成のインフラを提供できますので、常時複数系統持つ必要性もPureAppで
はありません。必要に応じて積極的に「デプロイ」で対応できるシステム設計を採用する
ことをご検討ください。
57
§4. まとめ
58
© 2013 IBM Corporation
本セッションのまとめになります。
58
本セッションのまとめ

パターンのカスタマイズに利用する機能および基本的なユースケースの紹介

仮想システム・パターンで利用できる機能&ツール

PureAppが提供する機能
z
z
z

仮想イメージ開発の支援ツール
z

スクリプト・パッケージ
アドオン
仮想イメージの複製（Clone）, 拡張（Extend）, 収集（Capture）
IBM Image Construction and Composition Tool (ICCT)
仮想アプリケーション・パターンで利用できる開発支援ツール

IBM Workload Plug-in Development Kit (PDK)
カスタマイズのために
スクリプト開発スキルも
あわせて磨きましょう!!
機能&ツールを駆使し, お客様に合わせた最適なパターンを提供していきましょう!!
59
© 2013 IBM Corporation
本セッションはパターンのカスタマイズにフォーカスを当てたセッションでした。
本セッションにおいてはパターン・モデル別にカスタマイズで利用できる機能＆ツール
と基本的なユースケースをご紹介いたしました。基本的にパターンのカスタマイズは自
動化が前提であり、スクリプトによる機能開発が求められます。スクリプト開発スキルは
日々磨いていくように心掛けてください。
機能&ツールを駆使して、お客様に合わせた最適なパターンを作って提供していきま
しょう!!
59
参考資料

[1] IBM PureApplication System W1500 / W700 Information Center

[2] IBM Workload Deployer V3.1 Information Center

[3] ワークロード・パターンによる革新的インフラ構築セミナー資料

[4] IBM PureApplication System ハンズオン・セミナー資料

[5] IBM PureApplication Systemにおける仮想イメージのカスタマイズ方法

[6] IBM Workload Deployerは非IBM製品にも対応～Image Construction and Composition
Tool によるカスタム仮想イメージ作成のヒントとベスト・プラクティス～

[7] IBM Image Construction and Composition Toolガイド

[8] developerWorks - 仮想システム・パターンを設計する

[9] Integrated Service Management Library

60
http://pic.dhe.ibm.com/infocenter/psappsys/v1r0m0/index.jsp
http://publib.boulder.ibm.com/infocenter/worlodep/v3r1m0/index.jsp
http://www.ibm.com/developerworks/jp/websphere/library/wca/work_pattern_seminar/
http://www.ibm.com/developerworks/jp/websphere/library/pureapp/pureapp_handson/
http://www.ibm.com/developerworks/jp/websphere/library/pureapp/pattern_customize/
http://www.ibm.com/developerworks/jp/websphere/library/wca/icct_white/
http://www.ibm.com/developerworks/jp/websphere/library/wca/icon_tool_guide/
http://www.ibm.com/developerworks/jp/cloud/library/cl-puresystem-vspdesign/index.html
https://www-304.ibm.com/software/brandcatalog/ismlibrary/search#query=ICCT
© 2013 IBM Corporation
60
ITを、もっと手早くカンタンに。
61
© 2013 IBM Corporation
61
補足資料
62
© 2013 IBM Corporation
62
仮想システムにおけるスクリプトの実行順序

デプロイ時
1.
VMの起動
2.
アクティベーション・スクリプト(パート別)の実行
¾
¾
¾
アドオンの実行
4.
ビルトインのスクリプト・パッケージ (拡張オプション)の実行
5.
スクリプト・パッケージの実行
¾
¾
¾
【NIC追加】 > 【ディスク追加】 > 【NFSマウント】 > 【ユーザーの追加】の順に実行
拡張オプションで指定された機能に対するビルトインの構成スクリプトが実行
実行タイプが【仮想システムの作成時】, 【仮想システムの作成時および開始時】の場合に実行可能
実行順序を設定可能, シリアルに実行される
稼働中
1.
スクリプト・パッケージの実行
¾

パート別にビルトインの構成スクリプトが実行
ICCTで追加した構成スクリプトもこの時点で実行される
3.
¾

定義あるいはデプロイ時に指定したリソース(CPUコア数, メモリー, ディスク・サイズ)でVMを起動
実行タイプが【開始時】, 【仮想システムの作成時および開始時】の場合に何度でも実行可能
削除時
1.
スクリプト・パッケージの実行
¾
実行タイプが【仮想システムの削除時】
スクリプトの実行順序は重要
実行されるタイミングの把握が必要
63
© 2013 IBM Corporation
63
スクリプト・パッケージ
関連の補足資料
64
© 2013 IBM Corporation
64
スクリプト・パッケージ固有の実装(1/3)： cbscript.json

name : パッケージ名(1024字以内)

log:

timeout:

type:

デフォルト： /tmp (Linux/AIX), C:¥temp (Windows)
ディレクトリか、ファイルで指定
実行タイムアウト値
デフォルト：60000000 (1000分)
0はタイムアウトなしを表す
実行モード
0: create , 1: delete, 2: manually, 3: create + manually
デフォルト： 0
ostype:

“name”:
“name”: “Test
“Test Package",
Package",
"description":
"description": "This
"This is
is aa test
test script
script package",
package",
"version":
"version": "1.0.0",
"1.0.0",
"command":
"/bin/sh
/tmp/Test/test.sh",
"command": "/bin/sh /tmp/Test/test.sh",
"location":
"location": "/tmp/Test",
"/tmp/Test",
"log":
"log": "/tmp/Test/trace.out",
"/tmp/Test/trace.out",
"timeout":
"timeout": "0",
"0",
″execmode″:
″execmode″: “0”,
“0”,
"commandargs":
"commandargs": "-arg01
"-arg01 ${param01}
${param01} -arg02
-arg02 ${param02}",
${param02}",
"ostype":
"linux/unix",
"ostype": "linux/unix",
"type":
"APPLICATION",
"type": "APPLICATION",
"keys":[
"keys":[
{{
"scriptkey":
"scriptkey": "param01",
"param01",
"scriptvalue":
"scriptvalue": "",
"",
"scriptdefaultvalue":
"scriptdefaultvalue": "Input
"Input string
string value",
value",
"locked":
“F“
"locked": “F“
},{
},{
"scriptkey":
"scriptkey": "param02",
"param02",
"scriptvalue":
"scriptvalue": "",
"",
"scriptdefaultvalue":
"scriptdefaultvalue": "Input
"Input your
your password",
password",
"type":
"type": "password",
"password",
"locked":
"locked": "T“
"T“
}}
]]
ログの出力先(4098字内)
execmode:

{{
コンソール上のパッケージ名と連動しない
description: パッケージの概要(1024字以内)
version: パッケージのバージョン
command: 実行コマンド(4098字以内)
location: 展開場所 (4098字内)

スクリプトがサポートするOSタイプ
linux/unix, windows, both
デフォルト: linux/unix
スクリプト・パッケージのタイプ
APPLICATIONのみ指定可能
commandargs: 実行コマンドの引数(4098字以内)
keys: ユーザー定義の変数（次ページ）
Update
}}
表記の仕方は決めうちなので
容易に作成可能
65
© 2013 IBM Corporation
65
スクリプト・パッケージ固有の実装(1/3)： keysのプロパティー

scriptkey
{{
“name”:
“name”: “Test
“Test Package",
Package",
・・・
・・・
"keys":[
"keys":[
{{
"scriptkey":
"scriptkey": "param01",
"param01",
"scriptvalue":
"scriptvalue": "",
"",
"scriptdefaultvalue":
"scriptdefaultvalue": "Input
"Input string
string value",
value",
"locked":
"locked": “F“
“F“
},{
},{
"scriptkey":
"scriptkey": "param02",
"param02",
"scriptvalue":
"scriptvalue": "",
"",
"scriptdefaultvalue":
"scriptdefaultvalue": "Input
"Input your
your password",
password",
"type":
"type": "password",
"password",
"locked":
"locked": "T“
"T“
}}
]]
環境変数名を指定
必ず指定

scriptvalue

scriptkeyに合わせて必ず指定
IWD/IPASでは現在使用されない

scriptdefaultvalue

type :

scriptkeyに対しデフォルトとなる値を指定
値のタイプを指定
指定できるタイプは以下の通り
string (default)
integer
positiveinteger
password
locked :
デプロイ時に環境変数を変更できるか否かを指定
デフォルト： F (変更可能)
F(変更可能)またはT(変更不可)を指定

}}

必要に応じてcbscript.jsonと同じディレクトリに配置
キー項目は現時点で以下の2種類

envonly

{
"envonly": "true“
},
{
false (書き込み可, default), True (書き込み不可)
"savevars": "1“
savevars

},
{
デプロイ後のスクリプトの変数値の変更を追従するか
否かを指定
以下の値を指定可
z

[
変数を/etc/virtualimage.propertiesに記録するか
否かを指定
以下の値を指定可
z

"product_license": {
"productid": "5725A26",
"licensetype": "SERVER",
"licensecpu": "16",
"licensememory": "4“
}
1 (保持しない, デフォルト), 0 (保持する)
product_license

スクリプト・パッケージで導入する製品のライセンス
情報を指定
PureAppはその情報をもとにライセンス情報を追跡可能
以下のプロパティーを指定可
z
z
67
New
}
]
productid, licensetype
licensecpu, licensememory(lisencetypeが“SERVER”の場合のみ)
© 2013 IBM Corporation
67
スクリプト・パッケージ固有の実装(2/3)：仮想マシン間の連携

デプロイ時に決まる環境情報（ホスト名等）を変数として指定可能
例 ) WAS側でDB2のホスト名を変数にスクリプトを実行したい場合
パターン・ビルダー画面
2
プロパティーの設定
スクリプト・パッケージの
編集アイコンをクリック
1
${part-name.property-name}で指定
パート名の取得
part-name = DB2_ESE
パートの編集アイコン
をクリック
68
予約されたプロパティー値
（環境変数）を有効に活用
© 2013 IBM Corporation
68
[Info] スクリプト・パッケージで利用できる環境変数

事前に決められた環境変数名を指定することで、デプロイ時の値を取得可能
Hypervisor Editionにより固有の環境変数が存在
指定できる環境変数の一覧は以下のリンクを参照

http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp?topic=%2Fcom.ibm.ipas.doc%2Fiwd%2Fpcr_envivari.html
WebShere Application Server Hypervisor Editionで指定できる環境変数一覧
（抜粋）デフォルト値
サービス名
環境変数名
69
WebSphere Cell Name
CELL_NAME
CloudBurstCell
WebSphere Default Profile location
WAS_PROFILE_ROOT
/opt/IBM/WebSphere/Profiles/DefaultAppSrv01
WebSphere Install Root
WAS_INSTALL_ROOT
/opt/IBM/WebSphere/AppServer
WebSphere Profile Root
PROFILE_ROOT
/opt/IBM/WebSphere/Profiles
WebSphere Hostname
HOSTNAME
WebSphere Node Name
NODE_NAME
CloudBurstNode
WebSphere Profile Name
PROFILE_NAME
DefaultAppSrv01
WebSphere Administrative Password
WAS_PASSWORD
Password
WebSphere Administrative Username
WAS_USERNAME
Virtuser
© 2013 IBM Corporation
69
スクリプト・パッケージ固有の実装(3/3)：オーダー(実行順)

パターン・ビルダー上でスクリプト・パッケージのオーダー(実行順)を変更可能
実行タイプが「仮想システムの作成時」に該当するもののみ
スクリプト・パッケージはオーダー順にシリアルに実行

上から順に実行
時間がかかるスクリプトが多い場合は要注意
70
© 2013 IBM Corporation
70
スクリプト・パッケージの開発の流れ
Step1. 実行したいスクリプトの作成
*.sh
■ 実際に実行したいスクリプトの作成を実施
Step2. cbscript.json/extendedattributes.jsonの作成
■ 実行するスクリプトの実行条件を記載
cbscript.json
Step3. パッケージング
■ 実行スクリプト、関連ファイルをまとめて.zip or .tgz(.tar.gz)ファイルに格納
Step4. スクリプト・パッケージの定義
■ ワークロード・コンソール上でスクリプト・パッケージを定義
Step5. zipファイルのアップロード
■ Step 3で作成したパッケージをアップロード
cbscript.jsonの作成が
スクリプト・パッケージ固有
71
© 2013 IBM Corporation
71
スクリプト・パッケージでの実装の考慮点

パッケージ（.zip, .tgzファイル）の最大サイズとアップロード方法

アーカイブ形式とサイズによりアップロード方法に制限が発生するため注意
アーカイブ形式
.zip
.tgz (.tar.gz)

それ以外の戻り値はエラーと判断されるため注意
スクリプト・パッケージはrootユーザーで実行される

別ユーザーで実行する必要のあるものはsuコマンドを利用して実行させる

例） su - virtuser -c <実行スクリプト名>
Linux/AIX用のシェル・スクリプトを書くときは、改行コードをLFにする

72
サイズ制限(コマンドライン)
4GB
(無制限)
スクリプト・パッケージの実行スクリプトの正常終了の際の戻り値は0

サイズ制限(Webブラウザ)
2GB
-
Windows標準のCR+LFではエラーになるため、注意
© 2013 IBM Corporation
72
ICCT関連の補足資料
73
© 2013 IBM Corporation
73
ICCTでの標準的な開発の流れ
Step1. 実行したいスクリプトの作成
*.sh
■ インストール / リセット / 構成タスク時に実行するスクリプトを作成
Step2. ソフトウェア・バンドルのビルド
■ ICCTコンソール上でソフトウェア・バンドルの定義を作成し、設定作業を実施
Step3. 仮想イメージの選択と編集
■ 拡張したい仮想イメージを選択し、使用するバンドルの選択など、イメージ編集作業を実施
Step4. 仮想イメージの同期処理（Synchronize）
■ 仮想イメージの同期処理を実施し、生成した仮想マシンに対しインストール・タスクを実行
Step5. 仮想イメージの収集処理（Capture）
■ 生成した仮想マシンに対して、リセット・タスクを実行し、仮想イメージ化
Step6. 拡張したイメージを用いてパターンの作成・デプロイ
■ デプロイ時に構成タスクを実行
74
具体的な手順は
参考資料[5]を参照
© 2013 IBM Corporation
74
パーソナリティーの設定(1/3)

追加したいソフトウェア・バンドルが登録されていることを確認

必要情報を入力し、利用したいソフトウェア・バンドルを選択
パーソナリティー名(=パート名)を指定
パートの数量設定
の可否を定義
使用するバンドルを選択

パーソナリティーが追加されていることを確認

必要に応じて他のパーソナリティーを定義

パターン・エディター時に使用できるパートの表示形式が変更される

インスタンス・カウントの選択を使用可能に設定

動的インスタンス・カウントを使用可能に設定

78
パターンエディター時に数量を変更可能にする
「インスタンスカウントの選択を使用可能に設定」が設定されていることが前提
デプロイ後に特定のパートに対する仮想マシン台数の変更を可能にする
© 2013 IBM Corporation
78
PDK関連の補足資料
79
© 2013 IBM Corporation
79
PDKでのパターン・カスタマイズの標準的な流れ
Step1. パターンの開発方針の検討
■ 新規にパターンを開発するのか、既存のパターンのカスタマイズかを選択
Step2. パターン・タイプの開発（存在しない場合に開発）
■作成する予定のプラグインが所属するパターン・タイプを作成
Step3. プラグインの開発
■ 作成・カスタマイズしたいパターンに必要なプラグインを作成
Step3-1：プラグイン構成の定義
Step3-3：ノード・パート/パートの作成
Step3-2：カーネル・サービスの定義
Step3-4：運用機能の定義
Step4. ビルドおよび実機へのアップロード
■ 開発したプラグイン/パターン・タイプをビルドし、実機にアップロード
Step5. パターンのデプロイおよび動作確認
■開発したプラグイン / パターン・タイプをもとにデプロイを実施し、動作確認
80
参考資料[3]を参照
© 2013 IBM Corporation
80
デプロイ時のスクリプトの実行の流れ(1/2)
0config.sh + exec_vm_tmpl.pyの実行
：作りこみ不要
：ノード・パート利用時
必ず作成
□ トポロジー・ドキュメント(topology.json)の解析
”packages”に指定されているノード・パートを特定
：ノード・パート利用時
必要あれば作成
□ 導入されるノード・パート(.tgz)のダウンロードと展開
setup/setup.pyの実行
setup/setup.pyの実行
setup/setup.pyの実行
□ 導入されるノード・パートの数だけ実行
common/install/
{N}_{name}.pyの実行
0_{name}.py
スロット0
･･･
9_{name}.py
スロット9
□ 存在する場合、スロット番号順に実行
common/start/
{N}_{name}.pyの実行
0_{name}.py
スロット0
･･･
8_{name}.py
スロット8
□ 存在する場合、スロット番号順に実行
maestroエージェント起動 (common/start/9_agent.sh)
81
© 2013 IBM Corporation
81
デプロイ時のスクリプトの実行の流れ(2/2)
maestroエージェント起動 (common/start/9_agent.sh)
□ トポロジー・ドキュメント(topology.json)の解析
”packages”に指定されているパートを特定
□ パート(.tgz)のダウンロードと展開（昇順）
setup/setup.pyの実行
setup/setup.pyの実行
install.pyの実行
：作りこみ不要
：パート利用時
必ず作成
：パート利用時
必要あれば作成
□ ダウンロード&展開された順に実行
□ ロール別にライフサイクル・スクリプトを実行
scripts/{role}/install.pyの実行
scripts/{role}/configure.pyの実行
scripts/{role}/{dep}/install.pyの実行
scripts/{role}/{dep}/install.pyの実行
scripts/{role}/{dep}/configure.pyの実行
scripts/{role}/{dep}/configure.pyの実行
scripts/{role}/start.pyの実行
scripts/{role}/{dep}/changed.pyの実行
scripts/{role}/{dep}/changed.pyの実行
scripts/{role}/changed.pyの実行
※ {role}と{dep}の状態が”RUNNING”の場合に実行
｛dep｝がロールの拡張の場合は実行されない
82
{role}: ロール名, {dep}: 依存ロール名
© 2013 IBM Corporation
82