| Oracle® Fusion Middleware Oracle WebLogic Server 12.1.3へのアプリケーションのデプロイ 12c (12.1.3) E56252-03 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Server 12.1.3へのアプリケーションのデプロイ 12c (12.1.3) E56252-03 |
|
前 |
次 |
この章では、WebLogic Server 12.1.3の再デプロイメントを利用して、アプリケーションや本番環境でデプロイしたアプリケーションの一部を更新する方法について説明します。
この章には次の項が含まれます:
本番環境にデプロイされたアプリケーションでは、顧客や内部クライアントに絶え間なくサービスを提供するために、24時間x 7日間の可用性がしばしば必要になります。WebLogic Serverでは、必要な可用性のレベルに基づいて本番アプリケーションを更新または修正できるように、柔軟性のある再デプロイメント戦略を提供しています。
本番再デプロイメント戦略では、更新されたアプリケーションの新しいバージョンを、同じアプリケーションの古いバージョンと並行してデプロイします。WebLogic Serverは、新しいクライアント・リクエストのみが新しいバージョンに転送されるように、自動的にクライアント接続を管理します。再デプロイメント時にアプリケーションにすでに接続していたクライアントは、作業が完了するまで古いバージョンのアプリケーションを使用し続けます。作業が完了した時点で、WebLogic Serverは自動的に古いバージョンをリタイアします。
本番再デプロイメントを使用すると、アプリケーションを停止せずに(アプリケーションのクライアントへの可用性を中断することなく)、本番環境でアプリケーションの更新と再デプロイを行うことができます。本番再デプロイメントでは、アプリケーションのダウンタイムのスケジューリング、新しいバージョンのアプリケーションをホストするための冗長サーバーの設定、複数のバージョンのアプリケーションに対するクライアント・アクセスの手動での管理、古いバージョンのアプリケーションの手動でのリタイアなどの手間を省くことができます(これらの手動の手順については、「インプレースでのアプリケーションおよびモジュールの再デプロイ」を参照してください)。
本番再デプロイメントを-distributeコマンドと併用すると、アプリケーションの新しいバージョンをデプロイメント用に準備することができます。その後で、アプリケーションを管理モードでデプロイできます。管理モードでデプロイすると、クライアントから使用できるようにする前に、新しいバージョンのアプリケーションの最終健全性テストを本番環境で直接実行できます。「本番アプリケーションの新しいバージョンの分散」を参照してください。
本番再デプロイメントは、特定の種類のJava EEアプリケーションでのみサポートされます。詳細は、「本番再デプロイメントの更新に関する制限事項」を参照してください。本番再デプロイメントの手順および関連情報については、「本番再デプロイメントを使用したアプリケーションの更新」を参照してください。
インプレース再デプロイメントでは、実行中のアプリケーションのデプロイメント・ファイルを、更新されたデプロイメント・ファイルでただちに置き換えます。本番再デプロイメントとは対照的に、アプリケーションまたはスタンドアロンJava EEモジュールのインプレース再デプロイメントでは、アプリケーションのクライアントに対する中断のないサービスは保証されません。これは、WebLogic Serverがアプリケーションの実行中のクラスローダーをただちに削除して、更新されたアプリケーションのクラス・ファイルをロードする新しいクラスローダーで置き換えるためです。
|
注意: インプレース再デプロイメントは、以前のバージョンのWebLogic Serverで使用された再デプロイメント戦略です。 |
WebLogic Serverは、バージョン識別子を指定していないJava EEアプリケーションや、本番再デプロイメントでサポートされていないJava EEアプリケーションおよびスタンドアロン・モジュールの場合に、インプレース再デプロイメント戦略を使用します。アプリケーションおよびスタンドアロンJava EEモジュールのインプレース再デプロイメントは、アプリケーションの定期的な停止時間中に、または、クライアントからアプリケーションへの既存の接続の維持にとって重要ではない時間に行うようにしてください。詳細は、「アプリケーションおよびスタンドアロン・モジュールに対するインプレース再デプロイメントの使用方法」を参照してください。
WebLogic Serverでは、デプロイ済アプリケーションまたはモジュールの部分的な再デプロイメントを行う場合に、インプレース再デプロイメント戦略を使用します。「静的ファイルの部分的な再デプロイメント」で説明するように、部分的な再デプロイメントでは、アプリケーション内の静的ファイルや、エンタープライズ・アプリケーション・デプロイメント内のJava EEモジュール全体を置き換えることができます。
WebLogic Serverでは、アプリケーション全体を一度に再デプロイするのではなく、実行中のアプリケーションの中の選択したファイルを再デプロイすることができます。この機能は一般に、実行中のWebアプリケーションの静的ファイル(画像、静的なHTMLページ、JSPなど)の更新に使用します。部分的な再デプロイメントは、展開されたアーカイブ・ディレクトリを使用してデプロイされているアプリケーションでのみ使用できます。
静的ファイルの部分的な再デプロイメントは、アプリケーションの既存のクライアントには影響を与えません。WebLogic Serverはデプロイされているアプリケーションの静的ファイルを単に置き換えるだけです。更新後のファイルはリクエストされたときにクライアントに提供されます。「デプロイされたアプリケーションにおける静的ファイルの更新」を参照してください。
部分的な再デプロイメントでは、デプロイされているエンタープライズ・アプリケーションの中の1つのモジュールまたはモジュールのサブセットを再デプロイすることもできます。この場合も、部分的な再デプロイメントは、展開されたアーカイブ・ディレクトリを使用してデプロイされているアプリケーションでのみサポートされます。
エンタープライズ・アプリケーション内のモジュールの再デプロイメントでは、インプレース再デプロイメント戦略を使用するため、モジュールに対する中断のないクライアント・アクセスは保証されません。このため、EAR内のJava EEモジュールの部分的な再デプロイメントは、アプリケーションの定期的なダウンタイム中に、または、アプリケーションに対するクライアント・アクセスの維持にとって重要ではない時間に行うようにしてください。「Java EEモジュールを更新するための部分的な再デプロイメントの使用」を参照してください。
次の表では、WebLogic Serverの各再デプロイメント戦略の概要を示し、各戦略を使用するシナリオについて説明します。
表8-1 再デプロイメント戦略のサマリー
| 再デプロイメント戦略 | サマリー | 用途 |
|---|---|---|
|
本番再デプロイメント |
アプリケーションの既存のバージョンと並行して、アプリケーションの新しいバージョンを再デプロイします。 |
|
|
アプリケーションおよびモジュールのインプレース再デプロイメント |
更新されたアプリケーションのクラス・ファイルをロードするために、アプリケーションのクラスローダーは新しいクラスローダーでただちに置き換えられます。WebLogic Serverでは再デプロイメント時の中断のないクライアント・アクセスを保証しないので、既存のクライアントの状態に関する情報は失われる可能性があります。 |
|
|
静的ファイルの部分的な再デプロイメント(インプレース再デプロイメント) |
HTML、JSP、グラフィック・ファイル、その他の静的ファイルを、更新済ファイルでただちに置き換えます。 |
|
|
Java EEモジュールの部分的な再デプロイメント(インプレース再デプロイメント) |
更新されたクラス・ファイルをロードするために、モジュールのクラスローダーは新しいクラスローダーでただちに置き換えられます。WebLogic Serverでは再デプロイメント時にモジュールへの中断のないクライアント・アクセスを保証しないので、既存のクライアントの状態に関する情報は失われる可能性があります。 |
|
WebLogic Serverは、アプリケーションの既存のクライアントに影響を与えずに、また、新しいクライアント・リクエストに対するアプリケーションの可用性を中断することなく、本番アプリケーションの更新済みの新しいバージョンを再デプロイできます。
WebLogic Serverでは、アプリケーションの実行中の古いバージョンと並行して、新しいバージョンのアプリケーションをデプロイすることによって、本番再デプロイメントを実行します。再デプロイメントが行われている間は、一方のバージョンのアプリケーションが「アクティブ」になり、もう一方のバージョンは「リタイア中」になります。アクティブなバージョンのアプリケーションは、そのアプリケーションに対する新しいクライアント接続リクエストをすべて受信します。一方、リタイア中のバージョンのアプリケーションは、再デプロイメントが行われたときに存在していたクライアント接続のみを処理します。WebLogic Serverは、アプリケーションのすべての既存のクライアントが作業を終えた後で、または構成されているタイムアウトに達した時点で、リタイア中のバージョンのアプリケーションをアンデプロイします。
アプリケーションの新しいバージョンを再デプロイすると、WebLogic Serverでは、新しくデプロイされたアプリケーションのバージョンをアクティブなバージョンとして扱い、古い方のバージョンのリタイアを開始します。リタイア期間中、WebLogic ServerはアプリケーションのHTTPセッションと進行中のトランザクションを自動的に追跡します。WebLogic Serverはセッションが完了するかタイムアウトするまで、各HTTPセッションを追跡します。進行中のトランザクションは、トランザクションが完了、ロールバック、またはトランザクションのタイムアウト期間に達するまで追跡されます。
古い方のアプリケーション・バージョンをアクティブにすると、本番再デプロイメントのプロセスをロールバックできます。この操作は、たとえば、新しいバージョンのアプリケーションに問題があると判断した場合や、クライアントを古い方のバージョンに戻したい場合などに必要になります。古い方のアプリケーション・バージョンをアクティブにするには、そのバージョンを再デプロイします。
WebLogic Serverクラスタでは、クラスタリングされた各サーバー・インスタンスは、現在の作業負荷を完了した時点で、リタイア中のアプリケーション・バージョンのローカル・デプロイメントをリタイアします。つまり、アプリケーション・バージョンは、クラスタ内の他のサーバーでリタイアされる前に、クラスタリングされた一部のサーバー・インスタンスでリタイアされる可能性があります。ただし、クラスタのフェイルオーバー・シナリオでは、クライアントのフェイルオーバー・リクエストは、そのアプリケーション・バージョンがまだ使用可能であれば、常にセカンダリ・サーバーにある同じアプリケーション・バージョンで処理されます。同じアプリケーション・バージョンがセカンダリ・サーバーで使用可能でない場合、フェイルオーバーは成功しません。
本番再デプロイメント機能を使用するには、開発時およびデプロイメントの段階で、アプリケーションは以下の要件を満たす必要があります。
本番再デプロイメント戦略は以下のものに対してサポートされています。
スタンドアロンのWebアプリケーション(WAR)モジュールと、クライアントがWebアプリケーション(HTTP)経由でアクセスするエンタープライズ・アプリケーション(EAR)。
グローバルなJMS宛先からのインバウンドJMSメッセージまたはインバウンドJCAリクエストによってアクセスされるエンタープライズ・アプリケーション。
会話形式で信頼性のあるWebサービスなど、すべてのタイプのWebサービス(ただし、8.xのWebサービスは除く)。
Coherenceキャッシュ・クライアント – ストレージが無効な管理対象Coherenceサーバーにデプロイされる、EAR内のグリッド・アーカイブ(GAR)モジュール。GAR内のクラスは、既存のデプロイメントとの後方互換性を備えている必要があります。
以下のものに対しては、本番再デプロイメントはサポートされません。
スタンドアロンのEJBまたはRARモジュール。そのようなモジュールで本番再デプロイメントを使用しようとすると、WebLogic Serverは再デプロイメント・リクエストを拒否します。そのようなモジュールを再デプロイするには、バージョン識別子を削除して、モジュールを明示的に再デプロイします。
JTSドライバを使用するアプリケーション。JDBCアプリケーション・モジュールの制限の詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』のJDBCアプリケーション・モジュールの制限に関する項を参照してください。
DriverManager APIを通じてJDBCデータ・ソースを取得するアプリケーション。本番再デプロイメントを使用するには、アプリケーションはJNDIを使用してデータ・ソースをルックアップする必要があります。
EJB 1.1のコンテナ管理による永続性(CMP) EJBを含むアプリケーション。CMP EJBを含むアプリケーションで本番再デプロイメントを使用するには、EJB 1.1 CMPではなくEJB 2.x CMPを使用します。
Coherenceキャッシュ・サーバー – ストレージが有効な管理対象CoherenceサーバーにデプロイされるGARモジュール。
本番再デプロイメントでサポートされるのはHTTPクライアントとRMIクライアントのみです(「RMIクライアント・リクエストの処理の正常な停止」を参照)。開発および設計チームは、サポートされないクライアントが、本番再デプロイメントを使用しているアプリケーションにアクセスしないようにしておく必要があります。WebLogic Serverはサポートされないクライアントがアプリケーションにアクセスしたことを検出せず、本番再デプロイメント時にはサポートされないクライアント接続を維持しません。
本番再デプロイメント中にアプリケーションの複数のバージョンがWebLogic Serverドメインで安全に共存できるようにするため、開発時には、特定の要件を満たすようにアプリケーションを設計する必要があります。本番再デプロイメントを使用するアプリケーションで要求されるプログラミング・ルールに関する情報は、『Oracle WebLogic Serverアプリケーションの開発』の本番再デプロイメント用バージョン付きのアプリケーションの開発に関する項を参照してください。
エンタープライズ・アプリケーションにJCAリソース・アダプタ・モジュールが含まれる場合、モジュールは:
JCA 1.5に準拠している必要があります
weblogic.connector.extensions.Suspendableインタフェースを実装する必要があります
enable-access-outside-appがfalse (デフォルト値)に設定されており、アプリケーション・スコープの方法で使用されていること
新しいバージョンのEARのリソース・アダプタがデプロイされる前に、旧バージョンのアプリケーションのリソース・アダプタがコールバックを受け取ります。その後で、新しいバージョンのアプリケーションがデプロイされ、旧バージョンのEAR全体がリタイアされます。
リソース・アダプタの本番再デプロイメント要件の完全なリストについては、『Oracle WebLogic Serverリソース・アダプタの開発』の本番再デプロイメントに関する項を参照してください。
|
警告: 本番再デプロイメント戦略ではアプリケーションが特定のプログラミング規約を守る必要があるため、開発および設計スタッフが承認したアプリケーションでのみ、本番再デプロイメントを使用してください。Oracleのプログラミング規約に従わないアプリケーションで本番再デプロイメントを使用すると、グローバルなリソースが破損したり、望ましくないアプリケーションの動作につながる可能性があります。 |
デプロイされるアプリケーションでは、そのアプリケーションで本番再デプロイメント処理を実行する前に、バージョン番号を指定する必要があります。つまり、バージョン指定されていないアプリケーションをデプロイし、その後でアプリケーションの新しいバージョンによる本番再デプロイメントを実行することはできません。
WebLogic Serverは一度に最大2つまで異なるバージョンのアプリケーションをホストできます。
新しいバージョンのアプリケーションを再デプロイするときに、以下の設定を変更することはできません。
アプリケーションのデプロイメント・ターゲット
アプリケーションのセキュリティ・モデル
Webアプリケーションの永続ストアの設定
上記の機能を変更するには、まず、アプリケーションのアクティブなバージョンをアンデプロイする必要があります。
WebLogic Serverでは、現在デプロイされているアプリケーションと再デプロイされるアプリケーションが別々のバージョンを指定している場合に、本番再デプロイメント戦略を使用しようとします。
アプリケーションにバージョン識別子を割り当てるには、デプロイするEARまたはWARのMANIFEST.MFファイルに、一意のバージョン文字列を直接格納することをお薦めします。開発プロセスでは、新しいアプリケーションをリリースするたびに自動的にバージョン識別子をインクリメントしてから、アプリケーションをデプロイメント用にパッケージ化するようにしてください。
バージョン情報をこのように保持すると、本番ドメインでアプリケーションが再デプロイされるたびに本番再デプロイメント戦略が使用されます。『Oracle WebLogic Serverアプリケーションの開発』の本番再デプロイメント用バージョン付きのアプリケーションの開発に関する項を参照してください。
本番再デプロイメント機能をテストする場合、またはマニフェスト・ファイルにバージョン文字列を含まないアプリケーションに対して本番再デプロイメントを使用する場合は、アプリケーションのデプロイまたは再デプロイ時に、-appversionオプションを使用して一意のバージョン文字列を手動で指定できます。
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -deploy -name myTestDeployment
-source /myDeployments/myApplication/91Beta
-targets myCluster -stage -appversion .91Beta
-appversionで指定されたバージョン文字列は、デプロイメント・ソース・ファイルでMANIFEST.MF内にバージョン文字列を指定していない場合にのみ適用されます。アプリケーションのバージョン文字列で有効な文字と文字形式に関する情報は、『Oracle WebLogic Serverアプリケーションの開発』のアプリケーション・バージョン・ルールに関する項を参照してください。
|
警告: 本番再デプロイメントに関するOracleのプログラミング規約にアプリケーションがしたがっていない限り、本番環境で-appversionを使用してデプロイまたは再デプロイしないでください。「本番再デプロイメントの要件と制限事項」を参照してください。プログラミング規約に従わないアプリケーションで本番再デプロイメントを使用すると、グローバルなリソースが破損したり、望ましくないアプリケーションの動作につながる可能性があります。 |
WebLogic Server管理コンソールでは、すべてのデプロイ済みアプリケーションおよびモジュールのバージョン文字列情報と状態情報の両方が表示されます。この情報を表示するには、WebLogic Server管理コンソールの左ペインで「デプロイメント」ノードを選択します。
weblogic.Deployer -listappsコマンドを使用して、デプロイ済みアプリケーションのバージョン情報をコマンド行から表示することもできます。
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -listapps
本番再デプロイメント戦略を使用してアプリケーションの新しいバージョンを再デプロイするには:
アプリケーションの1つのバージョンのみが、ドメインに現在デプロイされていることを確認します。「デプロイされたアプリケーションのバージョン情報の表示」を参照してください。
デプロイ済みアプリケーションと新しいアプリケーションで異なるバージョン文字列を持っていることを確認します。
「デプロイされたアプリケーションのバージョン情報の表示」の指示にしたがって、アプリケーションの現在デプロイされているバージョンを確認します。
デプロイする新しいアプリケーション・ソースのMANIFEST.MFファイルにあるバージョン文字列を調べます。
jar xvf myApp.ear MANIFEST.MF cat MANIFEST.MF
新しいアプリケーションのデプロイメント・ファイルを、デプロイメントに適した場所に置きます。アプリケーションのデプロイメント・ファイルの各バージョンを一意のサブディレクトリに格納することをお薦めします。
たとえば、現在デプロイされているアプリケーションのファイルが次の場所に格納されている場合、
/myDeployments/myApplication/91Beta
更新されたアプリケーション・ファイルは、次のような新しいサブディレクトリに格納します。
/myDeployments/myApplication/1.0GA
|
警告: nostageまたはexternal_stageモードのデプロイメントの場合は、古いバージョンのアプリケーションのデプロイメント・ファイルを上書きまたは削除しないでください。後でリタイアプロセスをロールバックして元のアプリケーション・バージョンに戻す場合に、元のデプロイメント・ファイルが必要になります。 |
新しいアプリケーション・バージョンを再デプロイして、更新されたデプロイメント・ファイルを指定します。更新されたデプロイメント・ファイルのマニフェスト・ファイルに一意のバージョン識別子が含まれている場合は、次のようなコマンドを使用します。
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -redeploy -name myTestDeployment
-source /myDeployments/myApplication/1.0GA
|
注意: 元の場所を変更した場合は、バージョン管理された既存のアプリケーションに対して-sourceオプションを指定しないでください。その場合、まずアプリケーションのデプロイを解除してから、デプロイしなおす必要があります。
詳細については、「再デプロイ」を参照してください。 |
新しいデプロイメント・ファイルのマニフェストにバージョン識別子が含まれていない場合は、「デプロイメントおよび再デプロイメント中のバージョン識別子の割当て」を参照してください。
デフォルトでは、WebLogic Serverは、新しいクライアント・リクエストを処理するために、アプリケーションの新しく再デプロイされたバージョンをアクティブにします。既存のクライアントは作業が完了するまで古いアプリケーションを使用し続け、古いアプリケーションは安全にアンデプロイされます。
(クライアントが作業を終了したかどうかに関係なく)古いバージョンのアプリケーションがリタイアされるまでの期間を指定する場合は、-redeployコマンドと一緒に-retiretimeoutオプションを使用します。
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -redeploy -name myTestDeployment
-source /myDeployments/myApplication/1.0GA
-retiretimeout 300
-retiretimeoutでは、古いバージョンのアプリケーションがリタイアされるまでの秒数を指定します。また、次のように、-undeployコマンドを使用し、古いアプリケーション・バージョンを指定して、古い方のアプリケーションをただちにリタイアすることもできます。
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -undeploy -name myTestDeployment
-appversion .91Beta
アプリケーションの古いバージョンと新しいバージョンの両方がデプロイされていて、適切なバージョンがアクティブになっていることを確認します。「デプロイされたアプリケーションのバージョン情報の表示」を参照してください。
WebLogic Serverがアプリケーションのあるバージョンをまだリタイアしていない場合、リタイアが完了するまで待たずにそのアプリケーションのバージョンをただちにアンデプロイできます。この操作は、たとえば、維持する必要のない長時間のクライアント・セッションが1つか2つのみあってアプリケーションがリタイア状態のままになっている場合などに必要になります。リタイア中のアプリケーション・バージョンのアンデプロイメントを行うには、-undeployコマンドを使用してそのアプリケーション・バージョンを指定します。
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -undeploy -name myTestDeployment
-appversion .91Beta
|
注意: リタイア中のバージョンのアプリケーションをアンデプロイする場合やリタイアのタイムアウトが発生するのを待つ場合に、コマンドに-gracefulオプションを指定することはできません。
|
本番再デプロイメント・プロセスを元に戻すと、アクティブなアプリケーションとリタイア中アプリケーションの状態が切り替わり、新しいクライアント接続リクエストはそれにしたがってリダイレクトされます。アプリケーションの新しくデプロイされたバージョンで問題が見つかった場合や、クライアントが新しいバージョンにアクセスしないようにする場合は、本番再デプロイメント・プロセスを元に戻す必要があります。
本番再デプロイメント・プロセスをロールバックするには、-redeployコマンドを再び発行して、古いバージョンのデプロイメント・ソース・ファイルを指定します。
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -redeploy -name myTestDeployment
-source /myDeployments/myApplication/91Beta
-retiretimeout 300
あるいは、古いバージョンのデプロイメント・ソース・ファイルを指定するかわりに、-appversionオプションを使用すると、以前のバージョンを指定できます。
デプロイメント・ファイルのマニフェストにバージョン識別子が含まれていない場合は、「デプロイメントおよび再デプロイメント中のバージョン識別子の割当て」を参照してください。
-rmigraceperiod属性を使用すると、アプリケーションをリタイア(-retirement)または正常停止(-graceful)する場合に、RMIクライアント・リクエストを処理するための猶予期間(秒単位)を指定できます。サーバー・インスタンスのワーク・マネージャは、新しいRMIクライアント・リクエストを受信せずに、猶予期間が経過するまでRMI呼出しを受け付けてスケジューリングします。猶予期間内に新しいRMIクライアント・リクエストが発生した場合、猶予期間はリセットされて、RMIクライアントの処理は以下の時点まで続行されます。
別のRMIリクエストによって猶予期間がリセットされる
RMIクライアント・リクエストがないまま猶予期間が過ぎる
RMIクライアントがリタイアされたアプリケーションまたは停止しているアプリケーションへアクセスしようとした場合、オブジェクトを呼び出そうとすると、クライアントはNoSuchObjectExceptionを受け取ります。そのオブジェクトの新しいバージョンが使用可能である場合、アプリケーションはNoSuchObjectException例外を取得し、JNDI環境プロパティweblogic.jndi.WLContext.RELAX_VERSION_LOOKUPを使用してオブジェクトの新しいバージョンをルックアップして、アクティブなバージョンのアプリケーションからバインドを戻す必要があります。
たとえば、次のコマンドは、保留中のHTTPセッションまたは進行中の作業が完了した後で、アプリケーションを管理モードにします。
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic -password weblogic -name mymodule -stop -adminmode -graceful -rmigraceperiod 30
正常なリタイアがT0秒で開始され、RMIリクエスト(msg1)がT1秒(T1 < (T0 + 30))で届いた場合、アプリケーションは追加のRMIクライアント・リクエストをT1 + 30秒間待機します。
msg2がT2秒(T2 < (T1 +30))で届いた場合、msg2はスケジューリングされ、猶予期間はT2+30秒にリセットされます。
追加のリクエストがない場合、またはリクエスト(msg2)がT2秒(T2 > (T1 +30))で届いた場合、ワーク・マネージャはRMIリクエストのスケジューリングを停止します。
アプリケーションの新しいバージョンを配布すると、WebLogic Serverはその新しいアプリケーション・バージョンをデプロイメントのために準備します。その後で、アプリケーションを管理モードでデプロイすると、アプリケーションは構成済の管理チャネル経由でのみ使用できるようになります。外部のクライアントは、配布されて管理モードでデプロイされたアプリケーションにはアクセスできません。
-adminmodeオプションを使用すると、アプリケーションを管理モードで起動できます。詳細は、「配布されたアプリケーションの管理モードでの起動」を参照してください。
アプリケーションの古いバージョンは、新しいクライアント・リクエストと既存のクライアント・リクエストの両方を処理するために、アクティブなままです。新しいバージョンを管理モードで配布およびデプロイした場合、WebLogic Serverはアプリケーションの古いバージョンを自動的にはリタイアしません。
管理チャネル経由で新しいアプリケーションのテストを完了したら、新しいアプリケーション・バージョンをアンデプロイするか起動します。アプリケーションを起動するとWebLogic Serverは新しいクライアント接続を更新されたアプリケーションにルーティングし、古い方のアプリケーション・バージョンのリタイアを開始します。
アプリケーションの新しいバージョンを管理モードで配布する基本的な手順は、「アプリケーションの新しいバージョンの再デプロイ」で説明した手順と同じです。-redeployコマンドのかわりに、weblogic.Deployer -distributeコマンドを使用するのみです。
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -distribute -name myTestDeployment
-source /myDeployments/myApplication/1.0GA
-appversion 1.0GA
アプリケーションを配布したら、管理モードで起動します。
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -start -adminmode -name myTestDeployment
-source /myDeployments/myApplication/1.0GA
-appversion 1.0GA
アプリケーションを管理モードで起動すると、構成済管理チャネル経由でのみ使用できるようになります。『Oracle WebLogic Serverサーバー環境の管理』のネットワーク・リソースの構成に関する項を参照してください。
必要に応じて、配布されるアプリケーションのリタイア・ポリシーやタイムアウト期間を指定することもできます。
構成済の管理チャネルを使用して最終テストを行ったら、-adminmodeオプションを指定せずにweblogic.Deployer -startコマンドを使用すると、管理モードで実行中の配布されたアプリケーション・バージョンを新しいクライアント接続にオープンできます。
WebLogic Server管理コンソールを使用して、両方のアプリケーション・バージョンのバージョンおよび状態情報を表示します。
アプリケーションの両方のバージョンがまだデプロイされていることを確認します。
管理モードで実行中のアプリケーション・バージョンのバージョン識別子をノートします。
weblogic.Deployerに-appversionオプションを使用して、管理モードで配布してデプロイされたアプリケーションを起動します。
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -start -name myTestDeployment
-appversion .91Beta
デフォルトでは、WebLogic Serverは、以前に配布されて管理モードで実行中のアプリケーション・バージョンに、新しいクライアント・リクエストをルーティングします。既存のクライアントは作業が完了するまで古いアプリケーションを使用し続け、古いアプリケーションは安全にアンデプロイされます。(クライアントが作業を終了したかどうかに関係なく)古いバージョンのアプリケーションが廃止されるまでの期間を指定する場合は、-retiretimeoutオプションを使用します。
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -start -name myTestDeployment
-appversion .91Beta -retiretimeout 300
-retiretimeoutでは、古いバージョンのアプリケーションがリタイアされるまでの秒数を指定します。
WebLogic Server管理コンソールを使用して、以前に配布したアプリケーションがアクティブになり、それより前のアプリケーション・バージョンがリタイア中になっていることを確認します。「デプロイされたアプリケーションのバージョン情報の表示」を参照してください。
本番再デプロイメントを使用する場合は、以下のベスト・プラクティスに留意してください。
本番再デプロイメントに関するOracleのプログラミング・ルールにアプリケーションがしたがっていない限り、本番アプリケーションに対してバージョン文字列を指定しないでください。『Oracle WebLogic Serverアプリケーションの開発』の本番再デプロイメント用バージョン付きのアプリケーションの開発に関する項を参照してください。
アプリケーションがstageモードでデプロイされている場合は、本番再デプロイメントを使用するのが最も簡単です。stageモードの場合、WebLogic Serverは、デプロイされているアプリケーションの別々のバージョンごとに別々のディレクトリを自動的に作成します。これらのディレクトリは、サーバーで構成されているステージング・ディレクトリ内に格納されて(デフォルトでは、ドメイン・ディレクトリのserver_name/stageサブディレクトリ)、関連付けられたアプリケーション・バージョンがアンデプロイされるときに削除されます。
nostageモードでデプロイする場合は、アプリケーションの新しい各バージョンを専用のサブディレクトリに格納します。こうすると、デプロイメント・ファイルの古いバージョンが上書きされなくなり、更新後に問題が見つかった場合に以前のアプリケーションに戻すことができます。
external_stageモードでデプロイする場合は、各アプリケーション・バージョンのデプロイメント・ファイルを、各ターゲット・サーバーのステージング・ディレクトリの、適切なバージョンのサブディレクトリに格納する必要があります。たとえば、以前のサンプル・コマンドで使用されているバージョン指定されたアプリケーション・ファイルの場合は、デプロイメントおよび再デプロイメントの前に、各サーバーのステージング・ディレクトリ内の/myTestDeployment/.91Betaおよび/myTestDeployment/1.0GAサブディレクトリにコピーする必要があります。
インプレース再デプロイメントでは、実行中のアプリケーションのデプロイメント・ファイルをただちにアンデプロイし、更新されたデプロイメント・ファイルで置き換えます。アプリケーション全体またはJava EEモジュールの再デプロイにインプレース再デプロイメントを使用すると、アプリケーションまたはモジュールはデプロイメント・プロセス中に使用できなくなり、既存のクライアントでは進行中の作業が失われる可能性があります。アプリケーションのクラス・ファイルとライブラリがクラスローダーからただちにアンデプロイされて、更新されたバージョンで置き換えられるため、このようなクライアント・サービスの中断が発生します。
アプリケーションおよびモジュールのインプレース再デプロイメントはアプリケーションのクライアントに悪影響を及ぼすため、次の場合を除いて、本番アプリケーションでは使用しないでください。
現在アプリケーションを使用しているクライアントがありません。
再デプロイメント中にアプリケーションへのクライアント・アクセスや進行中の作業が失われてもかまわません。
|
注意: WebLogic Serverは、バージョン識別子を含まないアプリケーションの場合は、常にインプレース再デプロイメントを実行します。 |
また、部分的な再デプロイメント処理(アプリケーションの一部分にのみ影響を与える再デプロイメント・コマンド)でもインプレース再デプロイメントを使用する場合が多くあります。また、再デプロイされるファイルはアクティブなクライアント接続に悪影響を及ぼさないので、本番アプリケーションで部分的な再デプロイメントを使用できる場合もあります。表8-0では、部分的な再デプロイメントの種類と、デプロイされたアプリケーションに与える影響について説明します。
表8-2 部分的な再デプロイメントの動作
| 部分的な再デプロイメントの範囲 | 再デプロイメントの動作 | 推奨される使用方法 |
|---|---|---|
|
画像ファイル、静的なHTMLファイル、JSP |
ソース・ファイルはディスク上でただちに置き換えられて、次のクライアント・リクエスト時に提供されます。 |
アプリケーションの定期的なダウンタイム中、またはクライアント接続や進行中の作業の維持にとって重要ではない時間にのみ使用します。 |
|
エンタープライズ・アプリケーションにおけるJava EEモジュール |
すべてのファイルはただちに置き換えられます。Javaクラス・ファイルとライブラリはクラスローダーからアンロードされ、更新済ファイルで置き換えられます。 |
アプリケーションの定期的なダウンタイム中、またはクライアント接続や進行中の作業の維持にとって重要ではない時間にのみ使用します。 |
|
動的なプロパティの変更(パラメータのチューニングなど)を伴うデプロイメント・プラン |
アプリケーションはインプレースで更新されます。アプリケーションがバージョン指定されている場合、プランのバージョンはインクリメントされません。 |
すべての本番環境で安全。 |
|
動的でないプロパティ(リソース・バインド)の変更を伴うデプロイメント・プラン |
アプリケーションがバージョン指定されていて、本番再デプロイメントに適しており、再デプロイされる場合、WebLogic Serverはバージョン識別子をインクリメントし、本番再デプロイメント戦略を使用してアプリケーションを更新します。 そのアプリケーションで本番再デプロイメントを使用できない場合は、アプリケーション全体を再デプロイする必要があります。 |
本番再デプロイメントに適している、バージョン指定されたアプリケーションでは安全。「本番再デプロイメントを使用したアプリケーションの更新」を参照してください。 アプリケーションで本番再デプロイメントを使用できない場合は、アプリケーションの定期的なダウンタイム中、またはクライアント接続や進行中の作業の維持にとって重要ではない時間にのみ、デプロイメント・プランを更新します。 動的ではないプロパティの変更を含むデプロイメント・プランとともに、アプリケーションを(更新ではなく)再デプロイする必要があります。そのようなプランを伴うアプリケーションを更新しようとすると失敗します。 |
インプレース再デプロイメント戦略を使用してアプリケーション全体またはスタンドアロン・モジュールを再デプロイするには、次の点に留意してください。
アプリケーションへのクライアント接続を保護するには、まずアプリケーションをオフラインにして、アプリケーションにアクセスしているクライアントがないことを確認します。
アプリケーションをオフラインにする具体的な方法は、WebLogic Serverドメインのアーキテクチャによって異なります。多くの場合、冗長サーバーやクラスタが作成されていて、アプリケーションのコピーを個別にホストしており、ロード・バランシング・ハードウェアまたはソフトウェアがサーバーやクラスタへのアクセスを管理しています。アプリケーションをオフラインにするには、ロード・バランシング・ポリシーを変更して、サーバーのセットまたはクラスタから冗長セットにすべてのクライアント接続を移します。
新しいアプリケーションのデプロイメント・ファイルを、デプロイメントに適した場所に置きます。アプリケーションのデプロイメント・ファイルの各バージョンを一意のサブディレクトリに格納することをお薦めします。
たとえば、現在デプロイされているアプリケーションのファイル(SimpleEAR.earなど)が次の場所に格納されている場合、
/myDeployments/myApplication/91Beta/SimpleEAR.ear
更新されたアプリケーション・ファイルは、次のような新しいディレクトリに格納します。
/myDeployments/myApplication/1.0GA/SimpleEAR.ear
アプリケーションを再デプロイして、更新されたデプロイメント・ソース・ファイルを指定します。構成済みのすべてのターゲット・サーバーにアプリケーションを再デプロイするには、デプロイメント名のみを指定します。
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -redeploy -source /myDeployments/myApplication/1.0GA/SimpleEAR.ear -name myApp
アプリケーションがクラスタリングされていない複数のサーバー・インスタンスにデプロイされている場合は、次のようにターゲット・リストを指定すると、ターゲット・サーバーのサブセットにのみアプリケーションを再デプロイできます。
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -redeploy -source /myDeployments/myApplication/1.0GA/SimpleEAR.ear -name myApp
-targets myserver1,myserver2
|
注意: クラスタにデプロイされたアプリケーションについては、再デプロイメントは常に、クラスタ内のすべてのターゲット・サーバー・インスタンスで行われます。アプリケーションがクラスタ内のすべてのサーバーにデプロイされている場合は、そのアプリケーションをクラスタ内の一部のサーバーに再デプロイすることはできません。 |
アプリケーションをホストするサーバーまたはクラスタをオフラインにした場合は、再デプロイメントの完了後にホスト・サーバーをオンラインに戻します。
必要な場合は、ロード・バランシング・ハードウェアまたはソフトウェアのロード・バランシング・ポリシーを回復して、一時的なサーバーからオンラインの本番サーバーにクライアントを戻します。
インプレース再デプロイメントを使用してアプリケーション全体またはスタンドアロン・モジュールを再デプロイする場合は、次の点に留意してください。
ステージングされたアプリケーション全体を再デプロイする場合、デプロイメント・ファイルが管理対象サーバーにコピーされるときにネットワーク・トラフィックが増加するため、パフォーマンスに影響が出る可能性があります。非常に大きなアプリケーションがある場合は、external_stageモードを使用して、アプリケーションを再デプロイする前にデプロイメント・ファイルを手動でコピーすることを検討してください。「external_stageモードのデプロイメントの使用」を参照してください。
WebLogic Serverクラスタにデプロイされたアプリケーションは、常にクラスタのすべてのメンバーに再デプロイする必要があります。クラスタリングされたアプリケーションをクラスタのサブセットに再デプロイすることはできません。
エンタープライズ・アプリケーションを正常に再デプロイするには、アプリケーションのすべてのモジュールが正常に再デプロイされる必要があります。
デフォルトでは、Webアプリケーションの再デプロイ時にWebLogic Serverが現在のユーザーのセッションを破棄します。再デプロイメント中にWebアプリケーションのユーザー・セッションを維持するには、weblogic.xmlデプロイメント記述子ファイルのcontainer-descriptorスタンザでsave-sessions-enabledを「true」に設定します。ただし、インプレース再デプロイメントが行われている間、アプリケーションは使用できなくなります。
デプロイ済エンタープライズ・アプリケーションの個別のモジュールを再デプロイする場合、weblogic.Deployerユーティリティでは別のコマンド形式を使用します。エンタープライズ・アプリケーションのモジュールのサブセットを再デプロイする場合は、ターゲット・サーバー・リストでmodulename@servernameと指定して、再デプロイするモジュールを指定します。例:
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -redeploy -name myApp
-targets mymodule1@myserver1,mymodule2@myserver2
|
注意: -redeploy module-uriの使用は非推奨になりました。かわりに、本番再デプロイメントを使用するか、または-targets module@target構文を使用してモジュールを再デプロイします。 |
アプリケーションがクラスタにデプロイされている場合は、一部のサーバーではなくクラスタ全体にモジュールを再デプロイする必要があります。クラスタ内の一部のサーバーを指定すると、weblogic.Deployerは次のエラーで応答します。
An attempt to add server target target_name to module module_name has been rejected. This is because its parent cluster, cluster_name, is aso targeted by the module.
次の制限は、エンタープライズ・アプリケーション内のモジュールの部分的な再デプロイメントを行う場合に適用されます。
エンタープライズ・アプリケーション内の1つのJava EEモジュールを再デプロイすると、同じクラスローダーにロードされている他のJava EEモジュールに影響を与える可能性がある場合、weblogic.Deployerでは、影響を受けるすべてのモジュールを明示的に再デプロイする必要があります。影響を受けるJava EEモジュールのサブセットのみを部分的に再デプロイしようとすると、weblogic.Deployerは次のエラーを表示します。
Exception:weblogic.management.ApplicationException: [J2EE:160076] You must include all of [module_list] in your files list to modify [module]
アプリケーションのデプロイメント記述子ファイルを変更した場合は、部分的な再デプロイメントを行おうとしても、コンテナはアプリケーション全体を再デプロイすることに留意してください。
WEB-INF/lib内のJARファイルは、Webアプリケーションの他の部分から独立して再デプロイできません。WEB-INF/lib内のJARファイルの再デプロイ時、コンテナは自動的にアプリケーション全体を再デプロイしますが、状態を保持します。
エンタープライズ・アプリケーション・モジュールで部分的な再デプロイメントを行う場合は、次のベスト・プラクティスに留意してください。
エンタープライズ・アプリケーション内のJava EEモジュールを再デプロイするために部分的な再デプロイメントを使用する場合は、更新されたモジュールのクラスローダーにロードされているすべてのクラスが再ロードされます。WebLogic Serverデプロイメント記述子でカスタムのクラスロード階層を定義すると、部分的な再デプロイメントによってアプリケーションの他のモジュールが受ける影響を最小限に抑えることができます。クラスローディングの動作の詳細は、『Oracle WebLogic Serverアプリケーションの開発』のWebLogic Serverアプリケーション・クラスローディングに関する項を参照してください。
WEB-INF/classesディレクトリ内のクラスは、Webアプリケーションの他の部分とは独立して再デプロイできません。Webアプリケーションの再ロード間隔を設定して、(WEB-INF/classesディレクトリ全体ではなく)更新したクラスのみをデプロイできます。(詳細は、『Oracle WebLogic Serverアプリケーション、サーブレット、JSPの開発』のweblogic.xml Schemaに関する項を参照してください。)また、『Oracle WebLogic Serverアプリケーションの開発』の実行中プログラムのクラス変更に関する項と、「FastSwapデプロイメントによる再デプロイメントの最小化」も参照してください。
デフォルトでは、Webアプリケーション・モジュールを再デプロイするときに、WebLogic Serverは現在のユーザー・セッションを破棄します。再デプロイメント中にWebアプリケーションのユーザー・セッションを維持するには、weblogic.xmlデプロイメント記述子ファイルのcontainer-descriptorスタンザでsave-sessions-enabledを「true」に設定します。ただし、インプレース再デプロイメントが行われている間、アプリケーションは使用できなくなります。
本番環境では、アプリケーション全体を再デプロイせずに、Webアプリケーション・モジュールの静的なコンテンツ(HTMLファイル、イメージ・ファイル、JSPなど)をリフレッシュすることが必要になる場合があります。Webアプリケーションまたはエンタープライズ・アプリケーションを展開されたアーカイブ・ディレクトリとしてデプロイした場合は、weblogic.Deployerユーティリティを使用して、1つ以上の変更済静的ファイルをインプレースで更新できます。
デプロイメント・ユニット内に関連付けられた単一のファイルを再デプロイするには、redeployコマンドの最後にファイル名を指定します。例:
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -name myApp -redeploy myApp/copyright.html
更新したファイルのパス名は、展開されたアーカイブ・ディレクトリのルート・ディレクトリを基準とする相対パスで常に指定します。前述の例では、Webアプリケーションはエンタープライズ・アプリケーションの一部としてデプロイされるため、モジュール・ディレクトリを(myApp/copyright.html)と指定しています。
Webアプリケーションが、エンタープライズ・アプリケーションの一部としてではなく、スタンドアロン・モジュールとしてデプロイされている場合は、ファイルを単独で指定します(copyright.html)。
単一のファイルではなくディレクトリ名を指定して、ファイルのディレクトリ全体を再デプロイすることもできます。例:
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -name myApp -redeploy myApp/myjsps
この例では、エンタープライズ・アプリケーションのmyjspsサブディレクトリにあるすべてのファイルとサブディレクトリが、インプレースで再デプロイされます。
アプリケーションまたはスタンドアロン・モジュールをデプロイしたら、WebLogic Server管理コンソールまたはweblogic.Deployerを使用して、WebLogic Serverのデプロイメント構成を変更できます。
WebLogic Server管理コンソールでは、個々のデプロイメント構成プロパティを対話形式で変更できます。一方、weblogic.Deployerでは、アプリケーションの再構成に使用する更新されたデプロイメント・プラン・ファイルのみを指定できます。
WebLogic Server管理コンソールを使用すると、アプリケーションのデプロイメント・プランに含まれていないプロパティを含む、アプリケーションのすべての再デプロイメント構成プロパティを再構成できます。アプリケーションがデプロイメント・プランとともにデプロイされた場合、コンソールでは、そのアプリケーションの「デプロイメント・プラン」ページに、デプロイメント・プランの構成プロパティが表示されます。
アプリケーションの他の構成ページを使用して、WebLogic Serverの他の構成プロパティを変更できます。構成で使用できる具体的なプロパティは、デプロイされているアプリケーションやJava EEモジュールの種類によって異なります。これらのページは、アプリケーションがデプロイメント・プランとともにデプロイされているかどうかにかかわらず使用できます。
一部の構成の変更は実行中の本番アプリケーションに適用可能ですが、それ以外の変更にはアプリケーションの停止と再起動が必要になります。「デプロイメント構成変更のための再デプロイメント動作の理解」を参照してください。
デプロイメント・プランで定義されたプロパティをWebLogic Server管理コンソールを使用して変更すると、コンソールは、変更した新しいプロパティの変数定義とプランで定義されている既存の変数を含む、新しいデプロイメント・プランを生成します。新しいデプロイメント・プランの保存先を選択できます。
weblogic.Deployerユーティリティでは、アプリケーションで使用する新しいデプロイメント・プランを指定すると、アプリケーションのデプロイメント構成を更新できます。
|
注意: 更新されたデプロイメント・プランは、アプリケーションの現在のターゲット・サーバーで有効でなければなりません。有効でない場合、構成の更新は失敗します。 |
別の(有効な)デプロイメント・プランでアプリケーションを再構成するには、-updateコマンドを使用して、新しいデプロイメント・プラン・ファイルを指定します。
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -update -name myTestDeployment
-plan /myDeployments/myNewPlan.xml
|
注意: 一部の構成の変更は実行中の本番アプリケーションに適用可能ですが、それ以外の変更にはアプリケーションの停止と再起動が必要になります。「デプロイメント構成変更のための再デプロイメント動作の理解」を参照してください。 |
|
注意: 次の項で説明する再デプロイメント動作は、WebLogic Server管理コンソールおよびweblogic.Deployer -updateコマンドを使用して行われた両方の構成の変更に適用されます。 |
デプロイされているアプリケーションのデプロイメント構成を変更する場合、WebLogic Serverは再デプロイメント処理を使用して変更を適用します。使用される再デプロイメント戦略の種類は、適用される構成の変更の性質によって異なります。リソース・バインディング・プロパティの値を変更した場合は、構成の更新で、本番再デプロイメント戦略(そのアプリケーションが本番再デプロイメントをサポートしている場合)、またはアプリケーション全体に対してインプレース再デプロイメント戦略が使用されます。本番環境では、アプリケーション全体またはモジュールに対してインプレース再デプロイメントを実行することはお薦めできません。アプリケーションは最初にアンデプロイされるので、接続しているクライアントが進行中の作業を失うおそれがあるためです。詳細については、「再デプロイメント戦略の概要」を参照してください。
