| 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 の再デプロイメントを利用して、アプリケーションやアプリケーションの一部をプロダクション環境で更新する方法について説明します。
プロダクション環境にデプロイされたアプリケーションでは、顧客や内部クライアントに絶え間なくサービスを提供するために、24 時間 x 7 日間の可用性がしばしば必要になります。WebLogic Server では、必要な可用性のレベルに基づいてプロダクション アプリケーションを更新または修正できるように、柔軟性のある再デプロイメント方式を提供しています。
プロダクション再デプロイメント方式では、更新されたアプリケーションの新しいバージョンを、同じアプリケーションの古いバージョンと並行してデプロイします。WebLogic Server は、新しいクライアント要求のみが新しいバージョンに転送されるように、自動的にクライアント接続を管理します。再デプロイメント時にアプリケーションにすでに接続していたクライアントは、作業が完了するまで古いバージョンのアプリケーションを使用し続けます。作業が完了した時点で、WebLogic Server は自動的に古いバージョンを廃止します。
プロダクション再デプロイメントを使用すると、アプリケーションを停止せずに (アプリケーションのクライアントへの可用性を中断することなく)、プロダクション環境でアプリケーションの更新と再デプロイを行うことができます。プロダクション再デプロイメントでは、アプリケーションのダウンタイムのスケジューリング、新しいバージョンのアプリケーションをホストするための冗長サーバの設定、複数のバージョンのアプリケーションに対するクライアント アクセスの手動での管理、古いバージョンのアプリケーションの手動での廃止などの手間を省くことができます (これらの手動の手順については、「インプレースでのアプリケーションおよびモジュールの再デプロイ」を参照してください)。
プロダクション再デプロイメントを -distribute コマンドと併用すると、アプリケーションの新しいバージョンをデプロイメント用に準備することができます。その後で、アプリケーションを管理モードでデプロイできます。管理モードでデプロイすると、クライアントから使用できるようにする前に、新しいバージョンのアプリケーションの最終状態テストをプロダクション環境で直接実行できます。「プロダクション アプリケーションの新しいバージョンの分散」を参照してください。
プロダクション再デプロイメントは、特定の種類の J2EE アプリケーションでのみサポートされます。詳細については、「プロダクション再デプロイメントの更新に関する制限事項」を参照してください。プロダクション再デプロイメントの手順および関連情報については、「プロダクション再デプロイメントを使用したアプリケーションの更新」を参照してください。
インプレース再デプロイメント方式では、実行中のアプリケーションのデプロイメント ファイルを、更新されたデプロイメント ファイルで直ちに置き換えます。プロダクション再デプロイメントとは対照的に、アプリケーションまたはスタンドアロン J2EE モジュールのインプレース再デプロイメントでは、アプリケーションのクライアントに対する中断のないサービスは保証されません。これは、WebLogic Server がアプリケーションの実行中のクラスローダを直ちに削除して、更新されたアプリケーションのクラス ファイルをロードする新しいクラスローダで置き換えるためです。
|
注意 : インプレース再デプロイメントは、以前のバージョンの WebLogic Server で使用された再デプロイメント方式です。 |
WebLogic Server は、バージョン識別子を指定していない J2EE アプリケーションや、プロダクション再デプロイメントでサポートされていない J2EE アプリケーションおよびスタンドアロン モジュールの場合に、インプレース再デプロイメント方式を使用します。アプリケーションおよびスタンドアロン J2EE モジュールのインプレース再デプロイメントは、アプリケーションの定期的なダウンタイム中に、または、クライアントからアプリケーションへの既存の接続の維持にとって重要ではない時間に行うようにしてください。詳細については、「アプリケーションおよびスタンドアロン モジュールに対するインプレース再デプロイメントの使用」を参照してください。
WebLogic Server では、デプロイ済みアプリケーションまたはモジュールの部分的な再デプロイメントを行う場合に、インプレース再デプロイメント方式を使用します。次の節「静的ファイルの部分的な再デプロイメント」で説明するように、部分的な再デプロイメントでは、アプリケーション内の静的ファイルや、エンタープライズ アプリケーション デプロイメント内の J2EE モジュール全体を置き換えることができます。
WebLogic Server では、アプリケーション全体を一度に再デプロイするのではなく、実行中のアプリケーションの中の選択したファイルを再デプロイすることができます。この機能は一般に、実行中の Web アプリケーションの静的ファイル (画像、静的な HTML ページ、JSP など) の更新に使用します。部分的な再デプロイメントは、展開されたアーカイブ ディレクトリを使用してデプロイされているアプリケーションでのみ使用できます。
静的ファイルの部分的な再デプロイメントは、アプリケーションの既存のクライアントには影響を与えません。WebLogic Server はデプロイされているアプリケーションの静的ファイルを単に置き換えるだけです。更新後のファイルは要求されたときにクライアントに提供されます。「デプロイされたアプリケーションにおける静的ファイルの更新」を参照してください。
部分的な再デプロイメントでは、デプロイされているエンタープライズ アプリケーションの中の 1 つのモジュールまたは複数のモジュールのサブセットを再デプロイすることもできます。この場合も、部分的な再デプロイメントは、展開されたアーカイブ ディレクトリを使用してデプロイされているアプリケーションでのみサポートされます。
エンタープライズ アプリケーション内のモジュールの再デプロイメントでは、インプレース再デプロイメント方式を使用するので、モジュールに対する中断のないクライアント アクセスは保証されません。このため、EAR 内の J2EE モジュールの部分的な再デプロイメントは、アプリケーションの定期的なダウンタイム中に、または、アプリケーションに対するクライアント アクセスの維持にとって重要ではない時間に行うようにしてください。「J2EE モジュールを更新するための部分的な再デプロイメントの使用」を参照してください。
次の表では、WebLogic Server の各再デプロイメント方式の概要を示し、各方式を使用するシナリオについて説明します。
表 8-1 再デプロイメント方式の概要
| 再デプロイメント方式 | 概要 | 用途 |
|---|---|---|
|
プロダクション再デプロイメント |
アプリケーションの既存のバージョンと並行して、アプリケーションの新しいバージョンを再デプロイする。 |
|
|
アプリケーションおよびモジュールのインプレース再デプロイメント |
更新されたアプリケーションのクラス ファイルをロードするために、アプリケーションのクラスローダは新しいクラスローダで直ちに置き換えられる。WebLogic Server では再デプロイメント時の中断のないクライアント アクセスを保証しないので、既存のクライアントの状態に関する情報は失われる可能性がある。 |
|
|
静的ファイルの部分的な再デプロイメント (インプレース再デプロイメント) |
HTML、JSP、画像ファイル、その他の静的ファイルを、更新済みのファイルで直ちに置き換える。 |
|
|
J2EE モジュールの部分的な再デプロイメント (インプレース再デプロイメント) |
更新されたクラス ファイルをロードするために、モジュールのクラスローダは新しいクラスローダで直ちに置き換えられる。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 サービスは除く)。
以下のものに対しては、プロダクション再デプロイメントはサポートされません。
スタンドアロンの EJB または RAR モジュール。そのようなモジュールでプロダクション再デプロイメントを使用しようとすると、WebLogic Server は再デプロイメント要求を拒否します。そのようなモジュールを再デプロイするには、バージョン識別子を削除して、モジュールを明示的に再デプロイします。
JTS ドライバを使用するアプリケーション。JDBC アプリケーション モジュールの制限事項の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server JDBC のコンフィグレーションと管理』の「JDBC アプリケーション モジュールの制限事項」を参照してください。
DriverManager API を通じて JDBC データ ソースを取得するアプリケーション。プロダクション再デプロイメントを使用するには、アプリケーションは JNDI を使用してデータ ソースをルックアップする必要があります。
EJB 1.1 のコンテナ管理による永続性 (CMP) EJB を含むアプリケーション。CMP EJB を含むアプリケーションでプロダクション再デプロイメントを使用するには、EJB 1.1 CMP ではなく EJB 2.x CMP を使用します。
プロダクション再デプロイメントでサポートされるのは HTTP クライアントと RMI クライアントのみです (「RMI クライアント要求の処理の正常な停止」を参照)。開発および設計段階において、サポートされないクライアントが、プロダクション再デプロイメントを使用しているアプリケーションにアクセスしないようにしておく必要があります。WebLogic Server はサポートされないクライアントがアプリケーションにアクセスしたことを検出せず、プロダクション再デプロイメント時にはサポートされないクライアント接続を保護しません。
プロダクション再デプロイメント中にアプリケーションの複数のバージョンが WebLogic Server ドメインで安全に共存できるようにするため、開発時には、特定の要件を満たすようにアプリケーションを設計する必要があります。プロダクション再デプロイメントを使用するアプリケーションで要求されるプログラミング規約については、『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションの開発』の「プロダクション再デプロイメント用アプリケーションの開発」を参照してください。
エンタープライズ アプリケーションに JCA リソース アダプタ モジュールが含まれる場合、モジュールは以下の条件を満たす必要があります。
JCA 1.5 に準拠していること
weblogic.connector.extensions.Suspendable インタフェースを実装していること
enable-access-outside-app が false (デフォルト値) に設定されており、アプリケーション スコープの方法で使用されていること
新しいバージョンの EAR のリソース アダプタがデプロイされる前に、旧バージョンのアプリケーションのリソース アダプタがコールバックを受け取ります。その後で、新しいバージョンのアプリケーションがデプロイされ、旧バージョンの EAR 全体が廃止されます。
リソース アダプタのプロダクション再デプロイメント要件の詳細なリストについては、『Oracle Fusion Middleware Oracle WebLogic Server リソース アダプタ プログラマーズ ガイド』の「プロダクションの再デプロイメント」を参照してください。
|
警告 : プロダクション再デプロイメント方式ではアプリケーションが特定のプログラミング規約を守る必要があるため、開発および設計スタッフが承認したアプリケーションでのみ、プロダクション再デプロイメントを使用してください。Oracle のプログラミング規約に従わないアプリケーションでプロダクション再デプロイメントを使用すると、グローバルなリソースが破損したり、望ましくないアプリケーションの動作につながる可能性があります。 |
デプロイされるアプリケーションでは、そのアプリケーションでプロダクション再デプロイメント処理を実行する前に、バージョン番号を指定する必要があります。つまり、バージョン指定されていないアプリケーションをデプロイし、その後でアプリケーションの新しいバージョンによるプロダクション再デプロイメントを実行することはできません。
WebLogic Server は一度に最大 2 つまで異なるバージョンのアプリケーションをホストできます。
新しいバージョンのアプリケーションを再デプロイするときに、以下の設定を変更することはできません。
アプリケーションのデプロイメント対象
アプリケーションのセキュリティ モデル
Web アプリケーションの永続ストアの設定
上記の機能を変更するには、まず、アプリケーションのアクティブなバージョンをアンデプロイする必要があります。
WebLogic Server では、現在デプロイされているアプリケーションと再デプロイされるアプリケーションが別々のバージョンを指定している場合に、プロダクション再デプロイメント方式を使用しようとします。
アプリケーションにバージョン識別子を割り当てるには、デプロイする EAR または WAR の MANIFEST.MF ファイルに、ユニークなバージョン文字列を直接格納することをお勧めします。開発プロセスでは、新しいアプリケーションをリリースするたびに自動的にバージョン識別子をインクリメントしてから、アプリケーションをデプロイメント用にパッケージ化するようにしてください。
バージョン情報をこのように管理すると、プロダクション ドメインでアプリケーションが再デプロイされるたびにプロダクション再デプロイメント方式が使用されます。『Oracle Fusion Middleware 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 Fusion Middleware Oracle WebLogic Server アプリケーションの開発』の「アプリケーションのバージョンの規約」を参照してください。
|
警告 : プロダクション再デプロイメントに関する Oracle のプログラミング規約にアプリケーションが従っていない限り、プロダクション環境で-appversion を使用してデプロイまたは再デプロイしないでください。「プロダクション再デプロイメントの要件と制限事項」を参照してください。プログラミング規約に従わないアプリケーションでプロダクション再デプロイメントを使用すると、グローバルなリソースが破損したり、望ましくないアプリケーションの動作につながる可能性があります。 |
WebLogic Server Administration Console では、すべてのデプロイ済みアプリケーションおよびモジュールのバージョン文字列情報と状態情報の両方が表示されます。この情報を表示するには、Administration Console の左ペインで [デプロイメント] ノードを選択します。
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
新しいデプロイメント ファイルのマニフェストにバージョン識別子が含まれていない場合は、「デプロイメントおよび再デプロイメント中のバージョン識別子の割り当て」を参照してください。
デフォルトでは、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
|
注意 : 廃止中のバージョンのアプリケーションをアンデプロイする場合や廃止のタイムアウトが発生するのを待つ場合に、-undeploy コマンドに -graceful オプションを指定することはできません。
|
プロダクション再デプロイメント プロセスを元に戻すと、アクティブなアプリケーションと廃止中アプリケーションの状態が切り替わり、新しいクライアント接続要求はそれに従ってリダイレクトされます。アプリケーションの新しくデプロイされたバージョンで問題が見つかった場合や、クライアントが新しいバージョンにアクセスしないようにする場合は、プロダクション再デプロイメント プロセスを元に戻す必要があります。
プロダクション再デプロイメント プロセスをロールバックするには、-redeploy コマンドを再び発行して、古いバージョンのデプロイメント ソース ファイルを指定します。
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -redeploy -name myTestDeployment
-source /myDeployments/myApplication/91Beta
-retiretimeout 300
デプロイメント ファイルのマニフェストにバージョン識別子が含まれていない場合は、「デプロイメントおよび再デプロイメント中のバージョン識別子の割り当て」を参照してください。
-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 Fusion Middleware Oracle WebLogic Server サーバ環境のコンフィグレーション』の「ネットワーク リソースのコンフィグレーション」を参照してください。
必要に応じて、分散されるアプリケーションの廃止ポリシーやタイムアウト期間を指定することもできます。
コンフィグレーション済みの管理チャネルを使用して最終テストを行ったら、-adminmode オプションを指定せずに weblogic.Deployer -start コマンドを使用すると、管理モードで実行中の分散されたアプリケーション バージョンを新しいクライアント接続に公開できます。
Administration Console を使用して、両方のアプリケーション バージョンのバージョンおよび状態情報を表示します。
アプリケーションの両方のバージョンがまだデプロイされていることを確認します。
管理モードで実行中のアプリケーション バージョンのバージョン識別子をメモします。
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 では、古いバージョンのアプリケーションが廃止されるまでの秒数を指定します。
Administration Console を使用して、以前に分散したアプリケーションがアクティブになり、それより前のアプリケーション バージョンが廃止中になっていることを確認します。「デプロイされたアプリケーションのバージョン情報の表示」を参照してください。
プロダクション再デプロイメントを使用する場合は、以下のベスト プラクティスに留意してください。
プロダクション再デプロイメントに関する Oracle のプログラミング規約にアプリケーションが従っていない限り、プロダクション アプリケーションに対してバージョン文字列を指定しないでください。『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションの開発』の「プロダクション再デプロイメント用アプリケーションの開発」を参照してください。
アプリケーションが stage モードでデプロイされている場合は、プロダクション再デプロイメントを使用するのが最も簡単です。stage モードの場合、WebLogic Server は、デプロイされているアプリケーションの別々のバージョンごとに別々のディレクトリを自動的に作成します。これらのディレクトリは、サーバでコンフィグレーションされているステージング ディレクトリ内に格納されて (デフォルトでは、ドメイン ディレクトリの server_name/stage サブディレクトリ)、関連付けられたアプリケーション バージョンがアンデプロイされるときに削除されます。
nostage モードでデプロイする場合は、アプリケーションの新しい各バージョンを専用のサブディレクトリに格納します。こうすると、デプロイメント ファイルの古いバージョンが上書きされなくなり、更新後に問題が見つかった場合に以前のアプリケーションに戻すことができます。
external_stage モードでデプロイする場合は、各アプリケーション バージョンのデプロイメント ファイルを、各対象サーバのステージング ディレクトリの、適切なバージョンのサブディレクトリに格納する必要があります。たとえば、以前のサンプル コマンドで使用されているバージョン指定されたアプリケーション ファイルの場合は、デプロイメントおよび再デプロイメントの前に、各サーバのステージング ディレクトリ内の /myTestDeployment/.91Beta および /myTestDeployment/1.0GA サブディレクトリにコピーする必要があります。
インプレース再デプロイメント方式では、実行中のアプリケーションのデプロイメント ファイルを直ちにアンデプロイし、更新されたデプロイメント ファイルで置き換えます。アプリケーション全体または J2EE モジュールの再デプロイにインプレース再デプロイメントを使用すると、アプリケーションまたはモジュールはデプロイメント プロセス中に使用できなくなり、既存のクライアントでは進行中の作業が失われる可能性があります。アプリケーションのクラス ファイルとライブラリがクラスローダから直ちにアンデプロイされて、更新されたバージョンで置き換えられるので、このようなクライアント サービスの中断が発生します。
アプリケーションおよびモジュールのインプレース再デプロイメントはアプリケーションのクライアントに悪影響を及ぼすため、次の場合を除いて、プロダクション アプリケーションでは使用しないでください。
現在アプリケーションを使用しているクライアントがない。
再デプロイメント中にアプリケーションへのクライアント アクセスや進行中の作業が失われてもかまわない。
|
注意 : WebLogic Server は、バージョン識別子を含まないアプリケーションの場合は、常にインプレース再デプロイメントを実行します。 |
また、部分的な再デプロイメント処理 (アプリケーションの一部分にだけ影響を与える再デプロイメント コマンド) でもインプレース再デプロイメントを使用する場合が多くあります。また、再デプロイされるファイルはアクティブなクライアント接続に悪影響を及ぼさないので、プロダクション アプリケーションで部分的な再デプロイメントを使用できる場合もあります。表 8-0 では、部分的な再デプロイメントの種類と、デプロイされたアプリケーションに与える影響について説明します。
表 8-2 部分的な再デプロイメントの動作
| 部分的な再デプロイメントの範囲 | 再デプロイメントの動作 | 推奨される使い方 |
|---|---|---|
|
画像ファイル、静的な HTML ファイル、JSP |
ソース ファイルはディスク上で直ちに置き換えられて、次のクライアント要求時に提供される。 |
プロダクション アプリケーションにとって安全。 |
|
エンタープライズ アプリケーション内の J2EE モジュール |
すべてのファイルは直ちに置き換えられる。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 つの J2EE モジュールを再デプロイすると、同じクラスローダにロードされている他の J2EE モジュールに影響を与える可能性がある場合、weblogic.Deployer では、影響を受けるすべてのモジュールを明示的に再デプロイする必要があります。影響を受ける J2EE モジュールの一部だけを部分的に再デプロイしようとすると、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 ファイルの再デプロイ時、コンテナは自動的にアプリケーション全体を再デプロイしますが、状態を保持します。
エンタープライズ アプリケーション モジュールで部分的な再デプロイメントを行う場合は、以下のベスト プラクティスに留意してください。
エンタープライズ アプリケーション内の J2EE モジュールを再デプロイするために部分的な再デプロイメントを使用する場合は、更新されるモジュールのクラスローダにロードされているすべてのクラスを再ロードする必要があります。WebLogic Server デプロイメント記述子でカスタムのクラス ローディング階層を定義すると、部分的な再デプロイメントによってアプリケーションの他のモジュールが受ける影響を最小限に抑えることができます。クラス ローディングの動作の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションの開発』の「WebLogic Server アプリケーションのクラスローディングについて」を参照してください。
WEB-INF/classes ディレクトリ内のクラスは、Web アプリケーションの他の部分とは独立して再デプロイできます。Web アプリケーションの再ロード間隔を設定して、WEB-INF/classes ディレクトリ全体ではなく、更新したクラスのみをデプロイすることも可能です (詳細については、『Oracle Fusion Middleware Oracle WebLogic Server Web アプリケーション、サーブレット、JSP の開発』の「weblogic.xml デプロイメント記述子の要素」を参照)。
デフォルトでは、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 サブディレクトリにあるすべてのファイルとサブディレクトリが、インプレースで再デプロイされます。
アプリケーションまたはスタンドアロン モジュールをデプロイしたら、Administration Console または weblogic.Deployer を使用して、WebLogic Server のデプロイメント コンフィグレーションを変更できます。
Administration Console では、個々のデプロイメント コンフィグレーション プロパティを対話形式で変更できます。一方、weblogic.Deployer では、アプリケーションの再コンフィグレーションに使用する更新されたデプロイメント プラン ファイルのみを指定できます。
Administration Console を使用すると、アプリケーションのデプロイメント プランに含まれていないプロパティを含む、アプリケーションのすべての再デプロイメント コンフィグレーション プロパティを再コンフィグレーションできます。アプリケーションがデプロイメント プランと共にデプロイされた場合、コンソールでは、そのアプリケーションの [デプロイメント プラン] タブに、デプロイメント プランのコンフィグレーション プロパティが表示されます。
アプリケーションの他のコンフィグレーション タブを使用して、WebLogic Server の他のコンフィグレーション プロパティを変更できます。コンフィグレーションで使用できる具体的なプロパティは、デプロイされているアプリケーションや J2EE モジュールの種類によって異なります。これらのタブは、アプリケーションがデプロイメント プランと共にデプロイされているかどうかに関わらず使用できます。
一部のコンフィグレーションの変更は実行中のプロダクション アプリケーションに適用可能ですが、それ以外の変更にはアプリケーションの停止と再起動が必要になります。「デプロイメント コンフィグレーション変更のための再デプロイメント動作について」を参照してください。
デプロイメント プランで定義されたプロパティを Administration Console を使用して変更すると、コンソールは、変更した新しいプロパティの変数定義とプランで定義されている既存の変数を含む、新しいデプロイメント プランを生成します。新しいデプロイメント プランの保存先を選択できます。
weblogic.Deployer ユーティリティでは、アプリケーションで使用する新しいデプロイメント プランを指定すると、アプリケーションのデプロイメント コンフィグレーションを更新できます。
|
注意 : 更新されたデプロイメント プランは、アプリケーションの現在の対象サーバで有効でなければなりません。有効でない場合、コンフィグレーションの更新は失敗します。 |
別の (有効な) デプロイメント プランでアプリケーションを再コンフィグレーションするには、-update コマンドを使用して、新しいデプロイメント プラン ファイルを指定します。
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -update -name myTestDeployment
-plan /myDeployments/myNewPlan.xml
|
注意 : 一部のコンフィグレーションの変更は実行中のプロダクション アプリケーションに適用可能ですが、それ以外の変更にはアプリケーションの停止と再起動が必要になります。「デプロイメント コンフィグレーション変更のための再デプロイメント動作について」を参照してください。 |
|
注意 : この節で説明する再デプロイメント動作は、Administration Console およびweblogic.Deployer -update コマンドを使用して行われた両方のコンフィグレーションの変更に適用されます。 |
デプロイされているアプリケーションのデプロイメント コンフィグレーションを変更する場合、WebLogic Server は再デプロイメント処理を使用して変更を適用します。使用される再デプロイメント方式の種類は、適用されるコンフィグレーションの変更の性質によって異なります。リソース バインディング プロパティの値を変更した場合は、コンフィグレーションの更新で、プロダクション再デプロイメント方式 (そのアプリケーションがプロダクション再デプロイメントをサポートしている場合)、またはアプリケーション全体に対してインプレース再デプロイメント方式が使用されます。プロダクション環境では、アプリケーション全体またはモジュールに対してインプレース再デプロイメントを実行することはお勧めできません。アプリケーションは最初にアンデプロイされるので、接続しているクライアントが進行中の作業を失うおそれがあるためです。詳細については、「再デプロイメント方式の概要」を参照してください。
