| Oracle® Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ E90320-02 |
|
 前へ |
 次へ |
この章には次の項が含まれます:
通常、管理者やデプロイヤが開発チームまたは品質保証チームから新しいアプリケーションや新しいバージョンのアプリケーションを受け取る場合、アプリケーションは開発環境またはテスト環境用に構成されています。
そのアプリケーションでは、特定のリソース名やパフォーマンス・チューニング設定(アプリケーションが最後にデプロイされた開発環境またはQA環境で使用されていたターゲット・サーバー上で利用可能なリソースに一致する名前や設定)が使用されている可能性があります。開発環境およびテスト環境は、アプリケーションが最終的にデプロイされる本番環境とは著しく異なっている可能性があるため、管理者は本番環境について有効かつ適切なリソース名およびパフォーマンス・チューニング・パラメータを使用するように、アプリケーションを構成する必要があります。
アプリケーションのデプロイメント構成は、アプリケーションのライフサイクルにおいて、いくつかの時点で行われる可能性があります。デプロイメント構成の各フェーズでは一般に、様々なデプロイメント・ファイルの作成と処理が行われます。
開発構成 - 開発中、プログラマはアプリケーションまたはモジュールのJava EEデプロイメント記述子を作成します。プログラマは、また、WebLogic Server開発環境にデプロイするアプリケーションを構成するWebLogic Serverデプロイメント記述子を作成します。『Oracle WebLogic Serverアプリケーションの開発』を参照してください。
注意:
WebLogic Server開発環境の外部で開発されたアプリケーション(たとえば、サンプル・アプリケーション、またはPetStoreなどサード・パーティのJava EEアプリケーション)には、Java EE記述子しか含まれていない場合があります。
エクスポート構成 - アプリケーションを開発からリリースする前に、プログラマまたは設計者は必要に応じて、アプリケーションのデプロイメント構成をWebLogic Serverデプロイメント・プランにエクスポートできます。構成のエクスポートによって、開発者がアプリケーションのWebLogic Serverデプロイメント記述子ファイルで定義したデプロイメント・プロパティの全部または一部のためのデプロイメント・プラン変数が作成されます。「新しい環境にデプロイするためのアプリケーションのエクスポート」を参照してください。
アプリケーションのエクスポートにより、組織における別分野のデプロイヤ(QAチームの技術者、本番管理者など)が、プログラマの開発環境とは異なる環境へ、アプリケーションを簡単にデプロイできるようになります。理想的なデプロイメント・プランには、新しい環境でアプリケーションをデプロイする前にデプロイヤが変更する必要のあるすべてのプロパティが含まれています。
デプロイメント時の構成 - 管理者またはデプロイヤは、ターゲット環境にアプリケーションをデプロイする前に、アプリケーションの構成を行います。デプロイメント時構成では、以下を使用できます。
開発時に作成されたWeblogic Serverデプロイメント構成およびデプロイメント・プラン
これらの開発構成およびデプロイメント・プランの修正版
それぞれの組織のデプロイメント構成ワークフローに応じ、デプロイヤがその環境用に事前に作成したカスタム・デプロイメント・プラン
デプロイメント後の構成 - アプリケーションがターゲット環境にデプロイされた後は、管理者またはデプロイヤは新しいデプロイメント・プランでの再デプロイメントによって、またはWebLogic Server管理コンソールを使用した既存のデプロイメント・プランの更新および再デプロイメントによって、アプリケーションを再構成できるようになります。「本番環境でのアプリケーションの再デプロイメント」 および「デプロイされたアプリケーションの管理」を参照してください。
デプロイメント構成は、アプリケーションのライフサイクルにおける様々な時点で、様々な人間によって行われるため、管理者、デプロイヤ、および開発者は互いに協力して、繰返し実行できる構成ワークフローを組織のために作成する必要があります。「一般的なデプロイメント構成のワークフロー」を参照してください。
アプリケーションの基本的なデプロイメント構成は、デプロイメント記述子として知られる複数のXMLドキュメントで定義されます。これらは、デプロイメント用に提供されるアプリケーション・アーカイブ・ファイルの一部として用意されています。デプロイメント記述子ファイルは、別個の2つのカテゴリに分類されます。
Java EEデプロイメント記述子。アプリケーションのデプロイ先に関係なく、Java EEアプリケーションまたはモジュールの基本的構成および動作を定義します。各Java EEアプリケーションおよびモジュールには、Java EE仕様で定義されている特定のJava EEデプロイメント記述子が必要です。
WebLogic Serverデプロイメント記述子は、特定のWebLogic Server環境でアプリケーションが使用するリソースの依存関係およびチューニング・パラメータを定義します。
本番デプロイメントを行うためには、Java EEとWebLogic Serverの双方のデプロイメント記述子を、開発チームが所有するアプリケーションのソース・コードの一部として扱う必要があります。本番環境にデプロイするアプリケーションの構成を行うために、アプリケーション・デプロイメント記述子を編集することはしないでください。かわりに、構成の変更をWebLogic Serverデプロイメント・プラン(次の項で説明)内に永続化します。
注意:
DTDベースのデプロイメント記述子を使用するアプリケーションでデプロイメント・プランを使用することはできません。このアプリケーションは、スキーマ・ベースの記述子を使用するようアップグレードする必要があります。
WebLogic Serverデプロイメント・プランは、前述したように特定のWebLogic Server環境へのデプロイメント用にアプリケーションを構成するために使用する任意のXMLドキュメントです。デプロイメント・プランでは、通常はアプリケーションのWebLogic Serverデプロイメント記述子で定義するようなデプロイメント・プロパティ値の設定を指定したり、WebLogic Serverデプロイメント記述子ですでに定義されているプロパティ値をオーバーライドしたりします。アプリケーションをエクスポートするときに、デプロイメント・プランは通常、開発中に作成したWebLogic Serverデプロイメント記述子内の選択されたプロパティをオーバーライドするよう機能します。
注意:
Java EEまたはWebLogic専用デプロイメント記述子を構成またはオーバーライドできますが、一時ラベル付きのアイテムは除きます。
JSR 88 DConfigBeansのセッター・メソッド(記述子要素の値の変更用)および削除メソッド(記述子要素の削除用)を使用し、デプロイメント・プランを更新できます。また、標準記述子およびWebLogic専用記述子用のgetDescriptorBean()によって返される記述子のBeanツリーから、セッター・メソッドと削除メソッドを呼び出すことも可能です。これらのメソッドによって、プランはオーバーライドされます。WebLogic Deployment APIによるアプリケーションのデプロイのデプロイメントのためのアプリケーションの構成を参照してください。
通常は、開発者が関連アプリケーション・ファイルとともにデプロイメント・プランを作成し、管理者やデプロイヤに配布します。配布を受けた管理者やデプロイヤは、特定の環境(ステージング、テスト、本番など)にあわせてプランを更新します。デプロイメント・プランは、アプリケーション・アーカイブや展開されたアーカイブ・ディレクトリの外部に格納します。ベスト・プラクティスとしては、単一のアプリケーションの各デプロイメント・プランを、アプリケーションのルート・ディレクトリにおける、それぞれの専用planサブディレクトリに格納することをお薦めします(「アプリケーションのインストール・ディレクトリの作成」を参照)。
デプロイメント・プランを使用すると、管理者はアプリケーション・アーカイブに含まれているデプロイメント記述子ファイルを変更することなく、アプリケーションを複数の様々なWebLogic Server環境にデプロイするためのWebLogic Server構成を簡単に変更できます。構成の変更は、変更するWebLogic Server記述子プロパティの場所と、それらのプロパティに割り当てる値の双方を定義する、デプロイメント・プラン内の変数を追加または変更することによって適用されます。アプリケーションをデプロイしている管理者は、デプロイメント・プランを変更するのみで済みます。元のデプロイメント・ファイルとデプロイメント記述子は、変更されないままです(図4-1を参照)。それぞれの環境のデプロイメント構成ワークフローを決定するには、「一般的なデプロイメント構成のワークフロー」を参照してください。
管理者にとって、アプリケーションを本番デプロイメント用に構成する際の第一の目標は、ターゲットWebLogic Server環境に適した有効な新しいデプロイメント・プランを生成することです。具体的には、デプロイメント・プランはすべての外部リソース参照を解決し、アプリケーションがターゲット環境において使用可能である有効なリソースを参照するようにする必要があります。アプリケーションの構成でターゲット・サーバーについて有効な外部リソースが定義されていなければ、アプリケーションはデプロイできません。
デプロイメント・プランでは、必要に応じてWebLogic Serverチューニング・パラメータを定義またはオーバーライドして、ターゲット環境におけるリソースの理想的な使用方法を実現できます。チューニング・パラメータの定義は、アプリケーションのデプロイを正常に実行するために必須というわけではありません。アプリケーションのデプロイメント記述子とデプロイメント・プランで、チューニング・パラメータが定義されていなければ、WebLogic Serverはデフォルト値を使用します。
デプロイメント・プランを使用すると、複数のWebLogic Server環境にデプロイするためのアプリケーションの構成の、便利で繰返し可能なワークフローを定義できます。本番アプリケーションのための構成ワークフローには、デプロイ可能なアプリケーションを作成およびパッケージ化する開発および設計チームと、各ターゲットWebLogic Server環境の管理者またはデプロイヤとの間で協力が必要です。
組織のための理想的なデプロイメント構成ワークフローは、次の要素によって決まります。
同じアプリケーションをデプロイするそれぞれの環境の数
各ターゲット環境によって提供されるリソースの違い
各ターゲット環境の変更頻度
アプリケーションのJava EE構成の変更頻度
組織内の様々な分野における構成情報に対する所有権の要件
次の項では、デプロイメント・プランの管理、および複数のWebLogic Serverドメインへのアプリケーションのデプロイのための一般的なデプロイメント構成ワークフローについて説明します。
様々なデプロイメント環境の正確な構成を理解している組織では、単一の精密に定義されたデプロイメント・プランを使用して、アプリケーションを複数のWebLogic Serverドメインにデプロイできます。単一デプロイメント・プランの構成ワークフローは、次のように機能します。
開発チームは、管理者およびデプロイヤと協力して、すべてのターゲット環境で使用するためのマスター・デプロイメント・プランを作成します。ターゲット環境の数は、組織の構成によって異なります。共通のデプロイメント環境には、1つまたは複数の品質保証(QA)またはテスト・ドメイン、ステージング・ドメイン、および本番ドメインが含まれます。
このフェーズでチームが作成するデプロイメント・プランは、ターゲット環境ごとに異なると分かっているすべての構成プロパティの変数を定義します。たとえばこのプランで、環境間で異なっており、アプリケーションがデプロイ可能になる前に構成が必要なリソース名のための空の変数を定義する場合があります。またこのプランでは、デプロイヤが環境において変更するかもしれない共通のチューニング・パラメータのデフォルト値を定義することもあります。
開発中におけるデプロイメント・プランの作成の詳細は、「新しい環境にデプロイするためのアプリケーションのエクスポート」を参照してください。
あるバージョンのアプリケーションのリリース準備が整うと、開発チームはそのアプリケーションのデプロイメント・ファイルをパッケージ化し、デプロイメント・ファイルとマスター・デプロイメント・ファイルの双方を、各ターゲット環境のデプロイヤに配信します。
各デプロイヤは、WebLogic Server管理コンソールを使用してアプリケーションをインストールし、構成に使用するデプロイメント・プランを識別します。WebLogic Server管理コンソールは、対象ドメインで使用可能なリソースに基づき、デプロイメント構成全体を検証します。その後、プランで定義されている構成可能なプロパティ(および、すべての無効なプロパティ)のリストを、編集のためにデプロイヤに提示します。
デプロイヤは、WebLogic Server管理コンソールを使用して、デプロイメント・プランで定義されたプロパティを対話形式で構成します。null値、またはターゲットWebLogic Serverインスタンスまたはクラスタについて無効な値を持つデプロイメント・プラン変数を構成しないと、アプリケーションがデプロイ可能になりません。すでに有効な値を持つデプロイメント・プラン変数は、デプロイメント前に変更する必要はありません。
各環境のデプロイヤは、構成変更をデプロイメント・プランで定義されたプロパティのみに制限することに同意しています。追加の構成変更が必要な場合、デプロイヤはマスター・デプロイメント・プランを変更する開発または設計チームに、それらの必要性を伝えなくてはなりません。
単一デプロイメント・プランのワークフローを使用する利点は、次のとおりです。
開発または設計チームが、アプリケーションのデプロイメント構成を制御できます。
アプリケーションをターゲット環境にデプロイする際に、デプロイヤが行わなければならない構成上の判断の数が減少します。
アプリケーションと関連付けられた構成ファイルの数が最小限に留められ、デプロイメント構成情報のソース・コントロール・システムへの格納が容易になります。
全般に、単一デプロイメント・プランのワークフローを使用するのは、組織におけるターゲット環境が少数かつ詳しく理解されており、各環境で標準化されたデプロイメント構成を簡単にレプリケートする必要がある場合です。
単一のデプロイメント・プランのワークフローでは、開発または設計チームが、デプロイメント・プランの所有権を保持しており、デプロイヤがプランに対して行える変更は、プラン内で定義される変数に限定されていることを前提としています。デプロイヤが、デプロイメント・プランで定義されているプロパティのみを変更する場合、それらの変更は変数の更新として、同じデプロイメント・プランに書き戻されます。
しかし、WebLogic Serverでは、デプロイヤがWebLogic Server管理コンソールを使用して変更できる構成プロパティに関しては、制限を設けていません。デプロイヤが、元来はプラン内で定義されていなかったデプロイメント・プロパティを構成する場合、管理コンソールは変数エントリが追加された新しいデプロイメント・プランを生成し、その新しいプランを、デプロイメントまたは再デプロイメント操作に使用します。これによりデプロイヤが、開発チーム所有のマスター・デプロイメント・プランとは大幅に異なるデプロイメント・プランを使用するという状況が生じる可能性があります。
マスター・デプロイメント・プランに新しく変更を組み込むには、デプロイヤは管理コンソールによって作成されカスタマイズされた、新しいデプロイメント・プランを取得します。理想的には、これらの変更は、マスター・デプロイメント・プランに適用されます。
頻繁に変更される数多くのデプロイメント環境を有する組織では、複数のデプロイメント・プランを備える構成ワークフローを使用する必要があります。複数デプロイメント・プランのワークフローでは、各デプロイメント・プランは開発チームではなく、アプリケーションのデプロイヤが所有しています。複数デプロイメント・プランの構成ワークフローは、次のように機能します。
開発チームは、あるバージョンのパッケージ化されたアプリケーション・デプロイメント・ファイル(Java EEおよびWebLogic Server記述子を含む)をリリースします。リソース定義のためのエクスポートされた変数、または共通のチューニング可能なパラメータを備えるテンプレート・デプロイメント・プランは、これに含めても含めなくてもかまいません。
アプリケーションをデプロイする前に、各デプロイヤは、ターゲット環境用にアプリケーションを構成するためのカスタム・デプロイメント・プランを生成します。
カスタム・デプロイメント・プランの作成は、テンプレートのデプロイメント・プラン(またはデプロイメント・プランなしで)により開始し、WebLogic Server管理コンソールを使用してアプリケーションのデプロイメント構成に変更を加えることが可能です。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのデプロイメント・プランの更新を参照してください。
環境にあわせてデプロイメント構成を定義後、各デプロイヤはカスタム・デプロイメント・プランを取得して、それをアプリケーションの将来的なデプロイメントに備えて維持します。カスタム構成プランは、必要に応じて新しいバージョンを追跡したり元に戻したりできるように、ソース・コントロール・システムに格納することをお薦めします。
その後のリリースでは、各デプロイヤはカスタマイズされたデプロイメント・プランを使用して、アプリケーションをデプロイメントのために構成します。カスタマイズされたプランを使用すると、デプロイヤはweblogic.Deployerでデプロイメントを実行したり、WLSTでデプロイメントを自動化したりできます。
複数デプロイメント・プランのワークフローを使用する利点は、次のとおりです。
管理者またはデプロイヤが、アプリケーションの構成と環境の構成を両方とも一緒に管理できるようになります。
デプロイヤが、アプリケーションをグローバルに構成するカスタム・プランを使用して、デプロイメント・プロセスを自動化できます。
全般に、複数デプロイメント・プランのワークフローを使用するのは、組織におけるデプロイメント環境の数が多く、頻繁に変更されるために単一のマスター・デプロイメント・プランを維持することが困難または不可能である場合です。
複数デプロイメント・プランのワークフローでは、(プログラミングあるいは設計チームではなく)デプロイヤまたは管理者が、アプリケーション用にデプロイメント構成を所有し管理するものと想定します。また、アプリケーションの基本的なJava EEの構成はほとんど変更しないことを想定しますが、それは特定のJava EEの構成変更が、デプロイヤのカスタム構成プランを無効にするためです。たとえば、エンタープライズ・アプリケーション内のモジュールが追加、削除、または変更された場合、そのモジュールを参照するカスタム・デプロイメント・プランは無効になります。この場合、各デプロイヤはWebLogic Server管理コンソールを使用してアプリケーションを構成することで、カスタム・プランを再作成する必要があります。
WebLogic Server管理コンソールは、ドメインにインストールしたアプリケーションのデプロイメント・プロパティを対話形式で変更すると、アプリケーションの有効なXMLデプロイメント・プランを自動的に生成(または更新)します。生成されたデプロイメント・プランを後のデプロイメントにおけるアプリケーションの構成に使用することもできますし、デプロイメント・プロパティを繰返し編集および保存することで新しいバージョンのデプロイメント・プランを生成することもできます。
注意:
weblogic.PlanGeneratorを使用して、Java EEデプロイメント記述子のみを使用した基本的なWebLogic Serverデプロイメント・プランを生成することもできます。「weblogic.PlanGeneratorコマンド行リファレンス」を参照してください
WebLogic Server管理コンソールを使用してのデプロイメント・プランの生成は、次の手順を伴います。
WebLogic Server管理コンソールでは、アプリケーション・インストール・アシスタントを使用して、新しいWebLogic Server環境に構成およびデプロイする新しいアプリケーションを簡単にインストールできます。アプリケーションまたはモジュールをインストールしてデプロイメント・ターゲットを選択すると、WebLogic Serverドメインでデプロイメント・ファイルが使用可能になり、必要に応じて構成、配布、およびデプロイできます。
アプリケーションをWebLogic Serverドメインにインストールするには、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのアプリケーションおよびモジュールのインストールに関する項の手順に従います。
WebLogic Server管理コンソールを使用して、「アプリケーション・アーカイブをインストールする」でインストールしたアプリケーションのデプロイメント構成プロパティを編集し、構成をデプロイメント・プランに保存します。
\planサブディレクトリに入れます。たとえば、c:\sample_root\plan\Plan.xmlとなります。例4-1 サンプル・デプロイメント・プラン
<deployment-plan xmlns="http://xmlns.oracle.com/weblogic/deployment-plan">
<application-name>sample_root</application-name>
<variable-definition>
<variable>
<name>SessionDescriptor_InvalidationIntervalSecs_11029744771850</name>
<value>80</value>
</variable>
<variable>
<name>SessionDescriptor_TimeoutSecs_11029744772011</name>
<value>8000</value>
</variable>
</variable-definition>
<module-override>
<module-name>myApp.ear</module-name>
<module-type>ear</module-type>
<module-descriptor external="false">
<root-element>weblogic-application</root-element>
<uri>META-INF/weblogic-application.xml</uri>
</module-descriptor>
<module-descriptor external="false">
<root-element>application</root-element>
<uri>META-INF/application.xml</uri>
</module-descriptor>
</module-override>
<module-override>
<module-name>myWebApp.war</module-name>
<module-type>war</module-type>
<module-descriptor external="false">
<root-element>weblogic-web-app</root-element>
<uri>WEB-INF/weblogic.xml</uri>
<variable-assignment>
<name>SessionDescriptor_InvalidationIntervalSecs_11029744771850</name>
<xpath>/weblogic-web-app/session-descriptor/invalidation-interval-secs</xpath>
</variable-assignment>
<variable-assignment>
<name>SessionDescriptor_TimeoutSecs_11029744772011</name>
<xpath>/weblogic-web-app/session-descriptor/timeout-secs</xpath>
</variable-assignment>
</module-descriptor>
<module-descriptor external="false">
<root-element>web-app</root-element>
<uri>WEB-INF/web.xml</uri>
</module-descriptor>
</module-override>
<module-override>
<module-name>sample_root</module-name>
<module-type>ear</module-type>
<module-descriptor external="false">
<root-element>weblogic-application</root-element>
<uri>META-INF/weblogic-application.xml</uri>
</module-descriptor>
<module-descriptor external="false">
<root-element>application</root-element>
<uri>META-INF/application.xml</uri>
</module-descriptor>
</module-override>
<config-root>C:\sample_root\plan</config-root>
</deployment-plan>
デプロイメント・プラン内の基本要素は、以下の関数に対する処理を行います。
deployment-plan。デプロイメント・プランのすべての内容をカプセル化します。
application-name。アプリケーションまたはモジュールのデプロイメント名に対応します。
variable-definition。1つまたは複数のvariable要素を定義します。各variableは、プラン内で使用される変数のname、および割り当てるvalue (nullでも可)を定義します。例4-1に示すサンプル・プランには、「セッション無効化間隔」および「セッション・タイムアウト」プロパティに加えた変更に対する変数定義が含まれます。
module-override要素。デプロイメント・プランがオーバーライドする、各モジュールの名前、種類、およびデプロイメント記述子を定義します。module-descriptor要素には、必要に応じて、記述子内のプロパティのオーバーライドに使用される変数名を識別するvariable-assignment、およびプロパティがオーバーライドされる記述子内の正確な場所を含めることができます。
例4-1に示すサンプル・プランには、エンタープライズ・アプリケーションのモジュール・オーバーライド要素、組込みWebアプリケーション、およびそれらを格納するルート・ディレクトリが含まれます。weblogic.xml記述子ファイルのmodule-descriptorエントリは、2つのvariable-assignment要素を含み、「デプロイメント・プランに構成の変更を保存する」の例で変更したセッション無効化間隔および「セッション・タイムアウト」プロパティのプロパティ値をオーバーライドします。
デフォルトでは、variable-assignment要素の値は記述子内で定義済みの値に追加されます。variable-assignment要素内のoperation下位要素を、それぞれreplaceまたはremoveの各値に設定することにより、variable-assignment要素が記述子内で定義された値に置換されるように、またはこれらの値が削除されるように、この動作を変更できます。
たとえば、ある開発者が、ejb-jar.xmlでejbRoleという名前のセキュリティ・ロールのみにアクセスを許可するポリシーを作成したとします。
... <assembly-descriptor> <security-role> <role-name>ejbRole</role-name> </security-role> <method-permission> <role-name>ejbRole</role-name> <method> <ejb-name>ejb.SearchHandlerWrapperEJB</ejb-name> <method-name>*</method-name> </method> </method-permission> </assembly-descriptor> ...
weblogic-ejb-jar.xmlのsecurity-role-assignment要素では、ejbRoleがuser1という名前のプリンシパルにマップされています。
... <security-role-assignment> <role-name>ejbRole</role-name> <principal-name>user1</principal-name> </security-role-assignment> ...
ここで、デプロイメント・プランを使用してweblogic-ejb-jar.xmlで定義されているsecurity-role-assignment要素をオーバーライドし、ejbRoleをuser1ではなくuser2にマップしたいとします。このオーバーライドは、デプロイメント・プラン内のvariable、variable-assignment、およびoperation要素に適切な値を設定することで実現できます。operationの値は、必ずreplaceに設定します。
...
<variable> <name>SecurityRoleAssignment_ejbRole_PrincipalNames_11168815313911</name>
<value>user2</value>
</variable>
<variable-assignment>
<name>SecurityRoleAssignment_ejbRole_PrincipalNames_11168815313911</name>
<xpath>/weblogic-ejb-jar/security-role-assignment/[role-name="ejbRole"]/principal-name</xpath>
<operation>replace</operation>
</variable-assignment>
WebLogic Serverデプロイメント・プランの内容の詳細は、http://xmlns.oracle.com/weblogic/deployment-plan/1.01/deployment-plan.xsdを参照してください。
デプロイメント用に受け取るアプリケーションは、構成情報の可変レベルを備えている可能性があります。
アプリケーションに現行の構成プランがある場合、「デプロイメント・ファイルの準備」で説明しているように単にアプリケーションを準備し、アプリケーション・ルートのplanサブディレクトリにデプロイメント・プランを配置します。次に、「アプリケーション・アーカイブをインストール」の命令を使用し、アプリケーションをインストールします。WebLogic Server管理コンソールは1つのプランが有効であれば、アプリケーション・ルート・ディレクトリの\planサブディレクトリで、自動的にPlan.xmlという名前のデプロイメント・プランを使用します。アプリケーションで複数のプランが有効であれば、それらは\planサブディレクトリ(たとえば\plan1および\plan2)に配置され、WebLogic Server管理コンソールはそれらを認識できません。したがってconfig.xmlは使用するプランを指定する必要があります。config.xmlの詳細は、『Oracle WebLogic Serverドメイン構成の理解』のドメイン構成ファイルに関する項を参照してください。
新しいアプリケーションおよび既存のデプロイメント・プランをインストール後、WebLogic Server管理コンソールはデプロイメント・プランの構成を、インストールの際に選択されたターゲット・サーバーおよびクラスタと比較して検証します。デプロイメント・プランに、空(null)の変数が格納されている、またはデプロイメント・プランで構成された値の中に、ターゲット・サーバー・インスタンスについて有効でないものがある場合は、デプロイメント・プランをオーバーライドしてからでなければ、アプリケーションをデプロイすることはできません。また、「デプロイメント・プランに構成の変更を保存する」で説明したように、アプリケーションをデプロイするターゲット環境に、よりよく適合させるため、チューニング・パラメータを構成することも可能です。アプリケーションの構成に対して加えた変更は、新しいデプロイメント・プランに保存されます。
アプリケーションの構成がデプロイ先の環境に対して完全に適合している有効なデプロイメント・プランがある場合は、WebLogic Server管理コンソールとweblogic.Deployerユーティリティのどちらかを使用して、デプロイメントに使用するデプロイメント・プランでアプリケーションをデプロイできます。
注意:
weblogic.Deployerユーティリティで使用するデプロイメント・プランはいずれも完全なものであり、ターゲット・サーバーについて有効であることが必要です。weblogic.PlanGeneratorでは、プランの作成時に個々のデプロイメント・プロパティを設定またはオーバーライドすることはできません。weblogic.Deployerを使用して、新しいアプリケーションおよび既存のデプロイメント・プランをデプロイするには、「デプロイメント・プランによるアプリケーションのデプロイ」を参照してください。
デプロイメント・プランを使用して、application.xmlデプロイメント記述子で定義されたcontext-root要素をオーバーライドできます。次の例では、Plan.xmlファイルを使用して、アプリケーションのcontext-rootを変更する方法を示します(関連セクションを太字で表示)。
例4-2 デプロイメント・プランを使用したアプリケーションのcontext-rootの変更
<deployment-plan xmlns="http://xmlns.oracle.com/weblogic/deployment-plan"> <application-name>test</application-name> <variable-definition> <variable> <name>myNewRoot</name> <value>DEF</value> </variable> </variable-definition> <module-override> <module-name>test</module-name> <module-type>ear</module-type> <module-descriptor external="false"> <root-element>application</root-element> <uri>META-INF/application.xml</uri> <variable-assignment> <name>myNewRoot</name> <xpath>/application/module/web/[context-root="ABC"]/</xpath> <operation>replace</operation> </variable-assignment> </module-descriptor> </module-override> <config-root>D:\Cases\WLS\PlanXML\test</config-root> </deployment-plan>
例4-2では、次のようになります。
application.xmlファイルで定義されたcontext-rootは、ABCです。
デプロイメント・プランを使用すると、context-rootがABCからDEFに正常に変更されます。
アプリケーションへのアクセスに使用されるURLは、http://localhost:7001/ABC/index.htmlからhttp://localhost:7001/DEF/index.htmlに変更されます。
汎用ファイル・ロード・オーバーライドを使用すると、アプリケーション固有のファイルを既存のプラン・ディレクトリ構造のオプションのサブディレクトリ(/AppFileOverridesという名前)にオーバーライドできます。このサブディレクトリの有無により、デプロイメントでファイルのオーバーライドが可能かどうかが決まります。
このサブディレクトリが存在する場合、デプロイメント用に、内部のClassFinderがアプリケーションおよびモジュールのクラス・ローダーの前に追加されます。結果として、ファイル・オーバーライドの階層規約は、既存のクラスローダーおよびアプリケーションのリソース・ロード規約および動作に従います。WebLogic Serverアプリケーション・クラスロードの詳細は、『Oracle WebLogic Serverアプリケーションの開発』のWebLogic Serverアプリケーションのクラスロードに関する項を参照してください。
注意:
このメカニズムは、リソースのオーバーライドのみであり、クラスはオーバーライドされません。
アプリケーション固有のファイルがあり、内容がWebLogic Serverには不透明なため、オーバーライド・ファイルが提供されるとき、ファイル全体の内容がオーバーライドされます。
/AppFileOverridesサブディレクトリに配置されるファイルは、残りのプラン・ディレクトリの内容とともにステージングされて配布され、すべてのターゲットに対して有効となります。その後、現行のクラスローダーを使用して、アプリケーションはこれらのファイルをリソースとしてロードすることができます(たとえば、ClassLoader.getResourceAsStreamメソッドを使用。)これは、構成とオーバーライドしたファイルの提供状況によって、アプリケーションでオーバーライドしたファイルまたはパッケージ化したファイルを見つけます。
Webアプリケーションの場合、アプリケーション・ファイル・オーバーライドは、クラスパスに関連付けられた(WEB-INF/classesおよびWEB-INF/libに存在する)リソースにのみ適用され、Webアプリケーションのリソース・パスに対しては適用されません。したがって、オーバーライドは、Webアプリケーションがclassloader.getResourceAsStream()メソッドを使用してリソースをルックアップする場合には適用されますが、ServletContext.getResourceAsStream()メソッドを呼び出す場合には適用されません。
この機能を使用するには、以下を行う必要があります。
デプロイメント・プランを指定する(「アプリケーションを構成するための新しいデプロイメント・プランの作成」を参照)。
プラン内にconfig-rootを指定します。
config-root/AppFileOverridesサブディレクトリを指定します。
/AppFileOverridesサブディレクトリの内容には、既存のプラン・ディレクトリ構造と、記述子のオーバーライド用にすでに存在するディレクトリ命名規則が適用されます。ディレクトリ命名規則については、「デプロイするファイルのパッケージ化」を参照してください。
アプリケーション・ファイル・オーバーライドを可能にすれば、ディレクトリのClassFinderがアプリケーションおよびモジュール・レベルのクラス・ローダーに追加されることになります。これは/AppFileOverridesサブディレクトリ(プラン・ディレクトリにあります)内の適切なルート・ディレクトリを指します。アプリケーションのクラス・ローダーの前面に挿入されるClassFinderには、AppDeploymentMBean.getLocalPlanDir + separator + "/AppFileOverrides"の構造が与えられます。モジュールのクラスロード前面に挿入されるClassFinderには、AppDeploymentMBean.getLocalPlanDir + separator + "/AppFileOverrides" + separator + moduleURIの構造が与えられます。
例:
表4-1 汎用ファイル・オーバーライドのディレクトリ構造
| ディレクトリ | 説明 |
|---|---|
install-root/plan/AppFileOverrides |
メイン・アプリケーション・クラスローダーのクラスパスの前に挿入されるディレクトリ |
install-root/plan/AppFileOverrides/WebApp1.war/... |
|
install-root/plan/AppFileOverrides/WebApp2.war/... |
|
重要なことは、アプリケーションは、ファイルの内容および形式を制御し、アプリケーション・コードによってファイルの内容へのアクセスを制御するということです。ベスト・プラクティスは、汎用ファイル・ロード・オーバーライドを、環境固有のプロパティ・ファイルを指定したアプリケーション・コードで使用し、それらのプロパティ・ファイルをアプリケーションのクラスローダーを使用してリソースとしてロードすることです。以下に、アプリケーション・コードによって実行可能な例を示します。
Properties myAppProps = new Properties();
InputStream iostream =
Thread.currentThread().getContextClassLoader().getResourceAsStream("myCfg/myApp.properties");
myAppProps.load(iostream);
参照情報では、追加のデプロイメント構成タスクが説明されています。
「デプロイメント・プランによるアプリケーションのデプロイ」,。weblogic.Deployerツールを使用して、有効なデプロイメント・プランとともにアプリケーションをデプロイする方法について説明します。「weblogic.Deployerコマンド行リファレンス」を参照してください。
「アプリケーションのデプロイメント構成の更新」。現在デプロイされているアプリケーションのデプロイメント構成を更新する方法について説明します。
「新しい環境にデプロイするためのアプリケーションのエクスポート」。開発者が、weblogic.PlanGeneratorツールを使用してポータブル・デプロイメント・プランを作成できる方法について説明します。
「weblogic.PlanGeneratorコマンド行リファレンス」。weblogic.PlanGeneratorツールに関する詳細なリファレンスを提供します。
複数バージョンのWebLogic Serverデプロイメント記述子ファイルではなく、常にデプロイメント・プランを使用して、複数のデプロイメント構成を管理します。
アプリケーションの既存のデプロイメント・プランは各々、常にアプリケーション・ルート・ディレクトリの専用planサブディレクトリに格納します。
組織において、いくつかの環境に対し、標準化された繰返し行えるデプロイメントが必要とされている場合は、「単一のデプロイメント・プランを使用するアプリケーション」のワークフローを使用して、ソース・コントロール・システム内で単一のデプロイメント・プランを維持します。
WebLogic Server管理コンソールを使用して、アプリケーションのデプロイメント構成に大幅な変更を行う場合は、今後の使用に備えて、更新されたデプロイメント・プランのバックアップを作成するか、安全に格納します。複数環境の構成情報、およびアプリケーションの複数バージョンを維持できるよう、ソース・コントロール・システム内にアプリケーション・ルート・ディレクトリ全体を格納することをお薦めします。
