| Oracle Fusion Middleware Oracle WebLogic Server アプリケーションのデプロイメント 11g リリース 1 (10.3.1) B55511-01 |
|
 戻る |
 次へ |
| Oracle Fusion Middleware Oracle WebLogic Server アプリケーションのデプロイメント 11g リリース 1 (10.3.1) B55511-01 |
|
戻る |
次へ |
以下の節では、アプリケーションをプロダクション WebLogic Server 環境にデプロイするためのコンフィグレーション方法について説明します。
通常、管理者やデプロイヤが開発チームまたは品質保証チームから新しいアプリケーションや新しいバージョンのアプリケーションを受け取る場合、アプリケーションは開発環境またはテスト環境用にコンフィグレーションされています。そのアプリケーションでは、特定のリソース名やパフォーマンス チューニング設定 (アプリケーションが最後にデプロイされた開発環境または QA 環境で使用されていた対象サーバ上で利用可能なリソースに一致する名前や設定) が使用されている可能性があります。
開発環境およびテスト環境は、アプリケーションが最終的にデプロイされるプロダクション環境とは著しく異なっている可能性があるため、管理者はプロダクション環境について有効かつ適切なリソース名およびパフォーマンス チューニング パラメータを使用するように、アプリケーションをコンフィグレーションする必要があります。
アプリケーションのデプロイメント コンフィグレーションは、アプリケーションのライフサイクルにおいて、いくつかの時点で行われる可能性があります。デプロイメント コンフィグレーションの各フェーズでは一般に、さまざまなデプロイメント ファイルの作成と処理が行われます。
デプロイメント コンフィグレーション - 開発中、プログラマはアプリケーションまたはモジュールの J2EE デプロイメント記述子を作成します。プログラマはまた、WebLogic Server デプロイメント記述子も作成して、アプリケーションを WebLogic Server 開発環境にデプロイするためにコンフィグレーションします。『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションの開発』を参照してください。
|
注意 : WebLogic Server 開発環境の外部で開発されたアプリケーション (たとえばサンプル アプリケーション、または PetStore などサードパーティの J2EE アプリケーション) には、J2EE 記述子しか含まれていない場合があります。 |
エクスポート コンフィグレーション - アプリケーションを開発からリリースする前に、プログラマまたは設計者は必要に応じて、アプリケーションのデプロイメント コンフィグレーションを WebLogic Server デプロイメント プランにエクスポートできます。コンフィグレーションのエクスポートによって、開発者がアプリケーションの WebLogic Server デプロイメント記述子ファイルで定義したデプロイメント プロパティの全部または一部のためのデプロイメント プラン変数が作成されます。「新しい環境にデプロイするためのアプリケーションのエクスポート」を参照してください。
アプリケーションのエクスポートにより、組織における別分野のデプロイヤ (QA チームの技術者、プロダクション管理者など) が、プログラマの開発環境とは異なる環境へ、アプリケーションを簡単にデプロイできるようになります。理想的なデプロイメント プランには、新しい環境でアプリケーションをデプロイする前にデプロイヤが変更する必要のあるすべてのプロパティが含まれています。
デプロイメント時コンフィグレーション - 管理者またはデプロイヤは、対象環境にアプリケーションをデプロイする前に、アプリケーションのコンフィグレーションを行います。デプロイメント時コンフィグレーションでは、以下を使用できます。
開発時に作成された Weblogic Server デプロイメント コンフィグレーションおよびデプロイメント プラン
これらの開発コンフィグレーションおよびデプロイメント プランの修正版
それぞれの組織のデプロイメント コンフィグレーション ワークフローに応じ、デプロイヤがその環境用に事前に作成したカスタム デプロイメント プラン
「weblogic.Deployer によるアプリケーションおよびモジュールのデプロイ」を参照してください。
デプロイメント後コンフィグレーション - アプリケーションが対象環境にデプロイされた後は、管理者またはデプロイヤは新しいデプロイメント プランでの再デプロイメントによって、または Administration Console を使用した既存のデプロイメント プランの更新および再デプロイメントによって、アプリケーションを再コンフィグレーションできるようになります。「プロダクション環境でのアプリケーションの再デプロイメント」および「デプロイされたアプリケーションの管理」を参照してください。
デプロイメント コンフィグレーションは、アプリケーションのライフサイクルにおけるさまざまな時点で、さまざまな人間によって行われるため、管理者、デプロイヤ、および開発者は互いに協力して、繰り返し実行できるコンフィグレーション ワークフローを組織のために作成する必要があります。「一般的なデプロイメント コンフィグレーションのワークフロー」を参照してください。
アプリケーションの基本的なデプロイメント コンフィグレーションは、デプロイメント記述子として知られる複数の XML ドキュメントで定義されます。これらは、デプロイメント用に提供されるアプリケーション アーカイブ ファイルの一部として用意されています。デプロイメント記述子ファイルは、別個の 2 つのカテゴリに分類されます。
J2EE デプロイメント記述子。アプリケーションのデプロイ先に関係なく、J2EE アプリケーションまたはモジュールの基本的構成および動作を定義します。各 J2EE アプリケーションおよびモジュールには、Java EE 5 仕様で定義されている特定の J2EE デプロイメント記述子が必要です。
WebLogic Server デプロイメント記述子。特定の WebLogic Server 環境でアプリケーションが使用するリソースの依存関係およびチューニング パラメータを定義します。
プロダクション デプロイメントを行うためには、J2EE と 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 環境の管理者またはデプロイヤとの間で協力が必要です。
組織のための理想的なコンフィグレーション ワークフローは、次の要素によって決まります。
同じアプリケーションをデプロイするそれぞれの環境の数
各対象環境によって提供されるリソースの違い
各対象環境の変更頻度
アプリケーションの J2EE コンフィグレーションの変更頻度
組織内のさまざまな分野におけるコンフィグレーション情報に対する所有権の要件
以下の節では、デプロイメント プランの管理、および複数の WebLogic Server ドメインへのアプリケーションのデプロイのための一般的なデプロイメント コンフィグレーション ワークフローについて説明します。
|
注意 : デプロイメント プランを使用して application.xml ファイルの context-root を変更することはできません。ただし、アプリケーションがライブラリとしてデプロイされている場合、context-root を weblogic-application.xml ファイルで直接変更する、またはデプロイメント プランを使用して変更することができます。 |
さまざまなデプロイメント環境の正確なコンフィグレーションを理解している組織では、単一の精密に定義されたデプロイメント プランを使用して、アプリケーションを複数の WebLogic Server ドメインにデプロイできます。単一デプロイメント プランのコンフィグレーション ワークフローは、次のように機能します。
開発チームは、管理者およびデプロイヤと協力して、すべての対象環境で使用するためのマスター デプロイメント プランを作成します。対象環境の数は、組織の構成によって異なります。共通のデプロイメント環境には、1 つまたは複数の品質保証 (QA) またはテスト ドメイン、ステージング ドメイン、およびプロダクション ドメインが含まれます。
このフェーズでチームが作成するデプロイメント プランは、対象環境ごとに異なると分かっているすべてのコンフィグレーション プロパティの変数を定義します。たとえばこのプランで、環境間で異なっており、アプリケーションがデプロイ可能になる前にコンフィグレーションが必要なリソース名のための空の変数を定義する場合があります。またこのプランでは、デプロイヤが環境において変更するかもしれない共通のチューニング パラメータのデフォルト値を定義することもあります。
開発中におけるデプロイメント プランの作成の詳細については、「新しい環境にデプロイするためのアプリケーションのエクスポート」を参照してください。
あるバージョンのアプリケーションのリリース準備が整うと、開発チームはそのアプリケーションのデプロイメント ファイルをパッケージ化し、デプロイメント ファイルとマスター デプロイメント ファイルの双方を、各対象環境のデプロイヤに配信します。
各デプロイヤは、Administration Console を使用してアプリケーションをインストールし、コンフィグレーションに使用するデプロイメント プランを識別します。Administration Console は、対象ドメインで使用可能なリソースに基づき、デプロイメント コンフィグレーション全体を検証します。その後、プランで定義されているコンフィグレーション可能なプロパティ (および、すべての無効なプロパティ) のリストを、編集のためにデプロイヤに提示します。
デプロイヤは、Administration Console を使用して、デプロイメント プランで定義されたプロパティを対話形式でコンフィグレーションします。null 値、または対象 WebLogic Server インスタンスまたはクラスタについて無効な値を持つデプロイメント プラン変数をコンフィグレーションしないと、アプリケーションがデプロイ可能になりません。すでに有効な値を持つデプロイメント プラン変数は、デプロイメント前に変更する必要はありません。
各環境におけるデプロイヤは、コンフィグレーションを変更できるのはデプロイメント プランで定義されたプロパティのみと制限することに同意しています。それ以上のコンフィグレーション変更が必要な場合、デプロイヤはマスター デプロイメント プランを変更する開発または設計チームに、それらの要求を伝える必要があります。
単一デプロイメント プランのワークフローを使用する利点は、次のとおりです。
開発または設計チームが、アプリケーションのデプロイメント コンフィグレーションを制御できる。
アプリケーションを対象環境にデプロイする際に、デプロイヤが行わなければならないコンフィグレーション上の判断の数が減少する。
アプリケーションと関連付けられたコンフィグレーション ファイルの数が最小限に留められ、デプロイメント コンフィグレーション情報のソース コントロール システムへの格納が容易になる。
全般に、単一デプロイメント プランのワークフローを使用するのは、組織における対象環境が少数かつ詳しく理解されており、各環境で標準化されたデプロイメント コンフィグレーションを簡単にレプリケートする必要がある場合です。
単一のデプロイメント プランのワークフローでは、開発または設計チームが、デプロイメント プランの所有権を保持しており、デプロイヤがプランに対して行える変更は、プラン内で定義される変数に限定されていることを前提としています。デプロイヤが、デプロイメント プランで定義されているプロパティのみを変更する場合、それらの変更は変数の更新として、同じデプロイメント プランに書き戻されます。
しかし、WebLogic Server では、デプロイヤが Administration Console を使用して変更できるコンフィグレーション プロパティに関しては、制限を設けていません。デプロイヤが、元来はプラン内で定義されていなかったデプロイメント プロパティをコンフィグレーションする場合、Administration Console は変数エントリが追加された新しいデプロイメント プランを生成し、その新しいプランを、デプロイメントまたは再デプロイメント操作に使用します。これによりデプロイヤが、開発チーム所有のマスター デプロイメント プランとは大幅に異なるデプロイメント プランを使用するという状況が生じる可能性があります。
マスター デプロイメント プランに新しく変更を組み込むには、デプロイヤは Administration Console によって作成されカスタマイズされた、新しいデプロイメント プランを取得します。理想的には、これらの変更は、マスター デプロイメント プランに適用されます。
頻繁に変更される数多くのデプロイメント環境を有する組織では、複数のデプロイメント プランを備えるコンフィグレーション ワークフローを使用する必要があります。複数デプロイメント プランのワークフローでは、各デプロイメント プランは開発チームではなく、アプリケーションのデプロイヤが所有しています。複数デプロイメント プランのコンフィグレーション ワークフローは、次のように機能します。
開発チームは、あるバージョンのパッケージ化されたアプリケーション デプロイメント ファイル (J2EE および WebLogic Server 記述子を含む) をリリースします。リソース定義のためのエクスポートされた変数、または共通のチューニング可能なパラメータを備えるテンプレート デプロイメント プランは、これに含めても含めなくてもかまいません。
アプリケーションをデプロイする前に、各デプロイヤは、対象環境用にアプリケーションをコンフィグレーションするためのカスタム デプロイメント プランを生成します。
カスタム デプロイメント プランの作成は、テンプレート デプロイメント プランから (またはデプロイメント プランなしで) 開始して、Administration Console を使用しアプリケーションのデプロイメント コンフィグレーションに変更を加えることで行えます。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「デプロイメント プランの更新」を参照してください。
環境に合わせてデプロイメント コンフィグレーションを定義後、各デプロイヤはカスタム デプロイメント プランを取得して、それをアプリケーションの将来的なデプロイメントに備えて維持します。カスタム コンフィグレーション プランは、必要に応じて新しいバージョンを追跡したり元に戻したりできるように、ソース コントロール システムに格納することをお勧めします。
その後のリリースでは、各デプロイヤはカスタマイズされたデプロイメント プランを使用して、アプリケーションをデプロイメントのためにコンフィグレーションします。カスタマイズされたプランを使用すると、デプロイヤは weblogic.Deployer でデプロイメントを実行したり、WLST でデプロイメントを自動化したりできます。
複数デプロイメント プランのワークフローを使用する利点は、次のとおりです。
管理者またはデプロイヤが、アプリケーションのコンフィグレーションと環境のコンフィグレーションを両方とも一緒に管理できるようになる。
デプロイヤが、アプリケーションを全面的にコンフィグレーションするカスタム プランを使用して、デプロイメント プロセスを自動化できる。
全般に、複数デプロイメント プランのワークフローを使用するのは、組織におけるデプロイメント環境の数が多く、頻繁に変更されるために単一のマスター デプロイメント プランを維持することが困難または不可能である場合です。
複数デプロイメント プランのワークフローでは、デプロイヤまたは管理者 (プログラミングまたは設計チームではない) が、アプリケーションのデプロイメント コンフィグレーションを所有および維持することが前提となっています。また、アプリケーションの基本の J2EE コンフィグレーションは滅多に変更されないものと想定されています。これは、J2EE コンフィグレーションに、ある特定の変更が加えられるとデプロイヤのカスタム コンフィグレーション プランが無効になってしまうからです。たとえば、エンタープライズ アプリケーション内のモジュールが追加、削除、または変更された場合、そのモジュールを参照するカスタム デプロイメント プランは無効になります。この場合、各デプロイヤは Administration Console を使用してアプリケーションをコンフィグレーションすることで、カスタム プランを再作成する必要があります。
Administration Console は、ドメインにインストールしたアプリケーションのデプロイメント プロパティを対話形式で変更すると、アプリケーションの有効な XML デプロイメント プランを自動的に生成 (または更新) します。生成されたデプロイメント プランを後のデプロイメントにおけるアプリケーションのコンフィグレーションに使用することもできますし、デプロイメント プロパティを繰り返し編集および保存することで新しいバージョンのデプロイメント プランを生成することもできます。
|
注意 :
|
Administration Console を使用してのデプロイメント プランの生成は、次の手順を伴います。
以降の節では、各手順について 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 を選択してください。
Administration Console では、アプリケーション インストール アシスタントを使用して、新しい WebLogic Server 環境にコンフィグレーションおよびデプロイする新しいアプリケーションを簡単にインストールできます。アプリケーションまたはモジュールをインストールしてデプロイメント対象を選択すると、WebLogic Server ドメインでデプロイメント ファイルが使用可能になり、必要に応じてコンフィグレーション、分散、およびデプロイできます。
サンプル サーバ ドメインにサンプル アプリケーションをインストールするには、次の手順に従います。
Windows の [スタート] メニューを使用して、または WL_HOME\samples\domains\wl_server\startWebLogic.cmd スクリプトを実行して、WebLogic サンプル サーバを起動します。
ブラウザで http://localhost:7001/console を指定して Administration Console にアクセスします。
Administration Console にログインします。
Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「アプリケーションおよびモジュールのインストール」に記載の手順に従い、独自のアプリケーション、または、「デプロイメント ファイルを準備する」でダウンロードした jspExpressionEar.ear サンプル アプリケーションをインストールします。
Administration Console を使用して、「アプリケーション アーカイブをインストールする」でインストールしたアプリケーションのデプロイメント コンフィグレーション プロパティを編集し、コンフィグレーションをデプロイメント プランに保存します。たとえば、jspExpressionEar.ear サンプル アプリケーションの以下のようなプロパティを変更できます。
[コンフィグレーション] ページで、1 つまたは複数のコンフィグレーション プロパティを編集します。たとえば、[セッション無効化間隔] を 80 秒に、[セッション タイムアウト] を 8000 秒に変更します。
[保存] をクリックして変更を保存します。Administration Console は、コンフィグレーションの変更を新しいデプロイメント プランに格納します。ルート ディレクトリからサンプル アプリケーションをデプロイした場合、Administration Console は新しいデプロイメント プランを自動的にルート ディレクトリの \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 記述子ファイルの 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.0/deployment-plan.xsd を参照してください。
デプロイメントのために受け取ったアプリケーションはさまざまなレベルのコンフィグレーション情報を伴っていると考えられます。アプリケーションの既存のデプロイメント プランがある場合は、単純に「デプロイメント ファイルを準備する」で説明したようにアプリケーションを準備し、デプロイメント プランをアプリケーション ルートの plan サブディレクトリに入れます。その後、「アプリケーション アーカイブをインストールする」に記載の手順でアプリケーションをインストールします。Administration Console は、アプリケーションのルート ディレクトリの \plan サブディレクトリ内に plan.xml という名前のデプロイメント プランがあれば、それを自動的に使用します。アプリケーション用に使用できるプランが複数ある場合、それらはそれぞれ専用の \plan サブディレクトリ (たとえば \plan1 および \plan2) に入れられ、Administration Console ではそれらを識別することができません。したがって、config.xml の中で、使用するプランを指定する必要があります。config.xml の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server ドメインのコンフィグレーションについて』の「ドメイン コンフィグレーション ファイル」を参照してください。
新しいアプリケーションおよび既存のデプロイメント プランをインストール後、Administration Console はデプロイメント プランのコンフィグレーションを、インストールの際に選択された対象サーバおよびクラスタと比較して検証します。デプロイメント プランに、空 (null) の変数が格納されている、またはデプロイメント プランでコンフィグレーションされた値の中に、対象サーバ インスタンスについて有効でないものがある場合は、デプロイメント プランをオーバーライドしてからでなければ、アプリケーションをデプロイすることはできません。また、「デプロイメント プランにコンフィグレーションの変更を保存する」で説明したように、アプリケーションをデプロイする対象環境に、よりよく適合させるため、チューニング パラメータをコンフィグレーションすることも可能です。アプリケーションのコンフィグレーションに対して加えた変更は、新しいデプロイメント プランに保存されます。
アプリケーションのコンフィグレーションがデプロイ先の環境に対して完全に適合している有効なデプロイメント プランがある場合は、Administration Console と weblogic.Deployer ユーティリティのどちらかを使用して、デプロイメントに使用するデプロイメント プランでアプリケーションをデプロイできます。
|
注意 : weblogic.Deployer ユーティリティで使用するデプロイメント プランはいずれも完全なものであり、対象サーバについて有効であることが必要です。weblogic.PlanGenerator では、プランの作成時に個々のデプロイメント プロパティを設定またはオーバーライドすることはできません。weblogic.Deployer を使用して、新しいアプリケーションおよび既存のデプロイメント プランをデプロイするには、「デプロイメント プランによるアプリケーションのデプロイ」を参照してください。 |
この機能を使用すると、アプリケーション固有のファイルを、既存のプラン ディレクトリ構造の新しいオプションのサブディレクトリ (/AppFileOverrides) にオーバーライドできます。デプロイメントでファイル オーバーライドが有効になるかどうかは、この新しいオプションのサブディレクトリが存在するかどうかによります。このサブディレクトリが存在すれば、デプロイメントのためのアプリケーション ClassLoader およびモジュール ClassLoader の前に内部 ClassFinder が追加されます。その結果、ファイル オーバーライドの階層ルールは、アプリケーションに対する既存の ClassLoader およびリソースのロード ルールおよび動作に従います。WLS アプリケーションのクラスローディングの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションの開発』の「WebLogic Server アプリケーションのクラスローディングについて」を参照してください。
|
注意 : このメカニズムは、リソースのオーバーライドのみであり、クラスについてはオーバーライドしません。 |
これらはアプリケーション固有のファイルであり、その内容は WLS に非透過的なため、オーバーライド ファイルが指定されるとファイルの内容全体がオーバーライドされます。
/AppFileOverrides サブディレクトリに配置されたファイルは、プラン ディレクトリのその他の内容とともにステージングおよび配布され、すべての対象で利用できます。アプリケーションは、現在の ClassLoader (ClassLoader.getResourceAsStream メソッドなど) を使用してこれらのファイルをリソースとしてロードできます。この場合、コンフィグレーションや、オーバーライド対象のファイルが指定されているかどうかに基づいて、オーバーライド対象のファイルやアプリケーションにパッケージされるファイルが特定されます。
Web アプリケーションの場合、アプリケーション ファイル オーバーライドは、クラスパスに関連付けられた (WEB-INF/classes および WEB-INF/lib に存在する) リソースにのみ適用され、Web アプリケーションのリソース パスに対しては適用されません。したがって、オーバーライドは、Web アプリケーションが classloader.getResourceAsStream() メソッドを使用してリソースをルックアップする場合には適用されますが、ServletContext.getResourceAsStream() メソッドを呼び出す場合には適用されません。
この機能を使用するには、以下を行う必要があります。
デプロイメント プランを指定する (「アプリケーションをコンフィグレーションするための新しいデプロイメント プランの作成」を参照)。
プラン内に config-root を指定する。
config-root/AppFileOverrides サブディレクトリを指定する。
/AppFileOverrides サブディレクトリの内容には、既存のプラン ディレクトリ構造と、記述子のオーバーライド用にすでに存在するディレクトリ命名規約が適用されます。ディレクトリ命名規約については、「デプロイするファイルのパッケージ化」を参照してください。
アプリケーション ファイル オーバーライドを有効にすると、アプリケーション レベルおよびモジュール レベルの ClassLoader にディレクトリ ClassFinder が追加されます。ClassFinder は、(プラン ディレクトリに含まれる) /AppFileOverrides サブディレクトリ内の適切なルート ディレクトリを指します。アプリケーションの ClassLoader の前に挿入される ClassFinder の構造は、AppDeploymentMBean.getLocalPlanDir + セパレータ + "/AppFileOverrides" のようになります。モジュールの ClassLoader の前に挿入される ClassFinder の構造は、AppDeploymentMBean.getLocalPlanDir + セパレータ + "/AppFileOverrides" + セパレータ + moduleURI のようになります。
以下に例を示します。
重要なことは、アプリケーションは、ファイルの内容および形式を制御し、アプリケーション コードによってファイルの内容へのアクセスを制御するということです。ベスト プラクティスは、汎用ファイル ロード オーバーライドを、環境固有のプロパティ ファイルを指定したアプリケーション コードで使用し、それらのプロパティ ファイルをアプリケーションのクラスローダを使用してリソースとしてロードすることです。以下に、アプリケーション コードによって実行可能な例を示します。
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 サブディレクトリに格納する。
組織において、いくつかの環境に対し、標準化された繰り返し行えるデプロイメントが必要とされている場合は、「単一のデプロイメント プランを使用するアプリケーション」のワークフローを使用して、ソース コントロール システム内で単一のデプロイメント プランを維持する。
Administration Console を使用して、アプリケーションのデプロイメント コンフィグレーションに大幅な変更を行う場合は、今後の使用に備えて、更新されたデプロイメント プランのバックアップを作成するか、安全に格納しておく。複数環境のコンフィグレーション情報、およびアプリケーションの複数バージョンを維持できるよう、ソース コントロール システム内にアプリケーション ルート ディレクトリ全体を格納することをお勧めします。
