Oracle® Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ 11g リリース1 (10.3.6) B60988-04 |
|
前 |
次 |
次の項では、アプリケーションを本番WebLogic Server環境にデプロイするための構成方法について説明します。
通常、管理者やデプロイヤが開発チームまたは品質保証チームから新しいアプリケーションや新しいバージョンのアプリケーションを受け取る場合、アプリケーションは開発環境またはテスト環境用に構成されています。そのアプリケーションでは、特定のリソース名やパフォーマンス・チューニング設定(アプリケーションが最後にデプロイされた開発環境またはQA環境で使用されていたターゲット・サーバー上で利用可能なリソースに一致する名前や設定)が使用されている可能性があります。
開発環境およびテスト環境は、アプリケーションが最終的にデプロイされる本番環境とは著しく異なっている可能性があるため、管理者は本番環境について有効かつ適切なリソース名およびパフォーマンス・チューニング・パラメータを使用するように、アプリケーションを構成する必要があります。
アプリケーションのデプロイメント構成は、アプリケーションのライフサイクルにおいて、いくつかの時点で行われる可能性があります。デプロイメント構成の各フェーズでは一般に、様々なデプロイメント・ファイルの作成と処理が行われます。
開発構成 - 開発中、プログラマはアプリケーションまたはモジュールのJava EEデプロイメント記述子を作成します。プログラマは、また、WebLogic Server開発環境にデプロイするアプリケーションを構成するWebLogic Serverデプロイメント記述子を作成します。『Oracle WebLogic Serverアプリケーションの開発』を参照してください。
注意: WebLogic Server開発環境の外部で開発されたアプリケーション(たとえば、サンプル・アプリケーション、またはPetStoreなどサード・パーティのJava EEアプリケーション)には、Java EE記述子しか含まれていない場合があります。 |
エクスポート構成 - アプリケーションを開発からリリースする前に、プログラマまたは設計者は必要に応じて、アプリケーションのデプロイメント構成をWebLogic Serverデプロイメント・プランにエクスポートできます。構成のエクスポートによって、開発者がアプリケーションのWebLogic Serverデプロイメント記述子ファイルで定義したデプロイメント・プロパティの全部または一部のためのデプロイメント・プラン変数が作成されます。「新しい環境にデプロイするためのアプリケーションのエクスポート」を参照してください。
アプリケーションのエクスポートにより、組織における別分野のデプロイヤ(QAチームの技術者、本番管理者など)が、プログラマの開発環境とは異なる環境へ、アプリケーションを簡単にデプロイできるようになります。理想的なデプロイメント・プランには、新しい環境でアプリケーションをデプロイする前にデプロイヤが変更する必要のあるすべてのプロパティが含まれています。
デプロイメント時構成 - 管理者またはデプロイヤは、ターゲット環境にアプリケーションをデプロイする前に、アプリケーションの構成を行います。デプロイメント時構成では、以下を使用できます。
開発時に作成されたWeblogic Serverデプロイメント構成およびデプロイメント・プラン
これらの開発構成およびデプロイメント・プランの修正版
それぞれの組織のデプロイメント構成ワークフローに応じ、デプロイヤがその環境用に事前に作成したカスタム・デプロイメント・プラン
デプロイメント後構成 - アプリケーションがターゲット環境にデプロイされた後は、管理者またはデプロイヤは新しいデプロイメント・プランでの再デプロイメントによって、または管理コンソールを使用した既存のデプロイメント・プランの更新および再デプロイメントによって、アプリケーションを再構成できるようになります。「本番環境でのアプリケーションの再デプロイメント」および「デプロイされたアプリケーションの管理」を参照してください。
デプロイメント構成は、アプリケーションのライフサイクルにおける様々な時点で、様々な人間によって行われるため、管理者、デプロイヤ、および開発者は互いに協力して、繰返し実行できる構成ワークフローを組織のために作成する必要があります。「一般的なデプロイメント構成のワークフロー」を参照してください。
アプリケーションの基本的なデプロイメント構成は、デプロイメント記述子として知られる複数のXMLドキュメントで定義されます。これらは、デプロイメント用に提供されるアプリケーション・アーカイブ・ファイルの一部として用意されています。デプロイメント記述子ファイルは、別個の2つのカテゴリに分類されます。
Java EEデプロイメント記述子。アプリケーションのデプロイ先に関係なく、Java EEアプリケーションまたはモジュールの基本的構成および動作を定義します。各Java EEアプリケーションおよびモジュールには、Java EE 5仕様で定義されている特定のJava EEデプロイメント記述子が必要です。
WebLogic Serverデプロイメント記述子。特定のWebLogic Server環境でアプリケーションが使用するリソースの依存関係およびチューニング・パラメータを定義します。
本番デプロイメントを行うためには、Java EEとWebLogic Serverの双方のデプロイメント記述子を、開発チームが所有するアプリケーションのソース・コードの一部として扱う必要があります。本番環境にデプロイするアプリケーションの構成を行うために、アプリケーション・デプロイメント記述子を編集することはしないでください。かわりに、構成の変更をWebLogic Serverデプロイメント・プラン(次の項で説明)内に永続化します。
注意: DTDベースのデプロイメント記述子を使用するアプリケーションでデプロイメント・プランを使用することはできません。このアプリケーションは、スキーマ・ベースの記述子を使用するようアップグレードする必要があります。 |
WebLogic Serverデプロイメント・プランは、前述したように特定のWebLogic Server環境へのデプロイメント用にアプリケーションを構成するために使用する任意のXMLドキュメントです。デプロイメント・プランでは、通常はアプリケーションのWebLogic Serverデプロイメント記述子で定義するようなデプロイメント・プロパティ値の設定を指定したり、WebLogic Serverデプロイメント記述子ですでに定義されているプロパティ値をオーバーライドしたりします。アプリケーションをエクスポートするときに、デプロイメント・プランは通常、開発中に作成したWebLogic Serverデプロイメント記述子内の選択されたプロパティをオーバーライドするよう機能します。
通常は、開発者が関連アプリケーション・ファイルとともにデプロイメント・プランを作成し、管理者やデプロイヤに配布します。配布を受けた管理者やデプロイヤは、特定の環境(ステージング、テスト、本番など)にあわせてプランを更新します。デプロイメント・プランは、アプリケーション・アーカイブや展開されたアーカイブ・ディレクトリの外部に格納します。ベスト・プラクティスとしては、単一のアプリケーションの各デプロイメント・プランを、アプリケーションのルート・ディレクトリにおける、それぞれの専用plan
サブディレクトリに格納することをお薦めします(「アプリケーションのインストール・ディレクトリの作成」を参照)。
デプロイメント・プランを使用すると、管理者はアプリケーション・アーカイブに含まれているデプロイメント記述子ファイルを変更することなく、アプリケーションを複数の様々なWebLogic Server環境にデプロイするためのWebLogic Server構成を簡単に変更できます。構成の変更は、変更するWebLogic Server記述子プロパティの場所と、それらのプロパティに割り当てる値の双方を定義する、デプロイメント・プラン内の変数を追加または変更することによって適用されます。アプリケーションをデプロイしている管理者は、デプロイメント・プランを変更するのみで済みます。元のデプロイメント・ファイルとデプロイメント記述子は、変更されないままです(図4-1を参照)。それぞれの環境のデプロイメント構成ワークフローを決定するには、「一般的なデプロイメント構成のワークフロー」を参照してください。
管理者にとって、アプリケーションを本番デプロイメント用に構成する際の第一の目標は、ターゲットWebLogic Server環境に適した有効な新しいデプロイメント・プランを生成することです。具体的には、デプロイメント・プランはすべての外部リソース参照を解決し、アプリケーションがターゲット環境において使用可能である有効なリソースを参照するようにする必要があります。アプリケーションの構成でターゲット・サーバーについて有効な外部リソースが定義されていなければ、アプリケーションはデプロイできません。
デプロイメント・プランでは、必要に応じてWebLogic Serverチューニング・パラメータを定義またはオーバーライドして、ターゲット環境におけるリソースの理想的な使用方法を実現できます。チューニング・パラメータの定義は、アプリケーションのデプロイを正常に実行するために必須というわけではありません。アプリケーションのデプロイメント記述子とデプロイメント・プランで、チューニング・パラメータが定義されていなければ、WebLogic Serverはデフォルト値を使用します。
デプロイメント・プランを使用すると、複数のWebLogic Server環境にデプロイするためのアプリケーションの構成の、便利で繰返し可能なワークフローを定義できます。本番アプリケーションのための構成ワークフローには、デプロイ可能なアプリケーションを作成およびパッケージ化する開発および設計チームと、各ターゲットWebLogic Server環境の管理者またはデプロイヤとの間で協力が必要です。
組織のための理想的なデプロイメント構成ワークフローは、次の要素によって決まります。
同じアプリケーションをデプロイするそれぞれの環境の数
各ターゲット環境によって提供されるリソースの違い
各ターゲット環境の変更頻度
アプリケーションのJava EE構成の変更頻度
組織内の様々な分野における構成情報に対する所有権の要件
次の項では、デプロイメント・プランの管理、および複数のWebLogic Serverドメインへのアプリケーションのデプロイのための一般的なデプロイメント構成ワークフローについて説明します。
注意: デプロイメント・プランを使用してapplication.xmlファイルのcontext-rootを変更することはできません。ただし、アプリケーションがライブラリとしてデプロイされている場合、context-rootをweblogic-application.xmlファイルで直接変更する、またはデプロイメント・プランを使用して変更することができます。 |
様々なデプロイメント環境の正確な構成を理解している組織では、単一の精密に定義されたデプロイメント・プランを使用して、アプリケーションを複数のWebLogic Serverドメインにデプロイできます。単一デプロイメント・プランの構成ワークフローは、次のように機能します。
開発チームは、管理者およびデプロイヤと協力して、すべてのターゲット環境で使用するためのマスター・デプロイメント・プランを作成します。ターゲット環境の数は、組織の構成によって異なります。共通のデプロイメント環境には、1つまたは複数の品質保証(QA)またはテスト・ドメイン、ステージング・ドメイン、および本番ドメインが含まれます。
このフェーズでチームが作成するデプロイメント・プランは、ターゲット環境ごとに異なると分かっているすべての構成プロパティの変数を定義します。たとえばこのプランで、環境間で異なっており、アプリケーションがデプロイ可能になる前に構成が必要なリソース名のための空の変数を定義する場合があります。またこのプランでは、デプロイヤが環境において変更するかもしれない共通のチューニング・パラメータのデフォルト値を定義することもあります。
開発中におけるデプロイメント・プランの作成の詳細は、「新しい環境にデプロイするためのアプリケーションのエクスポート」を参照してください。
あるバージョンのアプリケーションのリリース準備が整うと、開発チームはそのアプリケーションのデプロイメント・ファイルをパッケージ化し、デプロイメント・ファイルとマスター・デプロイメント・ファイルの双方を、各ターゲット環境のデプロイヤに配信します。
各デプロイヤは、管理コンソールを使用してアプリケーションをインストールし、構成に使用するデプロイメント・プランを識別します。管理コンソールは、ターゲット・ドメインで使用可能なリソースに基づき、デプロイメント構成全体を検証します。その後、プランで定義されている構成可能なプロパティ(および、すべての無効なプロパティ)のリストを、編集のためにデプロイヤに提示します。
デプロイヤは、管理コンソールを使用して、デプロイメント・プランで定義されたプロパティを対話形式で構成します。null値、またはターゲットWebLogic Serverインスタンスまたはクラスタについて無効な値を持つデプロイメント・プラン変数を構成しないと、アプリケーションがデプロイ可能になりません。すでに有効な値を持つデプロイメント・プラン変数は、デプロイメント前に変更する必要はありません。
各環境のデプロイヤは、構成変更をデプロイメント・プランで定義されたプロパティのみに制限することに同意しています。追加の構成変更が必要な場合、デプロイヤはマスター・デプロイメント・プランを変更する開発または設計チームに、それらの必要性を伝えなくてはなりません。
単一デプロイメント・プランのワークフローを使用する利点は、次のとおりです。
開発または設計チームが、アプリケーションのデプロイメント構成を制御できます。
アプリケーションをターゲット環境にデプロイする際に、デプロイヤが行わなければならない構成上の判断の数が減少します。
アプリケーションと関連付けられた構成ファイルの数が最小限に留められ、デプロイメント構成情報のソース・コントロール・システムへの格納が容易になります。
全般に、単一デプロイメント・プランのワークフローを使用するのは、組織におけるターゲット環境が少数かつ詳しく理解されており、各環境で標準化されたデプロイメント構成を簡単にレプリケートする必要がある場合です。
単一のデプロイメント・プランのワークフローでは、開発または設計チームが、デプロイメント・プランの所有権を保持しており、デプロイヤがプランに対して行える変更は、プラン内で定義される変数に限定されていることを前提としています。デプロイヤが、デプロイメント・プランで定義されているプロパティのみを変更する場合、それらの変更は変数の更新として、同じデプロイメント・プランに書き戻されます。
しかし、WebLogic Serverでは、デプロイヤが管理コンソールを使用して変更できる構成プロパティに関しては、制限を設けていません。デプロイヤが、元来はプラン内で定義されていなかったデプロイメント・プロパティを構成する場合、管理コンソールは変数エントリが追加された新しいデプロイメント・プランを生成し、その新しいプランを、デプロイメントまたは再デプロイメント操作に使用します。これによりデプロイヤが、開発チーム所有のマスター・デプロイメント・プランとは大幅に異なるデプロイメント・プランを使用するという状況が生じる可能性があります。
マスター・デプロイメント・プランに新しく変更を組み込むには、デプロイヤは管理コンソールによって作成されカスタマイズされた、新しいデプロイメント・プランを取得します。理想的には、これらの変更は、マスター・デプロイメント・プランに適用されます。
頻繁に変更される数多くのデプロイメント環境を有する組織では、複数のデプロイメント・プランを備える構成ワークフローを使用する必要があります。複数デプロイメント・プランのワークフローでは、各デプロイメント・プランは開発チームではなく、アプリケーションのデプロイヤが所有しています。複数デプロイメント・プランの構成ワークフローは、次のように機能します。
開発チームは、あるバージョンのパッケージ化されたアプリケーション・デプロイメント・ファイル(Java EEおよびWebLogic Server記述子を含む)をリリースします。リソース定義のためのエクスポートされた変数、または共通のチューニング可能なパラメータを備えるテンプレート・デプロイメント・プランは、これに含めても含めなくてもかまいません。
アプリケーションをデプロイする前に、各デプロイヤは、ターゲット環境用にアプリケーションを構成するためのカスタム・デプロイメント・プランを生成します。
カスタム・デプロイメント・プランの作成は、テンプレートのデプロイメント・プラン(またはデプロイメント・プランなしで)により開始し、管理コンソールを使用してアプリケーションのデプロイメント構成に変更を加えることが可能です。Oracle WebLogic Server管理コンソール・ヘルプの「デプロイメント・プランの更新」を参照してください。
環境にあわせてデプロイメント構成を定義後、各デプロイヤはカスタム・デプロイメント・プランを取得して、それをアプリケーションの将来的なデプロイメントに備えて維持します。カスタム構成プランは、必要に応じて新しいバージョンを追跡したり元に戻したりできるように、ソース・コントロール・システムに格納することをお薦めします。
その後のリリースでは、各デプロイヤはカスタマイズされたデプロイメント・プランを使用して、アプリケーションをデプロイメントのために構成します。カスタマイズされたプランを使用すると、デプロイヤはweblogic.Deployer
でデプロイメントを実行したり、WLSTでデプロイメントを自動化したりできます。
複数デプロイメント・プランのワークフローを使用する利点は、次のとおりです。
管理者またはデプロイヤが、アプリケーションの構成と環境の構成を両方とも一緒に管理できるようになります。
デプロイヤが、アプリケーションをグローバルに構成するカスタム・プランを使用して、デプロイメント・プロセスを自動化できます。
全般に、複数デプロイメント・プランのワークフローを使用するのは、組織におけるデプロイメント環境の数が多く、頻繁に変更されるために単一のマスター・デプロイメント・プランを維持することが困難または不可能である場合です。
複数デプロイメント・プランのワークフローでは、(プログラミングあるいは設計チームではなく)デプロイヤまたは管理者が、アプリケーション用にデプロイメント構成を所有し管理するものと想定します。また、アプリケーションの基本的なJava EEの構成はほとんど変更しないことを想定しますが、それは特定のJava EEの構成変更が、デプロイヤのカスタム構成プランを無効にするためです。たとえば、エンタープライズ・アプリケーションのモジュールを追加、削除または変更する場合、モジュールを参照しているカスタム・デプロイメント・プランは無効になります。この場合、各デプロイヤは管理コンソールを使用し、アプリケーションを構成することにより、カスタム・プランを再作成する必要があります。
管理コンソールは、ドメインにインストールしたアプリケーションのデプロイメント・プロパティを対話形式で変更すると、アプリケーションの有効なXMLデプロイメント・プランを自動的に生成(または更新)します。生成されたデプロイメント・プランを後のデプロイメントにおけるアプリケーションの構成に使用することもできますし、デプロイメント・プロパティを繰返し編集および保存することで新しいバージョンのデプロイメント・プランを生成することもできます。
注意:
|
管理コンソールを使用してのデプロイメント・プランの生成は、次の手順を伴います。
次の項では、各手順についてWebLogic Serverサンプル・アプリケーションjspExpressionEar.ear
を使用して説明します。
次の手順にしたがって、デプロイメント用のアプリケーションを準備します。
アプリケーションをデプロイするための新しいルート・ディレクトリと、app
およびplan
サブディレクトリを作成します。例:
mkdir c:\sample_root mkdir c:\sample_root\app mkdir c:\sample_root\plan
WebLogic Serverサンプル・アプリケーションjspExpressionEar.ear
をダウンロードします。ファイルの保存先は、必ずステップ1で作成したc:\sample_root\app
を選択してください。
管理コンソールでは、アプリケーション・インストール・アシスタントを使用して、新しいWebLogic Server環境に構成およびデプロイする新しいアプリケーションを簡単にインストールできます。アプリケーションまたはモジュールをインストールしてデプロイメント・ターゲットを選択すると、WebLogic Serverドメインでデプロイメント・ファイルが使用可能になり、必要に応じて構成、配布、およびデプロイできます。
サンプル・サーバー・ドメインにサンプル・アプリケーションをインストールするには、次の手順に従います。
Windowsの[スタート]メニューを使用して、またはWL_HOME
\samples\domains\wl_server\startWebLogic.cmd
スクリプトを実行して、WebLogicサンプル・サーバーを起動します。
ブラウザでhttp://localhost:7001/console
を指定して管理コンソールにアクセスします。
管理コンソールにログインします。
アプリケーションをインストールするには、Oracle WebLogic Server管理コンソール・ヘルプの「アプリケーションおよびモジュールのインストール」か、「デプロイメント・ファイルの準備」でダウンロードしたjspExpressionEar.ear
サンプル・アプリケーションの手順に従います。
管理コンソールを使用して、「アプリケーション・アーカイブをインストールする」でインストールしたアプリケーションのデプロイメント構成プロパティを編集し、構成をデプロイメント・プランに保存します。たとえば、jspExpressionEar.ear
サンプル・アプリケーションの以下のようなプロパティを変更できます。
「構成」ページで、1つ以上の構成プロパティを編集します。たとえば、「セッション無効化間隔」を80秒に、「セッション・タイムアウト」を8000秒に変更します。
[保存]をクリックして変更を保存します。管理コンソールは、構成の変更を新しいデプロイメント・プランに格納します。ルート・ディレクトリからサンプル・アプリケーションをデプロイした場合、管理コンソールは新しいデプロイメント・プランを自動的にルート・ディレクトリの\plan
サブディレクトリに入れます。たとえば、c:\sample_root\plan\Plan.xml
となります。
「アプリケーションを構成するための新しいデプロイメント・プランの作成」で生成したデプロイメント・プランには、「サンプル・デプロイメント・プラン」に示すエントリが含まれています。
例 4-1サンプル・デプロイメント・プラン
<deployment-plan xmlns="http://www.bea.com/ns/weblogic/90"> <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>jspExpressionEar.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>jspExpressionWar</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でも可)を定義します。「サンプル・デプロイメント・プラン」に示すサンプル・プランには、[セッション無効化間隔]および[セッション・タイムアウト]プロパティに加えた変更に対する変数定義が含まれます。
module-override
要素。デプロイメント・プランがオーバーライドする、各モジュールの名前、種類、およびデプロイメント記述子を定義します。module-descriptor
要素には、必要に応じて、記述子内のプロパティのオーバーライドに使用される変数名を識別するvariable-assignment
、およびプロパティがオーバーライドされる記述子内の正確な場所を含めることができます。
「サンプル・デプロイメント・プラン」に示しているサンプル・プランは、エンタープライズ・アプリケーション、組込みのWebアプリケーション、および同梱したルート・ディレクトリ用に、モジュール・オーバーライド要素が含まれています。weblogic.xml
記述子ファイルのモジュール記述子エントリは、2つの変数割当
要素を含み、「構成変更をデプロイメント・プランに保存」で変更した「セッション無効化間隔」、および「セッション・タイムアウト」のプロパティ値をオーバーライドします。
デフォルトでは、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.0/deployment-plan.xsd
を参照してください。
デプロイメント用に受け取るアプリケーションは、構成情報の可変レベルを備えている可能性があります。アプリケーションに現行の構成プランがある場合、「デプロイメント・ファイルの準備」で説明しているように単にアプリケーションを準備し、アプリケーション・ルートのplan
サブディレクトリにデプロイメント・プランを配置します。次に、「アプリケーション・アーカイブをインストール」の命令を使用し、アプリケーションをインストールします。管理コンソールは1つのプランが有効であれば、アプリケーション・ルート・ディレクトリの\plan
サブディレクトリで、自動的にplan.xml
という名称のデプロイメント・プランを使用します。アプリケーションで複数のプランが有効であれば、それらは\plan
サブディレクトリ(たとえば\plan1
および\plan2
)に配置され、管理コンソールはそれらを認識できません。したがってconfig.xml
は使用するプランを指定する必要があります。config.xml
の詳細は、『Oracle WebLogic Serverドメイン構成の理解』の「ドメイン構成ファイル」を参照してください。
新しいアプリケーションおよび既存のデプロイメント・プランをインストール後、管理コンソールはデプロイメント・プランの構成を、インストールの際に選択されたターゲット・サーバーおよびクラスタと比較して検証します。デプロイメント・プランに、空(null)の変数が格納されている、またはデプロイメント・プランで構成された値の中に、ターゲット・サーバー・インスタンスについて有効でないものがある場合は、デプロイメント・プランをオーバーライドしてからでなければ、アプリケーションをデプロイすることはできません。また、「デプロイメント・プランに構成の変更を保存する」で説明したように、アプリケーションをデプロイするターゲット環境に、よりよく適合させるため、チューニング・パラメータを構成することも可能です。アプリケーションの構成に対して加えた変更は、新しいデプロイメント・プランに保存されます。
アプリケーションの構成がデプロイ先の環境に対して完全に適合している有効なデプロイメント・プランがある場合は、管理コンソールとweblogic.Deployer
ユーティリティのどちらかを使用して、デプロイメントに使用するデプロイメント・プランでアプリケーションをデプロイできます。
注意: weblogic.Deployerユーティリティで使用するデプロイメント・プランはいずれも完全なものであり、ターゲット・サーバーについて有効であることが必要です。weblogic.PlanGeneratorでは、プランの作成時に個々のデプロイメント・プロパティを設定またはオーバーライドすることはできません。weblogic.Deployerを使用して、新しいアプリケーションおよび既存のデプロイメント・プランをデプロイするには、「デプロイメント・プランによるアプリケーションのデプロイ」を参照してください。 |
この機能により、アプリケーション固有のファイルを配置し、既存のプラン・ディレクトリ構造で、新しいオプションのサブディレクトリ(名前は/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
の構造が与えられます。
例:
重要なことは、アプリケーションは、ファイルの内容および形式を制御し、アプリケーション・コードによってファイルの内容へのアクセスを制御するということです。ベスト・プラクティスは、汎用ファイル・ロード・オーバーライドを、環境固有のプロパティ・ファイルを指定したアプリケーション・コードで使用し、それらのプロパティ・ファイルをアプリケーションのクラスローダーを使用してリソースとしてロードすることです。以下に、アプリケーション・コードによって実行可能な例を示します。
Properties myAppProps = new Properties(); InputStream iostream = Thread.currentThread().getContextClassLoader().getResourceAsStream("myCfg/myApp.properties"); myAppProps.load(iostream);
その他のデプロイメント構成タスクについては、次の項を参照してください。
「デプロイメント・プランによるアプリケーションのデプロイ」。weblogic.Deployer
ツールを使用して、有効なデプロイメント・プランとともにアプリケーションをデプロイする方法について説明します。付録A「weblogic.Deployerコマンド・ライン・リファレンス」を参照してください。
「アプリケーションのデプロイメント構成の更新」。現在デプロイされているアプリケーションのデプロイメント構成を更新する方法について説明します。
「新しい環境にデプロイするためのアプリケーションのエクスポート」。開発者が、weblogic.PlanGenerator
ツールを使用してポータブル・デプロイメント・プランを作成できる方法について説明します。
「weblogic.PlanGeneratorコマンド・ライン・リファレンス」。weblogic.PlanGenerator
ツールに関する詳細なリファレンスを提供します。
複数バージョンのWebLogic Serverデプロイメント記述子ファイルではなく、常にデプロイメント・プランを使用して、複数のデプロイメント構成を管理します。
アプリケーションの既存のデプロイメント・プランは各々、常にアプリケーション・ルート・ディレクトリの専用plan
サブディレクトリに格納します。
組織において、いくつかの環境に対し、標準化された繰返し行えるデプロイメントが必要とされている場合は、「単一のデプロイメント・プランを使用するアプリケーション」のワークフローを使用して、ソース・コントロール・システム内で単一のデプロイメント・プランを維持します。
管理コンソールを使用して、アプリケーションのデプロイメント構成に大幅な変更を行う場合は、今後の使用に備えて、更新されたデプロイメント・プランのバックアップを作成するか、安全に格納しておく。複数環境の構成情報、およびアプリケーションの複数バージョンを維持できるよう、ソース・コントロール・システム内にアプリケーション・ルート・ディレクトリ全体を格納することをお薦めします。