| Oracle® Fusion Middleware Oracle Virtual Assembly Builderアプリケーションおよびイントロスペクション・プラグインの開発 12c (12.1.2) E47992-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Virtual Assembly Builderアプリケーションおよびイントロスペクション・プラグインの開発 12c (12.1.2) E47992-01 |
|
前 |
次 |
次の項で具体的に説明します。
開発者はOracle Virtual Assembly Builderを使用してイントロスペクタ・プラグインを作成できます。
参照ホストの状態を取得するプロセスはイントロスぺクションから始まります。プラグインは参照ソフトウェアのインストールのデハイドレーションを実行することでイントロスぺクションに関与します。デハイドレーションの出力は参照インストールを説明するメタデータです。
後からターゲット環境でソフトウェア・アプライアンスを仮想マシンとしてインスタンス化することはデプロイメントとして知られています。プラグインは実行中の仮想マシンのコンテキストで参照ソフトウェアのリハイドレーションを実行することでデプロイメントに関与します。デハイドレーション時に記録されたメタデータはリハイドレーション時にプラグインで使用できます。
プラグインはサポートする製品とともにパッケージ化された.jarファイルとして実装されます。プラグインは実行時に動的プラグイン検出プロセスを通じてOracle Virtual Assembly Builder環境に入ります。検出後、Oracle Virtual Assembly Builder製品フレームワークはプラグインのデハイドレーションとリハイドレーションのエントリ・ポイントが適切な時間と場所、つまりデハイドレーションの場合はイントロスぺクション時に参照ホスト上で、リハイドレーションの場合はデプロイメントの終盤に実行中の仮想マシンの中で呼び出されるように調整します。
イントロスペクタ・プラグインの設計と実装を開始するには、最初に実行しなければならないことがあります。
イントロスペクタの名前を選択します。イントロスペクタ・プラグインのjarファイルはOracle Virtual Assembly Builderソフトウェア・インストール・ディレクトリ・ツリー内のプラグインごとに専用のサブディレクトリに格納されています。これらのサブディレクトリはプラグイン名に従って命名されるため、各プラグイン名は一意である必要があります。イントロスぺクションが実行される製品に関連する名前を選択します。これによってプラグインのユーザーがそれを呼び出す方法を見分けやすくします。プラグインの名前を使用して製品にイントロスぺクションを実行するためのCLIコマンド名が作成されます。コマンド名はintrospect<plug-in name>の形式で構成されます。GUIではイントロスぺクションを実行可能なコンポーネント・タイプのリストにプラグイン名が「そのまま」表示されます。
プラグインまたは既存のプラグインの拡張機能のいずれを記述するかを決定します。製品をOracle Virtual Assembly Builderプラグインが既存の別の製品(WLSなど)の上で実行する場合、そのプラグインへの拡張機能を記述した方が効率的な場合があります。
異なるバージョンの製品でイントロスぺクションを実行するプランを考えます。これはインスペクタ・プラグインに対して選択する名前に影響します。2つの明確に異なる方針があり、どちらか一方が他方より効果的な場合があります。方針の1つは単一のプラグインで異なる製品バージョンに一括してイントロスぺクションを実行するというものです。これはサポートされている製品バージョンの構成データが同様の場合に便利なことがあります。"foo"と呼ばれる製品の場合、イントロスペクタ・プラグインに"foo"と命名でき、プラグインは製品バージョン(バージョン1またはバージョン2)を検出し、そのバージョンに適した処理を実行します。
代替として、製品バージョンが非常に異なりイントロスペクタ・コードを完全に個別に保持した方が便利な場合には、それぞれ単一の製品バージョンに対してのみイントロスぺクションを実行できる"foo1"と"foo2"という名前の2つのプラグインを記述できます。この場合、ネットワーク内のどこかに両方の製品バージョンがインストールされている顧客は単一のOracle Virtual Assembly Builderインスタンスに両方のイントロスペクタ・プラグインを配置できますが、どの製品バージョンにイントロスぺクションを実行するかを顧客が認識している必要があります。Oracle Virtual Assembly Builderのクラスロード・スキームに起因して、異なるバージョンのプラグインには異なるパッケージ名を使用する必要がある点に注意してください。
イントロスペクタ・プラグインのコードの記述を開始する際には、第6章「イントロスぺクション・プラグインの開発」と第7章「イントロスぺクション・プラグイン・モジュール参照」を参照してください。これらの章にはチュートリアル・コード・サンプルが含まれ、共通するプラグイン操作の説明と、Oracle Virtual Assembly Builderイントロスぺクション・フレームワーク内のモジュールへの参照が記載されています。チュートリアルに目を通しサンプルコードをコピーしてOracle Virtual Assembly Builderによって呼び出し可能で、製品固有のコードを追加できるプラグインを生成できます。
イントロスペクタ・プラグインはイントロスペクタ・マネージャによって編成されます。それはイントロスペクタ・フレームワークのコアで、すべてのプラグインのコントローラとして動作します。イントロスペクタ・マネージャはユーザー・インタフェース(Studio GUIおよびコマンド・ライン・ユーティリティabctl)とプラグインの間に配置されたレイヤーです。すべてのプラグインを追跡しプラグインのデハイドレーションおよびリハイドレーションのメソッドを呼び出します。
可変のプラグイン・セットの場合があるため、使用可能なプラグインの正確なセットをイントロスペクタ・マネージャに通知するためのメカニズムが必要です。これはSPIFと呼ばれOracle Virtual Assembly Builderによって提供されているサービス・モデルを使用して実現されます。イントロスペクタ・マネージャに新しいプラグインを認識させるには、それをイントロスペクタ・プラグイン・サービスとして登録する必要があるのみです。この登録の実行方法の詳細は、第6章「イントロスぺクション・プラグインの開発」で説明されています。プラグインが登録されると、後はイントロスペクタ・フレームワークによって処理されます。
Oracle Virtual Assembly Builderを使用して、プラグインとの相互作用をトリガーするプロセスは次のとおりです。
OVABユーザーがイントロスぺクションを開始し、イントロスぺクションを実行する製品コンポーネントのタイプ、コンポーネントが存在しているホストおよびパスワード、ディレクトリ・パス、ユーザー名などの製品の構成データを取得するため必要な情報を指定します。
プラグインに適したIntrospectorPluginLocatorが検索され、より新しいバージョンのプラグインが参照ホストに存在してるかどうか判別するために使用されます。より新しいバージョンのプラグインが存在する場合は、ユーザーがイントロスぺクションを実行する前にアップグレードする必要があります。
より新しいバージョンのプラグインが見つからなかった場合は、プラグインのDehydrator.dehydrate()メソッドが呼び出され、ローカルまたはリモート・ホストのいずれかでユーザーによて指定されたとおりに実行されます。デハイドレータは主要な構成情報を取得しOracle Virtual Assembly Builderメタデータを作成します。メタデータはイントロスぺクションが実行されたシステムからコピーする必要のある製品実行可能ファイル、データおよび構成を示し、ファイル・セット定義の観点からそれらを記述します。
Oracle Virtual Assembly Builderフレームワークはイントロスペクタ・プラグインのファイル・セット定義から作成するファイル・セットを取得します。デフォルトでは、これはイントロスぺクションの完了直後に実行されますが、ユーザーの必要に応じてそれ以降に延期できます。
OVABユーザーはイントロスぺクションが実行された各種コンポーネント(メタデータ内にアプライアンスまたは原子性アセンブリとして現れる)からアセンブリを作成し、ネットワーク接続の観点から互いの関係を記述します。ユーザーはこの時点で他の構成パラメータも同様に編集できます。
OVABユーザーはVMシステム・ベース・イメージを持つアセンブリ内でアプライアンスのファイル・セットを組み合せるデプロイ可能なVMテンプレートを作成します。これらのテンプレートと、デプロイメントに必要なアセンブリ・メタデータおよびOracle Virtual Assembly Builderビット(イントロスペクタ・プラグインを含む)は、その後、1つのアセンブリ・アーカイブに(.ovaファイル)に組み合されます。
OVABユーザーはデプロイメント・プランを作成します。デプロイメント・プランは、編集可能なメタデータを上書きするために使用できます。また、デプロイメントに使用されるターゲットOVM環境のネットワーク構成を指定するためにも使用されます。
デプロイメント時には、VMがアプライアンスごとにインスタンス化され、イントロスペクタ・プラグインのRehydrator.rehydrate()メソッドが実行されます。プラグインは、保存されたメタデータの状態を、変更したネットワーク接続や新しいホスト名などでVM環境に適した製品構成に変換することで、コンポーネントのリハイドレーションを実行します。rehydrate()メソッドの完了後、Rehydrator.start()メソッドが呼び出されます。start()メソッドはコンポーネントを起動するために必要なアクションを実行します。
アセンブリはデプロイ後は一体として停止および起動でき、スケーラブルなアプライアンスはスケール・アップまたはスケール・ダウンできます。
イントロスペクタ・プラグインは、参照ホストからの製品の取得(デハイドレーション)とその製品の仮想アプライアンスとしてのデプロイメント(リハイドレーション)の両方に関与しています。各プラグインは参照ホスト上の製品の構成を調べ、仮想システムへの製品のデプロイを可能にするために十分なデータを取得します。リハイドレーション時には、製品が新しいホスト上で動作し、ユーザーが指定したすべての構成のオーバーライドが適用されるように製品の構成を修正する必要があります。
プラグインは、コンポーネントにイントロスぺクションを実行している間にユーザーによって入力されたパラメータを指定できます。これらのパラメータは、abctlの使用時にコマンド・ライン・オプションとして、またはGUI内のテキスト・フィールド・エントリとして表示されます。様々なジョブ・パラメータ・タイプとそれらがユーザーに対してどのように表示されるかの詳細は、第6章「イントロスぺクション・プラグインの開発」のジョブ・パラメータのチュートリアルを参照してください。
パスワード・タイプのジョブ・パラメータはセキュリティ上の理由から他のパラメータ・タイプとは異なる方法でabctlによって処理される点に注意してください。コマンド・ラインにクリア・テキストで表示されるようなパスワードのユーザー入力ではなく、プラグインまたは拡張機能が値を要求するときにユーザーにパスワードの入力が求められます。
デハイドレーションは指定された製品の関連する構成情報をメタデータとファイル・セット定義で取得するプロセスです。「関連」の定義は製品固有で、再構成はOracle Enterprise Managerの領域であるため、ユーザーがイントロスぺクションが実行された参照システムからデプロイ済仮想システムまでシステムを完全に再構成できるように考えられるすべての構成要素を取得する必要はありません。デハイドレーション・プロセスでは、ユーザーがあるシステムから別のシステムに変更すると予想される構成の重要な部分についてのみ十分な情報を取得する必要しかありません。たとえば、製品にパスワードがある場合、新しいシステムをデプロイする前にユーザーがパスワードを変更できるようにしておくと賢明です。
ファイル・セット定義に指定された製品のインストール・パスは参照ホスト上に存続するためデプロイ済VM上でも同じままです。そのため、プラグインはパスの修正を行う必要はなく、カスタマイズのためにファイル・セット・パスをユーザーに公開しないでください。
プラグインはデハイドレータ実装を提供する必要があります。Dehydrator.dehydrate(DehydrateContext context)メソッドはイントロスぺクションの実行中に呼び出されます。このメソッドに渡されたDehydrateContextによってユーザーが指定されたJobParameter値にアクセスできます。また、デハイドレーションの結果となるアプライアンスやアセンブリを作成するために使用されるメソッドもあります。
製品の異なる側面を記述するために使用できる様々なタイプのメタデータがあり、これらについては5.4項「メタデータの概要」で説明されています。
リハイドレーションはデハイドレーションの逆です。リハイドレーションは取得したメタデータを仮想システムに適用するプロセスです。リハイドレーションはデプロイ済仮想サーバー上で発生し、デプロイメントの最終ステップでデプロイヤによって呼び出されます。
プラグインはリハイドレータ実装を提供する必要があります。Rehydrator.rehydrate(RehydrateContext context)メソッドは、プラグインがデプロイメント中に製品を再構成するときに呼び出されます。rehydrate()メソッドに渡されたRehydrateContextによって、デプロイされたアプライアンスに関連付けられたメタデータにアクセスできます。
次のメソッドは特に興味深い場合があります。
RehydrateContext.getTargetAppliance()はターゲット・アプライアンス(デプロイされているアプライアンス)を取得し、プロパティ、入力、出力などにアクセスします。
RehydrateContext.getHostForTargetAppliance()はVMホスト名を取得します。
リハイドレーション時の仮想マシン環境について認識しておくべきことがあります。
ジョブのリハイドレートは常にデプロイ済システム上でrootとして実行します。コピーまたは作成するファイルはすべてroot所有権などが付きます。リハイドレーション時に作成するファイルのユーザーおよびグループの所有権は必要に応じて変更します。
ファイル・セット定義に含まれるファイルは定義に所有者とグループの値が自動的に設定されます。デハイドレーション時にプラグインによって、またはアセンブリの編集時にユーザーによって値が指定されていない場合は、所有者とグループはどちらも'oracle'に設定されます。
ファイル・セット定義に含まれるファイルは、VM上の元の権限を使用して作成されます。
oracle.as.assemblybuilder.introspector.plugin.utilモジュール内のRehydrateUtilsには、コマンドを特定のユーザーとして実行する機能があります。プロセスが適用可能な場所で'oracle'として起動したことを確認します。
プラグイン・コードはリハイドレーション時にアセンブリ内のすべてのメタデータにアクセスできます。RehydrateContext.getAssemblyNavigator()メソッドを使用して、必要なメタデータの検索に役立つAssemblyNavigatorを取得できます。
次の項ではイントロスペクタ・プラグインの開発者が精通しておくべき様々なOracle Virtual Assembly Builderのメタデータの構成について説明しています。Oracle Virtual Assembly Builderメタデータは大半がXMLファイルとして$AB_INSTANCE/catalogディレクトリの下のOracle Virtual Assembly Builderカタログに格納されます。
アプライアンスはイントロスぺクション・プロセスのプライマリ出力です。アプライアンスは(追加の構成ステップの後に)実行中のVMとしてインスタンス化できるメタデータ構成です。アプライアンス・メタデータの一部には、イントロスぺクションが実行されたシステムの製品環境の構成が記述されています。また、アプライアンスはVM上の製品をインスタンス化するために必要な製品構成や他のファイルなどのコンテンツ・リソースにも関連付けできます。この製品データとアプライアンス・メタデータはOracle Virtual Assembly Builderカタログに格納されています。
また、アプライアンスにはリソース要件のセットもあります。たとえば、プラグイン開発者はアプライアンスをインスタンス化するVMのメモリーと使用可能なCPU数が最小限になるように指定できます。
各アプライアンスには、アプライアンスから作成する必要のあるVM数(最小、ターゲット、最大および絶対最大)を示すスケーラビリティ情報もあります。「ターゲット」値はデフォルトによって作成されるアプライアンスのVMインスタンスの初期数です。最小および最大の値はVMインスタンス数の制限で、これらの制限はアプライアンスを含むアセンブリのデプロイ後に実効となります。「絶対最大」値は最大値の上限です。Oracle Virtual Assembly Builderは2000を超える絶対最大をサポートしていません。
また、アプライアンスにはVMのホスト上のネットワーク構成との関係を示すインタフェースと、他のアプリケーションとのネットワーク接続を示す入力と出力もあります。
アプライアンスの作成者がイントロスペクタ・プラグインまたは拡張機能の名前となり、プラグインによっては変更できません。それはアプライアンスに自動的に追加されます。この値はOracle Virtual Assembly Builderフレームワークがアプライアンスを操作するためにどのプラグインを使用するかを決定するために使用されます。
アプライアンスのタイプはデフォルトでプラグインまたは拡張機能の名前になりますが、必要に応じてプラグインによって別の値を指定できます。一般に、同じプラグインが複数のアプライアンス・タイプを作成できる場合に、デフォルトとは異なるタイプを指定すると有意義です。
アセンブリはアプライアンスとサブアセンブリのコンテナで、アセンブリによってそれらの間の接続を維持できます。非原子性アセンブリのみがデプロイメント・プランを保持できるため、トップレベルのアセンブリに含まれる単独のアプライアンスや原子性アセンブリは仮想環境にデプロイできません。(最も簡単なアセンブリには単一のアプライアンスのみが含まれ、そのアセンブリのデプロイメントの結果は単一のアプライアンス・インスタンスまたはVMとなります。)
イントロスペクタ・プラグインによって作成されたアセンブリは原子性アセンブリと呼ばれます。原子性アセンブリにはサブアセンブリは含まれません。Oracle Virtual Assembly Builder Studioでは、ユーザーが原子性アセンブリに影響をもたらすことのある編集操作を制限しています。原子性アセンブリ内でプラグインによって作成されたアプライアンス間の接続はユーザーによって編集できず、原子性アセンブリに対してアプライアンスを追加または削除することもできません。
原子性アセンブリは単位としてデプロイされるため、プラグインによってアセンブリ内に作成されたアプライアンスは適切な場所にネットワーク接続が配備されます。
原子性アセンブリ内のすべてのアプライアンスがファイル・セットを共有する必要があります。これは、イントロスぺクション・プロセスでは1つのホストとのみ接続しファイル・セットを取得するからです。ファイル・セットを共有するアプライアンスは兄弟と呼ばれ、最初のアプライアンスが作成された後、Assembly.createSibling()メソッドを使用して兄弟が原子性アセンブリに追加されます。
たとえば、Oracle WebLogic Serverでは、管理サーバーに管理対象サーバーと同じすべてのファイルが含まれるため、管理サーバーが取得したファイル・セットを必要とする唯一のマシンであり、他のアプライアンスは管理サーバー・アプライアンスの兄弟になることができます。
ただし、製品が個別にファイル・セットを取得する必要のある複数の異なるタイプのアプライアンスで構成されている場合は、原子性アセンブリではなくアプライアンスを生成するプラグインが必要です。複数のプラグインが必要となる場合もあれば、単一のプラグインでこれを実現できる場合もあります。その後、各アプライアンスは取得したファイル・セットを個別に保持できるため、それによってこれらのアプライアンスをすべての必要な接続を備えた適切なアセンブリにアセンブルできます。
プロパティとは、様々なタイプ(文字列、整数、パスワード、ブールおよびファイル参照)の値を格納する名前/値ペアです。他の大半Oracle Virtual Assembly Builderメタデータ構成では、アセンブリ、アプライアンス、入力、出力、インタフェースを含めそれらにプロパティをアタッチできます。
プロパティにはユーザーとシステムの2つのカテゴリがあり、ユーザー・プロパティはOVABユーザーによってオーバーライド可能である一方、システム・プロパティは読取り専用である点が異なります。ユーザー・プロパティの場合はプロパティのタイプを必須としてマークできるかどうかに応じて、初期値を指定できるかどうかが決まります。アセンブリをデプロイするには、事前にそのアセンブリに関連付けられたすべてのメタデータのすべての必須プロパティに値を指定する必要があります。これらの値は、アセンブリの編集時またはデプロイメント・プランを介してアセンブリ・メタデータ内で指定できます。
プロパティは、グループ化するすべてのプロパティの名前に共通の接頭辞を付加することで、プロパティ・グループにソートできます。Oracle Virtual Assembly Builder Studioは、プロパティをユーザーに表示するときのプロパティの編成方法としてグループを使用します。プラグイン・コードでは、グループに関連付けられた名前接頭辞を指定することでプロパティのグループを取得できます。
定義されたグループに属さないプロパティは、グループ・プロパティは共通の接頭辞(ある場合)に基づき、プロパティ名文字列は'.'文字で区切られるという経験則に従ってOracle Virtual Assembly Builder Studio内で表示されます。
"OVAB"、"Ovab"または"ovab"で始まるプロパティ・グループ名は内部使用向けに予約されている点に注意してください。
統合プロパティはアプライアンス・メタデータ内に存在せず、プラグインによって作成されないプロパティです。それらはデプロイメント・プラン内にのみ存在します。たとえば、アプライアンスのVMのホストに使用する必要のある物理マシン数を指定するためにデプロイメント・プラン内でオーバーライドされることのあるcom.oracle.ovab.deployer.anti-affinity-min-serversという名前の統合プロパティがあります。このプロパティはインスタンス化されたアプライアンスのみに関連するため、アプライアンス・メタデータ内には存在しません。
大半のプロパティ・タイプでは、単純にデハイドレーション時にプロパティを作成し、リハイドレーション時にその値を取得します。ただし、パスワード・プロパティとファイル参照プロパティについては補足が必要です。
パスワードは、メタデータがOracle Virtual Assembly Builderカタログのディスクに存続する場合に暗号化されます。リハイドレーション時にパスワード値を取得する場合は、TypedValue.getPasswordValue().getAsChar()メソッドを使用してクリア・テキスト値を取得する必要があります。char[]を取得します。次に示すように、セキュリティの理由からパスワードを使用して実行後すぐに消去する必要があります: Arrays.fill(passwd, (char) 0);
ファイル参照プロパティの値はファイルを指しています。既存のコンテンツ・リソースを指定することで、デハイドレーション時にプラグインによってファイルを提供できます。NULL値も指定できます。プロパティが必須としてマークされプラグインによってNULL値が指定された場合は、ユーザーがデプロイメント・プランを介してファイルを提供する必要があります。
デプロイメント・プランを介してファイル参照タイプのプロパティをオーバーライドするには、ディスクのローカル・ファイルを指定します。このファイルはその後デプロイメント時にVMに送信され、プラグイン・リハイドレーション・コードからアクセス可能となります。
|
注意: ファイル参照プロパティがデプロイメント・プランで表示専用の場合は、アセンブリ編集時にはそれらを表示または編集できません。 |
リハイドレーション時にアクセスするには、プラグインがFileRefプロパティの値を取得し、それを解析してコンテンツ・リソースの名前を見つける必要があります。プロパティ値は"contentresource:<name>"のようなURI値になります。メソッドjava.net.URI.getScheme()およびjava.net.URI.getSchemeSpecificPart()は値の解析に役立つ場合があります。コンテンツ・リソース名が取得されると、コンテンツ・リソースにアクセスするために提供されている通常のSDKメソッドを使用してコンテンツ・リソースにアクセスできます。
Oracle Virtual Assembly Builderは、将来的にFileRefプロパティ・タイプの他のURIスキームをサポートする権利を有しています。プラグイン・コードはこれに対して堅牢です。つまり、対応するコンテンツ・リソースの検索を試行する前に、それがコンテンツ・リソースであることを保証するURIスキームをチェックし、不明なスキームを持つプロパティは無視します。これは特に、プラグインがすべての使用可能なプロパティをスキャンする場合に当てはまります。
入力および出力は、アプライアンスと原子性アセンブリの機能で、アプライアンスまたは原子性アセンブリが使用するネットワーク・エンドポイントを示しています。(データ構造はアプライアンスとアセンブリで多少異なるため、ApplianceInput、AssemblyInput、ApplianceOutput、AssemblyOutputといったクラスがあります。)
入力および出力はイントロスペクタ・プラグインによって作成され、同じアセンブリ内の他のエンドポイントまたは外部リソースのいずれかへ接続するための可能な添付ポイントを示します。たとえば、データベース・アプライアンスにはデータベースが接続をリスニングしているポートを指す入力があり、WLSアプライアンスにはバックエンド・ストレージ用に使用されているホストを指すJDBC出力があります。WLS出力はデータベース入力に接続できます。この接続を介して、デプロイメント時にデータベース・ホストとポートをWLSプラグインに認識させることができるため、JDBC構成を修正できます。
アプライアンスをOracle Virtual Assembly Builder Studioアセンブリ・エディタで表示すると、入力はアプライアンスの左側に垂線付きの円として表示され、出力は右側に垂線付きの円として表示されます。
入力には関連付けられているポート番号があり、これはネットワーク接続と、ポートでサポートされているネットワーク・プロトコルのリストを受け入れるネットワーク・ポート番号です。入力はアプライアンスのネットワーク・インタフェースのいずれかにバインドされます。
入力と出力はどちらもイントロスペクタ・プラグインによってプロパティをアタッチできます。
出力には、出力からの通信に使用される単一のネットワーク・プロトコルが関連付けられます。
出力には必要に応じて接続プロパティ・セットを関連付け、(ある場合は)出力を確実に互換性のある入力に接続させるために使用できます。すべての出力接続プロパティの名前が入力プロパティの名前と一致する場合、入力と出力は互換性があるとみなされます。また、接続プロパティはその出力用に作成された外部リソースの入力プロパティをシードするためにも使用されます。
接続プロパティと入力プロパティはプラグインが生成したメタデータの外面の一部です。他のコンポーネントがアプライアンスとアセンブリへの接続方法を理解できるようにそれらをドキュメント化する必要があります。
接続は出力から入力へのネットワーク接続を表しています。接続に含まれる2つのエンドポイントはアプライアンスまたはアセンブリのいずれかに所属できます。接続がアセンブリとの間の場合、エンドポイントは実際にはアセンブリ内のアプライアンスによって所有されます。
出力がアセンブリ内のアプライアンスによって表されていないネットワーク・リソースを参照している場合、ユーザーはアセンブリ内に外部リソースを作成することでその出力に接続できます。バインドされていないアプライアンス出力は新しい外部リソースの入力に接続するように構成されます。アセンブリをインスタンス化したときに外部リソース用のVMは作成されないため、外部リソースはプレースホルダーのような役割を果たします。それらはアセンブリ内に単独で存在するため、ユーザーはユーザーのネットワーク上に既存のエンティティについて構成情報(ホスト名、ポートなど)を指定できます。
たとえば、多くのOracle製品がLDAPサーバーに依存しています。現在Oracle Virtual Assembly BuilderはLDAPアプライアンスの仮想環境へのデプロイをサポートしていないため、アセンブリ内でLDAPサーバーを表すために外部リソースが使用されます。
コンテンツ・リソースは、プラグインがリハイドレーション時に取得および使用するために、デハイドレーション時にOracle Virtual Assembly Builderカタログに保存されるファイルです。未修正のファイルをイントロスぺクションが実行されたシステムからデプロイ済システム(つまり、配布先ファイル・セット定義)へ転送するためにコンテンツ・リソースを使用しないでください。
コンテンツ・リソースは、、デハイドレーション時にVelocityテンプレート(または類似のもの)に変換され、後からリハイドレーション時にイントロスぺクションを実行したシステム上の元のファイルを変更することなくトークンに置換されるファイルに対して使用するためにあります。
また、コンテンツ・リソースはアセンブリの編集時にユーザーがまとめて更新できるようにするファイルに対しても使用できます。たとえば、ユーザーはカスタムSSL証明書を提供できます。この場合、コンテンツ・リソースをFileRefユーザー・プロパティとして公開する必要があります。そうすることで、ユーザーはデプロイメント時にそのファイルの異なるコピーを追加できます。
コンテンツ・リソースはアプライアンスまたは原子性アセンブリに関連付けることができます。
(これらは以前はパッケージ定義として知られ、PackageDefinitionBuilderクラスを介して作成されていました。)単純な例では、ファイル・セット定義は基本的にイントロスぺクションを実行したシステムからカタログにコピーされたファイルのリストで、後からアプライアンスをインスタンス化するために使用されるテンプレートに組み込まれます。
通常、定義にリストされるファイルは、イントロスぺクションを実行したシステムからカタログにコピーするために、Oracle Virtual Assembly Builderフレームワークによってファイル・セット(旧「パッケージ」)に圧縮(zip)され(取得され)ます。ファイル・セットはテンプレート作成プロセスでVMディスク・イメージに解凍され、ディスク・イメージはアプリケーションのインスタンス化時に実行中のVM上のディレクトリとしてマウントされます。
ファイル・セット定義には、ユーザーとシステムの2つのタイプがあります。ユーザー定義は、完全な削除を含め、ユーザーによって編集できます。システム定義はタイプを共有またはローカルとして選択する以外は編集できません。システム定義は、製品を適切に機能させるために必要なファイルのセットを示すためにあります。
ファイル・セット定義の作成時に除外を指定できます。これらは、指定したルート・ディレクトリの下に存在し、ファイル・セットの取得時に内包させたくないファイルです。除外の典型的な候補は、デプロイ済VMに持ち越しても何の意味もないログ・ファイルです。
除外のセマンティクスを表5-1で説明しています。
表5-1 除外のセマンティクス
| 定義のルートからの相対ディレクトリ | 除外の影響 |
|---|---|
|
some/relative/path/foo |
'foo'ディレクトリ全体を除外します。'foo'ディレクトリはデプロイ済VMには一切存在しません。 |
|
some/relative/path/bar/* |
'bar'ディレクトリの下のすべてのファイルを除外します。空のディレクトリがデプロイ済VMに存在します。 |
|
some/relative/path/logs/*.log |
名前が'.log'で終わるログ・ディレクトリ内のすべてのファイルを除外します。他のファイルは引き続き取得されます。すべてのファイルが削除されても、ログ・ディレクトリは存在します。 |
ファイル・セット定義がサポートするより複雑なシナリオには共有ファイル・セットが関与します。このような場合、VMをインスタンス化した後に共有されるボリュームに対して様々な調整が図られます。ファイル・セットの取得(APIでは「パッケージング」として知られる)は共有ファイル・セットではオプションです。ファイル・セットが作成されない場合、ファイル・セット定義は既存のボリュームまたは空のボリュームを参照することがあります。
共有ファイル・セットがOracle Virtual Assembly Builderフレームワークによって取得された場合、ファイル・システム・タイプはNFSまたはDISK_IMAGEのいずれかになります。NFSの場合には、Oracle Virtual Assembly Builderは、コピーされる一時ディスク・イメージのコンテンツを、すべてのアプライアンスがアクセスできるNFSファイル・システムに配置します。後続のアプライアンス・インスタンスはNFSファイル・システムをマウントするのみです。取得されたNFSファイル・セットはクラスタ化されたアプライアンスのメンバー間でのみ使用できる点に注意してください。取得されたDISK_IMAGEファイル・セットの場合、各アプライアンスは読取り専用ディスクとしてマウントされたファイル・セットのコンテンツを認識できます。これもクラスタ化されたアプライアンスのメンバーのみが使用可能です。
Oracle Virtual Assembly Builderフレームワークによってファイル・セットが取得されテンプレートに追加されていない場合は、既存の共有ボリュームが前提とされ、ファイル・システム・タイプはNFSまたはRAWのいずれかになります。
次に共有ファイル・セットの候補について要約します。
表5-2 共有ファイル・セット(取得済)
| ファイル・システム・タイプ | 共有ルール |
|---|---|
|
NFS |
クラスタ化されたアプライアンスのメンバーによってのみ共有できます。デプロイメント・プランでマウントターゲットによって指定されたVM外部のNFSボリュームは、クラスタ内の最初のアプライアンスがインスタンス化されたときに作成、移入およびマウントされます。後続のクラスタ・メンバーの各インスタンス化では単にこのボリュームをNFSマウントするのみです。 |
|
DISK_IMAGE |
クラスタ化されたアプライアンスのメンバーによってのみ共有できます。指定ファイルを含むボリュームをOracle Virtual Assembly Builderが構成します。OVMがよって各アプライアンスの構成にボリュームを含めます。これらのボリュームは読取り専用です。 |
|
RAW |
使用できません。 |
表5-3 共有ファイル・セット(未取得)
| ファイル・システム・タイプ | 共有ルール |
|---|---|
|
NFS |
デプロイメント・プランのマウントターゲットによって指定された既存のNFSボリュームが各アプライアンスによってマウントされます。 |
|
DISK_IMAGE |
使用しないでください。これは結果として空のまま存続するように指定された読取り専用のボリューム・サイズとなります。これらのいずれかを作成するためのプラグインは不要です。 |
|
RAW |
クラスタ化されたアプライアンスのメンバーによってのみ共有できます。Oracle Virtual Assembly BuilderがLinux RAWデバイスと/devの所有者、グループ、権限およびシンボリック名を構成します。(注意: これはRACデータベース・アプライアンスをサポートするために存在し、他のプラグイン・タイプではほとんど使用されません。) |
各ファイル・セット定義には、ファイル・セットを取得する際にファイルを収集するために再帰的にスキャンされるルート・ディレクトリが含まれます。特にイントロスぺクションを実行したシステムからインスタンス化されたVMへログや一時ファイルなどのファイルをコピーする必要がない場合、ルート・ディレクトリの下にあるファイルはファイル名またはパターンに基づいて除外されます。
原子性アセンブリは、原子性アセンブリ内のすべてのアプライアンスが同じファイル・セットを共有する構成で制限されます。(前述のコンテンツ・リソースは原子性アセンブリ内の各アプライアンス固有です。)
プラグイン拡張機能を使用して、デハイドレーションおよびリハイドレーション操作を既存のプラグインに追加できます。これはある製品が別の製品の上に構築されている場合に役立ちます。基礎の製品の動作を複製するのではなく、基礎のプラグインの実行時の実行にプラグイン拡張機能を追加し、必要に応じて追加のメタデータとロジックを提供できます。
プラグイン拡張機能は次のセマンティクスに従っています。
プラグイン拡張機能は、その親プラグインが実行されると常に実行されます。
プラグイン拡張機能は、デハイドレーション・ジョブの発行時にプラグインが受け取るパラメータ・セットに寄与します。これらの追加パラメータは、プラグインによって指定されたパラメータとともにプラグイン拡張機能に提供されます。
プラグイン拡張機能がデハイドレーション操作を起動するための親プラグインの別名として表示されるように選択できます。基礎のプラグインは常に、それを拡張するすべてのプラグイン拡張機能とともに実行されるため、このことは実行には影響しませんが、ユーザーが個別で追加のイントロスぺクションを選択できるかのように見せる効果があります。
プラグイン拡張機能はプラグインまたは別のプラグイン拡張機能を拡張できます(プラグイン拡張機能の拡張元エンティティは親とみなされます)。
プラグイン拡張機能は常に、その親が実行した後に実行します。
プラグイン拡張機能は直接の親を1つのみ保持できます。
1つのプラグインまたはプラグイン拡張機能は複数の子プラグイン拡張機能を保持できます。
兄弟プラグイン拡張機能は任意の順序で実行します。
プラグイン拡張機能は次の制限に従っています。
プラグイン拡張機能は通常、その親によって実行される動作に依存します。プラグイン拡張機能は多くの場合、親によって提供されるデータを使用し競合するデータを作成しないようにするために、親が何を提供しているかを認識する必要があります。これは、親が変更された場合にプラグイン拡張機能を変更する必要が生じる場合があることを意味しています。
プラグインは、それを拡張元とするプラグイン拡張機能とは独立している必要があります。プラグインにはそれを拡張元とするプラグイン拡張機能へのアクセスは提供されず、プラグイン拡張機能では親の操作を侵害しないよう注意する必要があります。
プラグイン拡張機能は、親プラグインが許可するまでアセンブリまたはアプライアンスを作成できません。プラグイン所有者の同意と慎重な管理なく、プラグイン拡張機能によってアプライアンスまたはアセンブリを作成すると、プラグインまたは他のプラグイン拡張機能によって実行されるそれ以降の操作に影響することがあります。このような同意がない場合は、プラグイン拡張機能はその操作を、プラグインによって作成されたアセンブリとアプライアンスのメタデータに関与する操作のみに制限する必要があります。
プラグイン拡張機能は実行する目的がない場合、つまり拡張機能が処理するコンポーネントがインストールされていない場合には何も実行しないでください。プラグイン拡張機能は常に親プラグインが実行したときに実行されます。つまり、一部の実行には特定のプラグイン拡張機能による動作は必要ありません。これを予測し、何も実行されなかったときにエラーがレポートされないようにするのはプラグイン拡張機能の責任です。これは、デハイドレーション時とリハイドレーション時の両方に当てはまります。
デハイドレーションの実行時に、プラグインは最初にアセンブリ/アプライアンスから構成される出力を使用して実行されます。プラグインが完了すると、次に各プラグイン拡張機能に、ユーザー指定のジョブ・パラメータ・セット全体と、他のプラグイン拡張機能実装によって加えられることのあるすべての変更を含むアセンブリ/アプライアンスの両方が渡されます。各プラグイン拡張機能が、すべての必要な入力パラメータを処理し、製品構成を調べ、プラグイン拡張機能の実行目的があるかどうかを判断する責任を担います。多くのプラグイン拡張機能では実行する処理がない場合に決定後に制御を戻すことが期待されています。
プラグイン拡張機能の実装は、起動、停止、ping、リハイドレートを含むすべてのリハイドレーション操作で親プラグインと一緒に呼び出されます。操作ごとに最初にベース・プラグインが実行されます。プラグインで実行された操作の正常な完了に続いて、対応する操作が各プラグイン拡張機能で順次呼び出されます。各プラグイン拡張機能が、特定の操作の実行中に何かを実行する必要があるかどうかを判断する責任を担っています。
プラグインまたはプラグイン拡張機能のデハイドレーション/リハイドレーション操作中に最初のエラーが発生すると、操作は中断され、追加のプラグイン拡張機能の実行を開始することなくエラーが即座に戻されます。つまり、プラグイン拡張機能の失敗は操作全体の失敗につながります。
プラグイン拡張機能を実装する手順は、実質上プラグインを実装する手順と同じです。主な違いは、プラグイン拡張機能がIntrospectorPluginインタフェースのかわりにIntrospectorPluginExtensionインタフェースを実装する必要がある点です。
IntrospectorPluginExtensionインタフェースには次の3つの追加メソッドがあります。
String getParentName();
プラグイン拡張機能が拡張する親プラグインまたはプラグイン拡張機能の名前を戻します。個々で戻される名前は、既存のプラグインまたは別の既存のプラグイン拡張機能のgetName()から戻される名前と同じである必要があります。
String getParentPluginName();
親プラグインの名前を戻します。プラグインから直接拡張している場合は、getParentName()は同じ値を戻します。
boolean isAlias();
アプリケーションが、可能なイントロスぺクションの選択肢のセットを提供する際に、このプラグイン拡張機能の名前を明確な選択肢として提供できるかどうかを判別します。例: このメソッドがtrueを戻した場合、ユーザーがintrospectXXXを実行したときに、親プラグインの名前が付いたコマンドが実行されたかのように、基礎の親プラグインが通常どおり実行されるにもかかわらず、abctlは個別のintrospectXXXコマンド(XXXはプラグイン拡張機能の名前)を作成します。
これらの各メソッドの詳細は、IntrospectorPluginExtensionに関するJavaDocに記載されています。IntrospectorPluginExtensionの他のすべてのメソッドはIntrospectorPluginのメソッドと同じです。
プラグイン拡張機能ではサービス名としてIntrospectorPlugin.class.getName()ではなくIntrospectorPluginExtension.class.getName()を使用して登録する必要がある点を除き、プラグイン拡張機能をサービスとして登録する方法は、プラグインを登録する方法と同じです。
this.registration = serviceContext.registerService(
IntrospectorPluginExtension.class.getName(), pluginExtension);
プラグインの登録方法の詳細は、第6章「イントロスぺクション・プラグインの開発」を参照してください。
この項では、Oracle Virtual Assembly Builderのサポート・サービスについて説明します。
サービス・プロバイダ・インタフェース・フレームワーク(SPIF)は、Javaクライアントが直接使用できるOSGiに似たインフラストラクチャを提供します。このフレームワークは、カスタム・クラスロード・メカニズム、アプリケーション・サービス、全般的なサービスおよびサービス検出を提供します。SPIFは、SPIと呼ばれるJavaが提供する単純なサービス・モデルの上に構築されています。
Oracle Virtual Assembly BuilderのORACLE_HOMEディレクトリ構造内には、SPIF jarと多数のサブディレクトリを含む'jlib'ディレクトリがあります。'apps'という名前のサブディレクトリはSPIFフレームワークにとって特別な意味を持っています。それには、Oracle Virtual Assembly Builderによって提供されるアプリケーションを定義する追加のサブディレクトリが含まれています。その他のディレクトリは、関連するモジュールをグループ化するために使用できます。これは依存関係をより明瞭にするために実行されますが、よりファイングレインなクラスロードも実現できます。アプリケーションは、クラスのロード元となるこれらのトップ・レベルのjlibディレクトリのリストを指定できます。これらのトップ・レベルのjlibディレクトリのいずれかにサブディレクトリがある場合は、これらも同様にロードされます。たとえば、'packager'ディレクトリを見ると、'plugin'および'plugin'と呼ばれるサブディレクトリに追加のjarファイルがあることがわかります。したがって、'packager'をアプリケーションのディレクトリ・リストに追加すると、アプリケーションはディレクトリ・ツリー内にあるjarファイルもロードします。
SPIFアプリケーションはOracle Virtual Assembly Builderアーキテクチャへのエントリ・ポイントです。プラグイン開発者は、プラグインを実行する各Oracle Virtual Assembly Builderアプリケーションがインストールされているプラグインを自動的にロードすることを理解している必要があります。アプリケーションに必要なその他のjarはspif.propertiesファイルを介して指定されます。
SPIFサービスはプラグインの開発において主要なコンポーネントです。サービス・アクティベータは、サービスの登録と、他のサービス・アクティベータからの登録済サービス・インスタンスの取得の両方に使用されます。
サービスは一部のインタフェースを実装するクラスのインスタンスにすぎません。サービスのコンシューマは実装クラスの名前やそのインスタンス化方法を知っている必要はありません。特定のインタフェースとして登録されたインスタンスがあることを知っていれば、それがどのように作成されたか意識せずに、インスタンスへの参照を取得しそれを使用することができます。
プラグイン開発者として、1つ以上のサービスを開発する必要があります。イントロスぺクション・フレームワークとプラグイン間のインタフェースはoracle.as.assemblybuilder.introspector.plugin.IntrospectorPluginです。このインタフェースはORACLE_HOME/jlib/introspector/oracle.as.assemblybuilder.introspector_0.1.0.jarにあります。第6章「イントロスぺクション・プラグインの開発」のチュートリアル1は、このインタフェースの実装を作成する例と、イントロスぺクション・フレームワークに実装を接続する残りのプロセスを示しています。
サービス・アクティベータの実装は、SPIFのエントリ・ポイントとして使用されます。それはstart()とstop()の両方のメソッドを提供します。単一のjarファイル内で複数のサービス・アクティベータが許容されます。複数のサービス・アクティベータがある場合、それぞれが呼び出されますが、呼出し順序は定義されていません。start()メソッドは、jarの初回ロード時にSPIFアプリケーションが起動される前に呼び出されます。これによりプリケーション・ロジックが呼び出される前にすべてのサービスが登録されるように確保しています。stop()メソッドは、SPIFアプリケーションの停止後、JVMが終了する前に呼び出されます。
サービス・アクティベータのインタフェース名は'oracle.as.assemblybuilder.spif.ServiceActivator'です。それは、'AB_HOME/jlib/oracle.as.assemblybuilder.spif_0.1.0.jar'ファイルにあります。このクラスの実装を呼び出すためには、それが最初にSPIFに接続されている必要があります。これは、jarに'META-INF/services/oracle.as.assemblybuilder.spif.ServiceActivator'という名前のファイルを追加することで実行されます。サービス・アクティベータ・ファイルで、サービス・アクティベータ実装の完全修飾クラス名を追加します。各クラス名はそれぞれ1行とし、最終行を含め各行の終わりに改行を付ける必要があります。
Oracle Virtual Assembly Builderがjarファイルをロードすると、アクティベータがロードされstart()メソッドが呼び出されます。その後、サービス・アクティベータを使用してサービスを登録するか既存のサービスを検索できます。
インタフェースの実装を作成しサービス・アクティベータに関連付けた後に、それをサービスとして登録します。
サービス・アクティベータの開始メソッドで、サービスを提供するクラスのインスタンスを作成します。その後ServiceContextを使用してregisterService()を呼び出し、サービスとインスタンスになるインタフェースの名前を渡します。stop()メソッドでServiceReferenceのunregister()を呼び出せるように、このメソッドから戻されたServiceReferenceを確実に保存します。
次に、サービスを登録し、それを登録解除する例を示します。
public class PluginActivator implements ServiceActivator {
private ServiceRegistration registration = null;
@Override
public void start(ServiceContext serviceContext) throws Exception {
IntrospectorPlugin plug-in = new SamplePlugin();
registration =
serviceContext.registerService(
IntrospectorPlugin.class.getCanonicalName(),
plugin);
}
@Override
public void stop(ServiceContext serviceContext) throws Exception {
if (this.registration != null) {
this.registration.unregister();
}
}
}
SPIFサービス・インスタンスはServiceContextが提供する複数のメソッドとインタフェースを介して取得できます。推奨アプローチは、ServiceContextからコレクタを取得し、そのコレクタを使用して必要なSPIFサービスを追跡する方法です。
ServiceActivator実装がstart()メソッド内からサービスの獲得を試行しない点が重要です。これが実行されない場合、必要なサービスが見つからない可能性があります。各サービス・インスタンスが必要とされるポイントでのみ取得され、start()メソッドよりかなり後に戻されれば理想的です。
コレクタを使用するには、最初にServiceActivatorのstart()メソッドの実行時にコレクタを作成します。
myCollector = serviceContext.createCollector();
このコレクタ・インスタンスは専用のサービス実装に直接渡されるか、サービス取得方法の詳細を隠すためにプラグイン実装で定義されたインタフェースでインスタンスをラップして渡されます。
サービスが必要とされるポイントの近くで、次のコレクタ・メソッドのいずれかが呼び出されます。
SomeService myInstance = myCollector.getSingletonService(SomeService.class);
List<SomeService> myInstances = myCollector.getServices(SomeService.class);
特定のサービスの1つのインスタンスのみが必要な場合は、getSingletonService()を使用します。サービスの1つ以上のインスタンスが登録されている場合は、インスタンスは任意で選択され戻されます。インスタンスが存在しない場合は、エラーがスローされます。
特定のサービスの複数のインスタンスを獲得する必要がある場合は、getServices()を使用します。インスタンスが存在しない場合、戻されるリストは空です。
プラグインにより、Oracle Virtual Assembly Builderの様々なライフサイクル操作の検証コードを提供できます。このコードは他のプラグインと同じjarに組み込んで、IntrospectorPluginと同じServiceActivatorに登録できます。
ファイル・セット取得(以前は「パッケージング」として知られ、SDKではまだそう呼ばれている)のプロセス時に、ファイル・セット定義に記述されているファイルはファイル・セット(旧「パッケージ」)に圧縮されます。これは通常イントロスぺクションが完了した直後に実行されますが、ファイル・セットの初期作成は遅延させることでき、OVABユーザーは後からファイル・セットを再作成するように選択できます。
Oracle Virtual Assembly Builderフレームワークによって、SDKユーザーはファイル・セット取得プロセスの開始時に呼び出され、製品の取得に適した状態を確保することを目的としたプラグインを提供できます。たとえば、ファイル・セット取得を続行する前に製品をシャットダウンする必要がある場合があります。検証プラグインは製品が実行中であることを検出した場合、ファイル・セット取得を中断できます。プラグインはOVABユーザーに対して表示されるエラー・メッセージを提供できます。
詳細は、SDKのPackagerValidationPluginインタフェースの冒頭を参照してください。
PackagerValidationPluginの登録はイントロスぺクタ・プラグインの登録と同じです。PackagerValidationPluginインタフェースの実装はイントロスペクタ・プラグインと同じjarにすることもできれば、同じディレクトリ内に配置された別のjarで配信することもできます。
プラグインではサポート可能なプラットフォームとOSのタイプに制限がある場合があります。Oracle Virtual Assembly Builderフレームワークはアプライアンスにイントロスぺクションが実行された後にこれらの要件を適用する機能があります。検証のJVMはイントロスぺクションのものと異なるため、この検証はアセンブリ・メタデータが提供する以上の状態情報には依存しません。
この機能を使用するには、PlatformOsValidationPluginインタフェースを実装するためのクラスを作成します。このクラスのインストールはイントロスペクタ・クラスのインストールと同様です。イントロスペクタ・プラグインと同じjarまたはプラグイン・ディレクトリ内の専用のjarファイルでクラスを配信できます。
Oracle Virtual Assembly Builderフレームワークはプラグインとそのプラグイン拡張機能に属するすべての実装に対してプラットフォームおよびOS検証を呼び出します。このような各実装が検証のレスポンスを提供し、このレスポンスがコンプライアンスまたは非コンプライアンスを示します。
非コンプライアンスはプラグイン指定のエラー・メッセージとともに警告または拒否として通知できます。拒否が示されていない場合は、すべての警告がユーザーにリレーされます。
Oracle Virtual Assembly Builderフレームワークは、プラグイン開発者がテンプレート作成に使用されるOSベース・イメージがプラグインの製品のニーズを満たしていることを保証するために使用できる機能を備えています。プラグインは、ユーザーおよびグループ・アカウント、ソフトウェア(RPM)パッケージ、カーネル構成パラメータおよびシステム・スワップ領域のチェックを手配できます。
この機能を使用するには、BaseImageValidationPluginインタフェースを実装するクラスを作成します。クラスのインストールはイントロスペクタ・クラスのインストールと同様です。イントロスペクタ・プラグインと同じjarまたはプラグイン・ディレクトリ内の専用のjarファイルでクラスを配信できます。
プラグインは、実行する必要のある検証ごとに、検証を記述したバリデータ・オブジェクトを作成します。Oracle Virtual Assembly Builderフレームワークはテンプレート・プロセス時にバリデータのリストを横断し、提案されたベース・イメージが要件を満たしているかチェックして、満たしていない場合はプラグイン指定の警告またはエラー・メッセージを発行します。
バージョン12.1.2.0.0以降のOracle Virtual Assembly Builderでは、イントロスぺクション・プラグインはOracle Virtual Assembly Builder自体には組み込まれていませんが、かわりにそれらがサポートする製品で提供されインストールされます。プラグインはOracle Virtual Assembly Builderによって検出され、使用するOracle Virtual Assembly Builderインスタンスにインストールされます。これを容易にするために、プラグイン開発者はいくつかの責任を担っています。
プラグインを製品とともに特定の場所にインストールします。
plugin.configファイルを作成し、それをプラグインの側に提供/インストールします。
IntrospectorPluginLocatorサービスを作成し、それをServiceActivatorから登録します(プラグインのServiceActivatorの詳細は第6章「イントロスぺクション・プラグインの開発」に記載されています)。
イントロスぺクション・プラグインまたは拡張機能は次の場所にインストールします。
$ORACLE_HOME/plugins/ovab/introspector/<plugin-name>/*
各プラグインまたは拡張機能は、プラグイン検出、初期インストールおよびアップグレード時に使用するプロパティ・ファイルを提供する必要があります。このファイルは次の場所の各プラグインのディレクトリに存在します。
$ORACLE_HOME/plugins/ovab/introspector/<plug-in name>/plugin.config
plugin.configファイルで次のプロパティを公開する必要があります。
plugin.name
プラグイン/拡張機能の名前で、getName()によって戻されディレクトリ名と同じです。このプラグイン/拡張機能の適用先の製品を示している必要があります。
plugin.version
プラグインのバージョンで、プラグイン実装が変更されると変更されます。このバージョンは程度の差はあれ頻繁に変更されることがあるため、プラグインとともに提供された製品のバージョンとは異なります。値は後述のバージョン・フォーマットに準じている必要があります。
product.version.min
このプラグインがサポートする製品の最低バージョンです。このプロパティは情報提供のみを目的に使用されます。値は後述のバージョン・フォーマットに準じている必要があります。
product.version.max
このプラグインがサポートする製品の最高バージョンです。これは通常、プラグインを含むインストール内の製品のバージョンと同じです。このプロパティは情報提供のみを目的に使用されます。値は後述のバージョン・フォーマットに準じている必要があります。
plugin.description
プラグイン/拡張機能の簡単な説明です。プラグイン/拡張機能の操作対象の製品を含める必要があります。
ovabsdk.version
このプラグイン/拡張機能に必要なOracle Virtual Assembly Builderのイントロスペクタ・プラグインSDKの最低バージョンです。これはOVABバージョンとは異なりあまり頻繁には変更されません。Oracle Virtual Assembly Builder自体は実際にSDKを変更することなく改訂できます。Oracle Virtual Assembly Builderのバージョン12.1.2.0.0ではSDKのバージョンは3.0のため、plugin.configファイルでは3.0を使用します。SDKバージョンが変更されるたびにプラグイン開発者に通知されます。
parent.plugin.name
親プラグインまたは拡張機能の名前です。拡張機能の場合のみ設定します(トップ・レベルのプラグインには親はありません)。
parent.plugin.version
この拡張機能に必要な親プラグイン/拡張機能の最低バージョンです。拡張機能の場合のみ設定します(トップ・レベルのプラグインには親はありません)。値は後述のバージョン・フォーマットに準じている必要があります。
プロパティ・ファイルとの相互作用には次の動作が含まれます。
Oracle Virtual Assembly Builderは、プロパティ・ファイルが<プラグイン名>ディレクトリに存在しない場合にエラーを報告します。
Oracle Virtual Assembly Builderは不明なプロパティを検出した場合にエラーを報告しません。これは、使用中のOracle Virtual Assembly Builder製品より新しいプラグインのホームを検索している場合に発生することがあります。
Oracle Virtual Assembly Builderはプロパティが指定されていない場合のデフォルトをドキュメント化する必要があります。これは、使用中のOracle Virtual Assembly Builder製品より古いプラグインのホームを検索している場合に発生することがあります。
バージョン番号のフォーマット
プロパティ・ファイル内のバージョン番号はすべて、単純な「番号.番号」形式で表す必要があります。これらのバージョン番号は、ピリオド(「.」)で区切られた正の10進整数から構成される構文(たとえば、「5」、「2.0」、「1.2.3.4.5.6.7」など)を使用します。これによって、拡張可能な番号を使用して、メジャー、マイナー、ミクロなどのバージョンを表現できます。バージョン仕様は次の正式な構文によって記述されます。
DotVersion:
Digits RefinedVersion
RefinedVersion:
. Digits
. Digits RefinedVersion
Digits:
Digit
Digits
Digit:
Character.isDigit(char)がtrueを戻す任意の文字(たとえば、0、1、2、...)。
バージョン番号は、バージョン番号の対応するコンポーネントを比較することで比較されます。各コンポーネントは整数として扱われ、値が比較されます。値が必要な値より大きい場合は、trueが戻されます。値が小さい場合は、falseが戻されます。値が等しい場合は、次のコンポーネント・ペアが比較されます。あるバージョンのコンポーネント数が他方より多い場合は、欠落したコンポーネントは0と想定され、比較時に存在していたかのように処理されます。
プラグインと拡張機能は、定義によって、イントロスペクション時にユーザーが指定したジョブ・パラメータから自身の製品の製品ルート・ディレクトリを決定できます。製品ルート・ディレクトリは、1つ以上の指定されたジョブ・パラメータから派生可能な場合もあるが、通常は明示的なジョブ・パラメータです。イントロスペクタ・フレームワークは、この情報がジョブ・パラメータからどのように派生しプラグインと拡張機能に渡されたか認識できませんが、各イントロスぺクションの開始時にプラグインと拡張機能の更新を自動的にチェックできるようにするためにこの情報を把握する必要があります。
この問題を解決するには、プラグインと拡張機能がIntrospectorPluginLocatorサービス実装を公開する必要があります。
各イントロスぺクション(デハイドレーション)の開始時にイントロスぺクション・フレームワークは次のステップを実行します。
イントロスぺクションに関与しているプラグインと拡張機能を判別します。
getPluginOrExtensionName()メソッドから同じ名前を戻すIntrospectorPluginLocator実装を検索します。
ステップ2で見つけた各IntrospectorPluginLocator実装でgetProductInstallHome()メソッドを実行することで、検索する製品ルートのリストを作成します。重複は統合されます。
ステップ3で導出した製品ルートで、ステップ1で見つけたより新しいバージョンのプラグインおよび拡張機能を検索します。見つかった場合は、イントロスぺクションを中断し、検出されたアップグレード候補をユーザーに報告します。
IntrospectorPluginLocator実装はSPIFサービスとして追跡され、対応するプラグインまたは拡張機能を登録するために使用された同じServiceActivator実装内で同じ方法で登録されることがあります。
プラグインまたは拡張機能のインストール時には、plugin.config内の情報に基づいて、プラグインまたは拡張機能がすでにインストールされているものと互換性があるかどうかが判別されます。常に古いバージョンをより新しいバージョンで更新した方が安全であると想定されています。これを動作させるには、次の定義に従ってプラグインと拡張機能の両方に下位互換性が必要です(プラグインと拡張機能の両方に適用されます)。
プラグインは、それがデハイドレート/リハイドレート可能な製品バージョンに関して常に下位互換性を持つことが前提とされています。つまり、新し製品に付随するより新しいプラグインは以前に取得可能だったより古い製品も引き続きデハイドレート/リハイドレートする必要があります。
プラグインは、それが処理可能なカタログ・メタデータに関して常に下位互換性があることが前提とされます。つまり、より新しいプラグインは引き続き自身の以前バージョンが作成したメタデータを使用して製品をリハイドレートできなければなりません。
プラグインは、それを拡張元とする拡張機能との相互作用に関して常に下位互換性を持つことが前提とされています。親の1つのバージョンに対して開発された拡張機能は、同じ親のより新しいバージョンに対しても引き続き動作する必要があります。
プラグインと拡張機能のインストールに関連する操作は、次のガイドラインに準じる必要があります。
拡張機能はすでにインストールされている親なしではインストールできません。
プラグインは、プラグインによって作成されたアプライアンスが存在しない場合を除き、インストールされているバージョンより古いバージョンにダウングレードできません。それを実行すると、プラグインによって作成されたアプライアンスが破損することがあります。
プラグインは、プラグインによって作成されたアプライアンスが存在する場合は削除できません。それを実行すると、プラグインによって作成されたアプライアンスが破損します。
プラグインを削除すると再帰的にプラグインのすべての子も削除されます。
プラグインを無効にすると再帰的にプラグインのすべての子も無効になります。
拡張機能は親が無効な場合は有効化できません。
これらのガイドラインは、Oracle Virtual Assembly Builderアプリケーションによって提供される様々なプラグイン・インストール操作によって適用されます。
プラグインSDKは1つ以上のプラグインで事項する必要が生じることのある共有のタスク向けにいくつかのユーティリティおよびヘルパー・クラスを提供しています。introspector.plug.utilパッケージにはSPIFサービスとして登録されるUtilFactoryが含まれています。プラグインのSPIFサービス・アクティベータ・クラスで次を使用することでこのサービスを操作できます。
UtilFactory utilFactory =
(UtilFactory) myCollector.getSingletonService(UtilFactory.class.getName());
UtilFactory.getOcmUtil()
このユーティリティを使用して、デハイドレーション時にOracle Configuration Managerに関連するプロパティをアプライアンスに追加し、リハイドレーション時にそれらのプロパティの基づいてOCMをアプライアンスに登録できます。
UtilFactory.getOuiUtil()
このユーティリティを使用して、OUI中央インベントリを構成し、デプロイメント時にそのインベントリにORACLE_HOMEを登録するために必要なメタデータを作成できます。
UtilFactory.openSshConnection()
コマンドを実行またはファイルを送信/取得するために別マシンへのSSHが必要な場合は、SshConnectionクラスを使用します。
ここでは、いくつかのベスト・プラクティス、注意事項およびイントロスペクタ・プラグインの設計と開発時に留意すべき点について説明します。
プラグインは、イントロスぺクション時に参照ホストを変更できません。一時ファイルは参照製品のディレクトリの下に作成できません。参照製品の構成と実行時の状態は変更できません。
一時ファイルを作成する必要がある場合は、Oracle Virtual Assembly Builderのtmpディレクトリを使用します。AbConfigクラスには、Oracle Virtual Assembly Builderのtmpディレクトリの場所を検索するためのメソッドがあります。
Oracle Virtual Assembly Builder Studioでイントロスペクタ・プラグインを1回インスタンス化すれば、それを繰り返し使用してイントロスぺクションとファイル・セット取得操作を実行できます。1つのStudioセッションで製品のイントロスぺクションを複数回実行する場合は静的変数を使用しないでください。使用すると予期せぬ結果を引き起こすことがあります。
ServiceActivator.start()を呼び出している間は、SPIFサービスへのアクセスを試みないでください。
プラグインが異なるメタデータ要素に指定できる名前には特定の制限があります。
アプライアンスおよびアセンブリの名前に含めることができるのは、ASCII文字(A-Z a-z)、数字(0-9)および次のシンボルのみです: ! # % ( ) * + , - . : = ? @ [ ] ^ _ { } ~
名前の長さは最長で40文字までです。
プラグイン開発者は、イントロスペクタ・プラグインを含めすべてのOracle Virtual Assembly Builderサービスが単一のクロスローダーによってロードされることを認識している必要があります。このため、複数のプラグインが同じクラスを提供する場合競合が生じることがあります。プラグインがクラスを共有することを想定していない場合があります。外部jarを提供するプラグイン(その他のプラグインによって内包されている場合もある)は、それらのjarをロードするために後述のImplProvider機能を使用する必要があります。
プラグインは、たとえば、製品に付随する独自のAPIを使用して製品構成を調べたり変更したりするために、ターゲット製品からのjarを使用しなければならない場合があります。プラグイン内で製品のjarを使用すると、これらのAPIを使用するプラグイン・コードを新しい製品バージョンと変更されたAPIに対応するように変更する必要が生じることがあるため、追加のメンテナンス問題が生じます。
多くの場合製品jarの使用はわずかな手間で回避できますが、ターゲット製品からのjarを使用する必要があると判断した場合に使用できる2つのオプションがあります。
1番目のオプションは、それらのjarをプラグインがデプロイされているディレクトリに追加することです。このアプローチの短所は、外部製品jarを製品とOracle Virtual Assembly Builderの両方に提供する必要がある点です。また、製品バージョンが変更されると、プラグインで新しい製品バージョンをそれぞれサポートするために、製品jarの複数のコピーをOracle Virtual Assembly Builderに提供する必要があります。
2番目のオプションは、製品jarをそれらが製品とともにインストールされている場所から実行時に動的にロードすることです。このアプローチは多少手間がかかりますが、製品jar(複数バージョンの可能性がある)をOracle Virtual Assembly Builderに提供する必要がなくなります。これは推奨アプローチです。
イントロスぺクション・プラグインまたはプラグイン拡張機能が複数のバージョンの製品と対話できれば理想的です。これは製品jarを使用する必要がある場合にはさらに厄介となります。そのような製品jar内のAPIはバージョンごとに変更されている可能性があるからです。これには複数のソリューションがありますが、ここでは検討する価値のある考えられる手段を提供しています。
基本的な考え方は、必要な製品jarを実行時にインストールから動的にロードするとともに、それらのjarにアクセスするための抽象レイヤーを作成するというものです。次にこのアプローチを使用するために実行できることを概略します。
製品jarを使用して実行されるタスクを抽象化するラッパー・インタフェースを作成します。この抽象化は、複数の製品バージョンに適用するために十分な高レベルにする必要があります。インタフェースは、常にロードされるプラグインのjar内に配置できます。
製品APIが変更された製品バージョンごとに前述のインタフェースの実装を作成します。最初はこのような実装を1つのみ作成し、それ以降の製品リリースで製品のAPIが変更されている場合にさらに追加していきます。これらの実装は製品インストール内のjarファイル内またはOracle Virtual Assembly Builderインストール内の個別のjarに配置できます。どちらの場合も、実装は実行時に動的にロードされます。
実行時に、製品バージョンを判別し、対応するラッパー実装とその実装に必要な製品jarをロードします。
このアプローチを容易にするために次のように処理されます。
Oracle Virtual Assembly Builderは、起動時に、BuilderのORACLE_HOME/jlib/ディレクトリ内の任意の場所にある"dynlib"という名前のディレクトリ内のすべてのjarのロードを省略します。複数のラッパー実装をこのディレクトリに配置し、必要に応じて動的にロードできます。
UtilFactory.createImplProvider()は、ラッパー実装と必要なjarの製品インストールからの動的ロードを支援します。このメソッドとoracle.as.assemblybuilder.introspector.plugin.utilパッケージのImplProviderについてはJavadocを参照してください。
仮説の例:
/**
* Interface for interactions with MDS.
*
* Resides in jlib/stuff/myplugin.jar
*/
interface MdsWrapper {
String getMdsFoo();
String getMdsBar();
void setMdsFoo(String value);
void setMdsBar(String value);
}
/**
* Uses 11g APIs to interact with MDS (fabric-core.jar).
*
* Resides in jlib/stuff/dynlib/mdswrapper-v1.jar
*/
class MdsWrapperImplVersion1 implements MdsWrapper {
...
}
/**
* Uses 12g APIs to interact with MDS.
*
* Resides in jlib/stuff/dynlib/mdswrapper-v2.jar
*/
class MdsWrapperImplVersion2 implements MdsWrapper {
...
}
前述のコードでは、プラグインは製品バージョンに応じて必要な実装を取得できます。
void doMdsStuff(String oracleHome) {
String fabricJarPath = oracleHome + "/jlib/fabric-core.jar";
String productVersion = getVersion(oracleHome);
MdsWrapper mdsWrapper = null;
// obtain product version specific implementation
if (productVersion.equals(VER_11G)) {
ImplProvider implProvider =
utilFactory.createImplProvider("mdswrapper-v1.jar", fabricJarPath);
mdsWrapper =
implProvider.createInstance(MdsWrapper.class, "MdsWrapperImplVersion1");
}
else if (productVersion.equals(VER_12G)) {
ImplProvider implProvider =
utilFactory.createImplProvider("mdswrapper-v2.jar", fabricJarPath);
mdsWrapper =
implProvider.createInstance(MdsWrapper.class, "MdsWrapperImplVersion2");
}
// use implementation generically
String foo = mdsWrapper.getMdsFoo();
String bar = mdsWrapper.getMdsBar();
mdsWrapper.setMdsFoo(foo);
mdsWrapper.setMdsBar(bar);
}
プラグインのデハイドレーションおよびリハイドレーション機能のテストについて説明します。
イントロスペクタ・プラグイン内のデハイドレーション機能のテストは簡単で、単にイントロスぺクションを実行するのみです。プラグインをOracle Virtual Assembly Builder環境にインストールする方法の詳細は、5.6.3項「プラグインの検出およびインストール」を参照してください。
イントロスぺクション・プラグイン内のリハイドレーション機能のテストは時間がかかり、OVM環境でのトラブルシューティングが厄介な場合があります。この項では、ガイダンスを説明しています。Oracle Virtual Assembly Builderの使用のトラブルシューティングに関する項も参照してください。
Oracle Virtual Assembly Builderがアセンブリをデプロイするときに生ずるステップを理解しておくと、障害の優先順位付けに役立ちます。プラグイン・コードを呼び出す前にVMで実行するいくつかのアクションがあります。
仮想マシンの作成と起動
Oracle Virtual Assembly BuilderデプロイヤはOVMマネージャに、デプロイしているアセンブリ内のすべてのアプリケーションの仮想マシンを作成するように指示します。すべての仮想マシンが作成された後、それらはアプライアンスとの依存関係に基づいて起動されます。
VM上でのABサービスの作成
VMが起動すると、oraclevm-template.shと呼ばれる特別なスクリプトが自動的に実行されます。このスクリプトは、'ab'と呼ばれるLinuxサービスをインストールします。abサービスはネットワーク構成とアプライアンス・デプロイ・ドライバの起動を担います。
VMのネットワーク構成
abサービスがoraclevm-template.shスクリプトによって起動され、VMのネットワーク設定を構成します。
phonehomeを介した遅延バインドの取得
ネットワーク・セットアップの完了後、abサービスはJavaプロセスのアプライアンス・デプロイ・ドライバを起動します。このJavaコードは、Oracle Virtual Assembly Builderデプロイヤとの通信を処理し遅延バインドを取得します。また、プラグインを呼び出すリハイドレータ・コードを起動し、Oracle Virtual Assembly Builderデプロイヤに再び接続してリハイドレーションが成功したか失敗したかを報告します。
アプライアンス・デプロイ・ドライバは、Oracle Virtual Assembly Builder Deployerに接続し遅延バインド情報を取得します。
遅延バインド情報がOracle Virtual Assembly Builderデプロイヤから取得されると、VM上のメタデータがその遅延バインドを反映して更新されます。この更新されたメタデータは/assemblybuilder/catalog/metadata/rootの下にあります。
イントロスペクタ・プラグインの呼出し
遅延バインディングがVM上のカタログ(Oracle Virtual Assembly Builderホスト上のカタログのサブセットで、デプロイされている現在のアプライアンスをリハイドレートするために必要なメタデータのみを含む)に保存された後、プラグインのRehydrator.rehydrate()メソッドが呼び出されます。
Oracle Virtual Assembly Builderデプロイヤへのリハイドレーションの結果の送信
ベース・プラグインとそのすべての拡張機能が正常に完了すると、アプライアンス・デプロイ・ドライバはOracle Virtual Assembly Builder Deployerへ正常な結果を送信します。いずれかのポイントで失敗した(ベース・プラグインまたはいずれかの拡張機能が例外をスローした)場合は、失敗が発生した時点で失敗の結果が送信されます。
