WebLogic Server 9.1 アプリケーションのデプロイメント
![]() |
![]() |
![]() |
![]() |
以下の節では、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 の各再デプロイメント方式の概要を示し、各方式を使用するシナリオについて説明します。
WebLogic Server は、アプリケーションの既存のクライアントに影響を与えずに、また、新しいクライアント要求に対するアプリケーションの可用性を中断することなく、プロダクション アプリケーションの更新済みの新しいバージョンを再デプロイできます。
WebLogic Server では、アプリケーションの実行中の古いバージョンと並行して、新しいバージョンのアプリケーションをデプロイすることによって、プロダクション再デプロイメントを実行します。再デプロイメントが行われている間は、一方のバージョンのアプリケーションが「アクティブ」になり、もう一方のバージョンは「廃止中」になります。アクティブなバージョンのアプリケーションは、そのアプリケーションに対する新しいクライアント接続をすべて受信します。一方、廃止中のバージョンのアプリケーションは、再デプロイメントが行われたときに存在していたクライアント接続のみを処理します。WebLogic Server は、アプリケーションのすべての既存のクライアントが作業を終えた後で、またはコンフィグレーションされているタイムアウトに達した時点で、廃止中のバージョンのアプリケーションをアンデプロイします。
アプリケーションの新しいバージョンを再デプロイすると、WebLogic Server では、新しくデプロイされたアプリケーションのバージョンをアクティブなバージョンとして扱い、古い方のバージョンの廃止を開始します。廃止期間中、WebLogic Server はアプリケーションの HTTP セッションと進行中のトランザクションを自動的に追跡します。WebLogic Server はセッションが完了するかタイムアウトするまで、各 HTTP セッションを追跡します。進行中のトランザクションは、トランザクションが完了、ロールバック、またはトランザクションのタイムアウト期間に達するまで追跡されます。
古い方のアプリケーション バージョンをアクティブにすると、プロダクション再デプロイメントのプロセスをロールバックできます。この操作は、たとえば、新しいバージョンのアプリケーションに問題があると判断した場合や、クライアントを古い方のバージョンに戻したい場合などに必要になります。古い方のアプリケーション バージョンをアクティブにするには、そのバージョンを再デプロイします。
WebLogic Server クラスタでは、クラスタ化された各サーバ インスタンスは、現在の作業負荷を完了した時点で、廃止中のアプリケーション バージョンのローカル デプロイメントを廃止します。つまり、アプリケーション バージョンは、クラスタ内の他のサーバで廃止される前に、クラスタ化された一部のサーバ インスタンスで廃止される可能性があります。ただし、クラスタのフェイルオーバでは、クライアントのフェイルオーバ要求は常に、そのアプリケーション バージョンがまだ使用可能な場合は、セカンダリ サーバにある同じアプリケーション バージョンで処理されます。同じアプリケーション バージョンがセカンダリ サーバで使用可能でない場合、フェイルオーバは成功しません。
プロダクション再デプロイメント機能を使用するには、開発時およびデプロイメントの段階で、アプリケーションは以下の要件を満たす必要があります。
プロダクション再デプロイメント方式は、スタンドアロンの Web アプリケーション (WAR) モジュールと、クライアントが Web アプリケーション (HTTP) 経由でアクセスするエンタープライズ アプリケーション (EAR) に対してのみ提供されます。また、グローバルな JMS 送り先からの着信 JMS メッセージまたは着信 JCA リクエストによってアクセスされるエンタープライズ アプリケーションもサポートされます。
プロダクション再デプロイメントはスタンドアロンの EJB または RAR モジュールではサポートされません。また、スタンドアロンまたは組み込みの Web サービス モジュールでもサポートされません。そのようなモジュールでプロダクション再デプロイメントを使用しようとすると、WebLogic Server は再デプロイメント要求を拒否します。そのようなモジュールを再デプロイするには、バージョン識別子を削除して、モジュールを明示的に再デプロイします。
さらに、以下のものに対しては、プロダクション再デプロイメントはサポートされません。
JDBC アプリケーション モジュールの制限事項の詳細については、『WebLogic JDBC のコンフィグレーションと管理』の「JDBC アプリケーション モジュールの制限事項」を参照してください。
プロダクション再デプロイメントでは HTTP クライアントのみをサポートし、Java クライアントはサポートしません。開発および設計チームでは、プロダクション再デプロイメントを使用するアプリケーションが、サポートされないクライアントからアクセスされないようにする必要があります。WebLogic Server はサポートされないクライアントがアプリケーションにアクセスしたことを検出せず、プロダクション再デプロイメント時にはサポートされないクライアント接続を保護しません。
プロダクション再デプロイメント中にアプリケーションの複数のバージョンが WebLogic Server ドメインで安全に共存できるようにするため、開発時には、特定の要件を満たすようにアプリケーションを設計する必要があります。プロダクション再デプロイメントを使用するアプリケーションで要求されるプログラミング規約については、『WebLogic Server アプリケーションの開発』の「プロダクション再デプロイメント用アプリケーションの開発」を参照してください。
エンタープライズ アプリケーションに JCA リソース アダプタ モジュールが含まれる場合、モジュールは以下の条件を満たす必要があります。
weblogic.connector.extensions.Suspendable
インタフェースを実装していることenable-access-outside-app
が false
(デフォルト値) に設定されており、アプリケーション スコープの方法で使用されていること新しいバージョンの EAR のリソース アダプタがデプロイされる前に、旧バージョンのアプリケーションのリソース アダプタがコールバックを受け取ります。その後で、新しいバージョンのアプリケーションがデプロイされ、旧バージョンの EAR 全体が廃止されます。
リソース アダプタのプロダクション再デプロイメント要件の詳細なリストについては、『WebLogic リソース アダプタ プログラマーズ ガイド』の「プロダクション再デプロイメント」を参照してください。
警告 : プロダクション再デプロイメント方式ではアプリケーションが特定のプログラミング規約を守る必要があるため、開発および設計スタッフが承認したアプリケーションでのみ、プロダクション再デプロイメントを使用してください。BEA のプログラミング規約に従わないアプリケーションでプロダクション再デプロイメントを使用すると、グローバルなリソースが破損したり、望ましくないアプリケーションの動作につながる可能性があります。
デプロイされるアプリケーションでは、そのアプリケーションでプロダクション再デプロイメント処理を実行する前に、バージョン番号を指定する必要があります。つまり、バージョン指定されていないアプリケーションをデプロイし、その後でアプリケーションの新しいバージョンによるプロダクション再デプロイメントを実行することはできません。
WebLogic Server は一度に最大 2 つまで異なるバージョンのアプリケーションをホストできます。
新しいバージョンのアプリケーションを再デプロイするときに、以下の設定を変更することはできません。
上記の機能を変更するには、まず、アプリケーションのアクティブなバージョンをアンデプロイする必要があります。
WebLogic Server では、現在デプロイされているアプリケーションと再デプロイされるアプリケーションが別々のバージョンを指定している場合に、プロダクション再デプロイメント方式を使用しようとします。
アプリケーションにバージョン識別子を割り当てるには、デプロイする EAR または WAR の MANIFEST.MF
ファイルに、ユニークなバージョン文字列を直接格納することをお勧めします。開発プロセスでは、新しいアプリケーションをリリースするたびに自動的にバージョン識別子をインクリメントしてから、アプリケーションをデプロイメント用にパッケージ化するようにしてください。
バージョン情報をこのように管理すると、プロダクション ドメインでアプリケーションが再デプロイされるたびにプロダクション再デプロイメント方式が使用されます。『WebLogic Server アプリケーションの開発』の「プロダクション再デプロイメント用アプリケーションの開発」を参照してください。
プロダクション再デプロイメント機能をテストする場合、またはマニフェスト ファイルにバージョン文字列を含まないアプリケーションに対してプロダクション再デプロイメントを使用する場合は、weblogic.Deployer
ツールを使用し、アプリケーションのデプロイまたは再デプロイ時に -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
内にバージョン文字列を指定していない場合にのみ適用されます。アプリケーションのバージョン文字列で有効な文字と文字形式の詳細については、『WebLogic Server アプリケーションの開発』の「アプリケーションのバージョンの規約」を参照してください。
警告 : プロダクション再デプロイメントに関する BEA のプログラミング規約にアプリケーションが従っていない限り、プロダクション環境で -appversion
を使用してデプロイまたは再デプロイしないでください。プログラミング規約に従わないアプリケーションでプロダクション再デプロイメントを使用すると、グローバルなリソースが破損したり、望ましくないアプリケーションの動作につながる可能性があります。
WebLogic Server Administration Console では、すべてのデプロイ済みアプリケーションおよびモジュールのバージョン文字列情報と状態情報の両方が表示されます。この情報を表示するには、Administration Console の左ペインで [デプロイメント] ノードを選択します。
weblogic.Deployer
-listapps コマンドを使用して、デプロイ済みアプリケーションのバージョン情報をコマンドラインから表示することもできます。
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -listapps
プロダクション再デプロイメント方式を使用してアプリケーションの新しいバージョンを再デプロイするには、次の手順に従います。
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
オプションを指定することはできません。
-appversion
オプションでアプリケーションのバージョンを明示的に指定しない場合、WebLogic Server は、アプリケーションのアクティブなバージョンと廃止されたすべてのバージョンをアンデプロイします。アプリケーションの古いバージョンがまだ廃止されていないときに、-appversion
オプションを指定しないで -undeploy
コマンドを実行すると、WebLogic Server はサーバ ログに警告メッセージを記録し、廃止されていないバージョンのアンデプロイは行いません。そのようなアプリケーションのバージョンを後でアンデプロイするには、-undeploy
コマンドを再び実行し、-appversion
オプションでアプリケーションのバージョンを指定します。
プロダクション再デプロイメント プロセスを元に戻すと、アクティブなアプリケーションと廃止中アプリケーションの状態が切り替わり、新しいクライアント接続要求はそれに従ってリダイレクトされます。アプリケーションの新しくデプロイされたバージョンで問題が見つかった場合や、クライアントが新しいバージョンにアクセスしないようにする場合は、プロダクション再デプロイメント プロセスを元に戻す必要があります。
プロダクション再デプロイメント プロセスをロールバックするには、-redeploy コマンドを再び発行して、古いバージョンのデプロイメント ソース ファイルを指定します。
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -redeploy -name myTestDeployment
-source /myDeployments/myApplication/91Beta
-retiretimeout 300
デプロイメント ファイルのマニフェストにバージョン識別子が含まれていない場合は、「デプロイメントおよび再デプロイメント中のバージョン識別子の割り当て」を参照してください。
アプリケーションの新しいバージョンを分散すると、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
アプリケーションを管理モードで起動すると、コンフィグレーション済みの管理チャネル経由でのみ使用できるようになります。『WebLogic Server 環境のコンフィグレーション』の「ネットワーク リソースのコンフィグレーション」を参照してください。
分散されるアプリケーションの廃止ポリシーやタイムアウト期間を指定することもできます。
コンフィグレーション済みの管理チャネルを使用して最終テストを行ったら、-adminmode
オプションを指定せずに weblogic.Deployer
-start コマンドを使用すると、管理モードで実行中の分散されたアプリケーション バージョンを新しいクライアント接続に公開できます。
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
プロダクション再デプロイメントを使用する場合は、以下のベスト プラクティスに留意してください。
/stage
サブディレクトリ)、関連付けられたアプリケーション バージョンがアンデプロイされるときに削除されます。 /myTestDeployment/.91Beta
および /myTestDeployment/1.0GA
サブディレクトリにコピーする必要があります。
インプレース再デプロイメント方式のしくみは、実行中のアプリケーションのデプロイメント ファイルを、更新されたデプロイメント ファイルで直ちに置き換えることです。アプリケーション全体または J2EE モジュールの再デプロイにインプレース再デプロイメントを使用すると、アプリケーションまたはモジュールはデプロイメント プロセス中に使用できなくなり、既存のクライアントでは進行中の作業が失われる可能性があります。アプリケーションのクラス ファイルとライブラリがクラスローダから直ちにアンデプロイされて、更新されたバージョンで置き換えられるので、このようなクライアント サービスの中断が発生します。
アプリケーションおよびモジュールのインプレース再デプロイメントはアプリケーションのクライアントに悪影響を及ぼすため、次の場合を除いて、プロダクション アプリケーションでは使用しないでください。
WebLogic Server は、バージョン識別子を含まないアプリケーションの場合は、常にインプレース再デプロイメントを実行します。また、部分的な再デプロイメント処理 (アプリケーションの一部分にだけ影響を与える再デプロイメント コマンド) でもインプレース再デプロイメントを使用する場合が多くあります。また、再デプロイされるファイルはアクティブなクライアント接続に悪影響を及ぼさないので、プロダクション アプリケーションで部分的な再デプロイメントを使用できる場合もあります。表 6-2 では、部分的な再デプロイメントの種類と、デプロイされたアプリケーションに与える影響について説明します。
|
|
|
|
||
|
|
インプレース再デプロイメント方式を使用してアプリケーション全体またはスタンドアロン モジュールを再デプロイするには、次の手順に従います。
アプリケーションをオフラインにする具体的な方法は、WebLogic Server ドメインのアーキテクチャによって異なります。多くの場合、冗長サーバやクラスタが作成されていて、アプリケーションのコピーを個別にホストしており、ロード バランシング ハードウェアまたはソフトウェアがサーバやクラスタへのアクセスを管理しています。アプリケーションをオフラインにするには、ロード バランシング ポリシーを変更して、サーバのセットまたはクラスタから冗長セットにすべてのクライアント接続を移します。
たとえば、現在デプロイされているアプリケーションのファイルが次の場所に格納されている場合、
/myDeployments/myApplication/91Beta
更新されたアプリケーション ファイルは、次のような新しいディレクトリに格納します。
/myDeployments/myApplication/1.0GA
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -redeploy -name myApp
アプリケーションがクラスタ化されていない複数のサーバ インスタンスにデプロイされている場合は、次のように対象リストを指定すると、対象サーバのサブセットにのみアプリケーションを再デプロイできます。
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -redeploy -name myApp
-targets myserver1,myserver2
注意 : クラスタにデプロイされたアプリケーションについては、再デプロイメントは常に、クラスタ内のすべての対象サーバ インスタンスで行われます。アプリケーションがクラスタ内のすべてのサーバにデプロイされている場合は、そのアプリケーションをクラスタ内の一部のサーバに再デプロイすることはできません。
インプレース再デプロイメントを使用してアプリケーション全体またはスタンドアロン モジュールを再デプロイする場合は、以下の点に留意してください。
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.
以下の制限事項は、エンタープライズ アプリケーション内のモジュールの部分的な再デプロイメントを行う場合に適用されます。
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 ファイルの再デプロイ時、コンテナは自動的にアプリケーション全体を再デプロイしますが、状態を保持します。エンタープライズ アプリケーション モジュールで部分的な再デプロイメントを行う場合は、以下のベスト プラクティスに留意してください。
WEB-INF/classes
ディレクトリ内のクラスは、Web アプリケーションの他の部分とは独立して再デプロイできます。Web アプリケーションの再ロード間隔を設定して、WEB-INF/classes
ディレクトリ全体ではなく、更新したクラスのみをデプロイすることも可能です (詳細については、『WebLogic Server Web アプリケーション、サーブレット、JSP の開発』の「weblogic.xml デプロイメント記述子の要素」を参照してください)。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
注意 : 一部のコンフィグレーションの変更は実行中のプロダクション アプリケーションに適用可能ですが、それ以外の変更にはアプリケーションの停止と再起動が必要になります。「デプロイメント コンフィグレーション変更のための再デプロイメント動作について」を参照してください。
デプロイされているアプリケーションのデプロイメント コンフィグレーションを変更する場合、WebLogic Server は再デプロイメント処理を使用して変更を適用します。使用される再デプロイメント方式の種類は、適用されるコンフィグレーションの変更の性質によって異なります。リソース バインディング プロパティの値を変更した場合は、コンフィグレーションの更新で、プロダクション再デプロイメント方式 (そのアプリケーションがプロダクション再デプロイメントをサポートしている場合)、またはアプリケーション全体に対してインプレース再デプロイメント方式が使用されます。プロダクション環境では、アプリケーション全体またはモジュールに対してインプレース再デプロイメントを実行することはお勧めできません。アプリケーションは最初にアンデプロイされるので、接続しているクライアントが進行中の作業を失うおそれがあるためです。詳細については、「再デプロイメント方式の概要」を参照してください。
上記の再デプロイメント動作は、Administration Console および weblogic.Deployer
-update コマンドを使用して行われた両方のコンフィグレーションの変更に適用されます。
![]() ![]() |
![]() |
![]() |