9 デプロイされたアプリケーションの管理

以下の節では、現在 WebLogic Server ドメインにデプロイされているアプリケーションとモジュールの一般的な保守タスクを実行する方法について説明します。

• プロダクション アプリケーションのオフライン化

• 共有ライブラリおよびパッケージのアンデプロイ

• デプロイされたエンタープライズ アプリケーションへの新しいモジュールの追加

• サーバ起動時のデプロイメント順の変更

• 既存のデプロイメントの対象リストの変更

• Web アプリケーション デプロイメントからのファイルの削除

• 長時間かかるデプロイメント タスクの管理

• 内部アプリケーションのオンデマンド デプロイメント

プロダクション アプリケーションのオフライン化

WebLogic Server では、テストまたは保守目的でアプリケーションをオフラインにする方法が 2 つあります。

• アプリケーションの停止によるクライアント アクセスの制限 - アプリケーションでクライアント要求を処理できないようにしますが、WebLogic Server ドメインからデプロイメントは削除されません。アプリケーションを停止するとデプロイメントは管理モードになり、コンフィグレーション済みの管理チャネルを使用して内部的なテストを実行できるようになります。

• アプリケーションまたはモジュールのアンデプロイ - アプリケーションでクライアント要求を処理できないようにし、WebLogic Server で生成したデプロイメント ファイルをドメインから削除します。

アプリケーションの停止によるクライアント アクセスの制限

「プロダクション環境へのアプリケーションの分散」で説明するように、アプリケーションを分散して管理モードで起動すると、アプリケーションへのアクセスはコンフィグレーション済みの管理チャネルに制限されます。実行中のアプリケーションでクライアント要求の処理を停止して、そのアプリケーションを管理モードにすることもできます。プロダクション環境では、報告された問題を確認するためにアプリケーションを停止したり、定期的な保守を行うためにアプリケーションを外部クライアントの処理から分離したりできます。

実行中のアプリケーションを管理モードにするには、-stop コマンドを使用します。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -name mymodule -stop -adminmode

デフォルトでは、WebLogic Server は、保留中の HTTP セッションや進行中の作業を考慮せずに、アプリケーションを直ちに停止します。アプリケーションでクライアント要求の処理を停止して、そのアプリケーションを管理モードにする前に、保留中の HTTP セッションが作業を完了するのを待機する場合は、-graceful オプションを追加します。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -name mymodule -stop -adminmode -graceful

注意 : -appversion オプションでアプリケーションのバージョンを明示的に指定しない場合、-stop コマンドはアプリケーションのアクティブなバージョンのみを停止します。停止する他のアプリケーション バージョン (または、アクティブなバージョンの代わりに停止するアプリケーション バージョン) がある場合は、-appversion オプションで指定する必要があります。

以前に停止したアプリケーションを再起動して外部クライアントから使用できるようにするには、-start コマンドを使用してデプロイメント名を指定します。停止していたアプリケーションを使用可能にするために再デプロイする必要はありません。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -name mymodule -start

アプリケーションまたはモジュールのアンデプロイ

新しいアプリケーションまたはスタンドアロン モジュールをドメイン内のサーバにデプロイした後、デプロイメント名は選択したデプロイメント ファイルに関連付けられたままになります。すべてのサーバ上でデプロイメントを停止した後でも、ファイルは、Administration Console または weblogic.Deployer ユーティリティを使用した再デプロイメントに使用できる状態になっています。

デプロイメント名および関連付けられたデプロイメント ファイルをドメインから削除するには、アプリケーションまたはスタンドアロン モジュールを明示的にアンデプロイする必要があります。weblogic.Deployer を使用してデプロイメント ユニットをドメインからアンデプロイするには、-undeploy コマンドを指定します。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -name mymodule -undeploy

注意 : -targets および -submoduletargets フラグを指定しないで -undeploy コマンドを使用すると、すべての WebLogic Server インスタンスからアプリケーションまたはスタンドアロン モジュールが完全に削除され、すべての JMS サブモジュール リソースの対象指定が解除されます。

デフォルトでは、WebLogic Server は現在のクライアントや進行中の作業を中断して、アプリケーションを直ちに停止してアンデプロイします。プロダクション環境では、現在の HTTP クライアントが作業を完了できるように、「正常に (gracefully)」アンデプロイすることもできます。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -name mymodule -undeploy -graceful

デプロイメント ユニットをアンデプロイしても、デプロイメントに使用した元のソース ファイルは削除されません。ドメインからデプロイメントのコンフィグレーションが削除されるだけです。また、WebLogic Server がデプロイメント時に作成したデプロイメント ファイルも削除されます (たとえば、stage デプロイメント モードでコピーされたファイルや、管理サーバにアップロードされたファイルなど)。

アンデプロイ後にデプロイメント ユニットを再デプロイする必要がある場合は、「weblogic.Deployer によるアプリケーションおよびモジュールのデプロイ」の指示に従って、デプロイメント ファイル、対象、ステージング モード、およびデプロイメント名を再び指定する必要があります。

共有ライブラリおよびパッケージのアンデプロイ

共有 J2EE ライブラリまたはオプション パッケージは、そのライブラリまたはパッケージを参照するすべてのアプリケーションがアンデプロイされるまでは、アンデプロイできません。アプリケーションまたはパッケージを参照するアプリケーションがない場合は、「アプリケーションまたはモジュールのアンデプロイ」の手順に従ってアンデプロイしてください。

デプロイされたエンタープライズ アプリケーションへの新しいモジュールの追加

WebLogic Server のモジュール レベルの対象指定を利用すると、すでにデプロイされている他のモジュールを再デプロイしなくても、新しいエンタープライズ アプリケーション モジュールを追加およびデプロイできます。EAR 内に新しいモジュールをデプロイするには、「モジュール対象指定の構文」で説明されているモジュール レベルの対象指定構文を使用するだけです。

たとえば、myapp.ear という名前のデプロイ済みエンタープライズ アプリケーションにモジュール newmodule.war を追加する場合は (必要に応じて application.xml ファイルを更新)、次のように weblogic.Deployer コマンドを使用して newmodule.war をデプロイできます。

java weblogic.Deployer -username myname -password mypassword 
   -name myapp.ear -deploy -targets newmodule.war@myserver 
   -source /myapp/myapp.ear

このコマンドでは、アプリケーション内のその他のモジュールは再デプロイせずに、新しいモジュールをデプロイします。EAR ファイル内のアーカイブされたモジュールの正しいファイル拡張子 (上の例では .war) を指定する必要があります。

サーバ起動時のデプロイメント順の変更

デフォルトでは、WebLogic Server は以下の順序でアプリケーションおよびリソースをデプロイします。

1. JDBC システム モジュール

2. JMS システム モジュール

3. J2EE ライブラリおよびオプション パッケージ

4. アプリケーションおよびスタンドアロン モジュール

5. 起動クラス

   
   

   注意 : WebLogic Server セキュリティ サービスは常に、サーバ リソース、アプリケーション、および起動クラスがデプロイされる前に初期化されます。したがって、起動クラスを使用してカスタム セキュリティ プロバイダをコンフィグレーションすることはできません。また、カスタム セキュリティ プロバイダの実装が JDBC などのデプロイ済みサーバ リソースに依存することもできません。

   
   

アプリケーションおよびスタンドアロン モジュールのデプロイメント順の変更

Administration Console で AppDeploymentMBean DeploymentOrder 属性を設定して (または、AppDeploymentMBean をプログラム的に使用して)、デプロイされたアプリケーションまたはスタンドアロン モジュールのデプロイメント順序を変更することができます。DeploymentOrder 属性は、デプロイメントの (相対的な) ロード順序を制御します。DeploymentOrder の値が小さいモジュールが、値の大きいモジュールよりも先にデプロイされます。デフォルトでは、各デプロイメント ユニットの [デプロイ順序] の値は 100 にコンフィグレーションされます。[デプロイ順序] の値が同じデプロイメントは、デプロイメント名のアルファベット順にデプロイされます。どんな場合でも、アプリケーションとスタンドアロン モジュールは、WebLogic Server インスタンスが依存するサブシステムを初期化した後でデプロイされます。

注意 : weblogic.Deployer ユーティリティを使用してアプリケーションおよびスタンドアロン モジュールのロード順を変更することはできません。

Administration Console を使用してデプロイメントのデプロイ順序を表示または変更するには、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「サーバのデプロイ順の変更」の手順に従います。

エンタープライズ アプリケーションにおけるモジュールのデプロイメント順の変更

エンタープライズ アプリケーションに含まれているモジュールは、application.xml デプロイメント記述子で宣言されている順序でデプロイされます。『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションの開発』の「エンタープライズ アプリケーションのデプロイメント記述子の要素」を参照してください。

起動クラスの実行およびデプロイメントの順序付け

デフォルトでは、サーバで JMS サービスと JDBC サービスが初期化され、アプリケーションおよびスタンドアロン モジュールがデプロイされた後に WebLogic Server の起動クラスが実行されます。

JMS サービスと JDBC サービスが使用可能になった後、アプリケーションおよびモジュールがアクティブ化される前に起動タスクを実行する場合は、Administration Console で [アプリケーション アクティブ化の前に実行] オプションを選択します (または StartupClassMBean の LoadBeforeAppActivation 属性を「true」に設定します)。

JMS サービスと JDBC サービスが使用可能になる前に起動タスクを実行する場合は、Administration Console で [アプリケーション デプロイメントの前に実行] オプションを選択します (または StartupClassMBean の LoadBeforeAppDeployments 属性を「true」に設定します)。

Administration Console で [アプリケーション デプロイメントの前に実行] または [アプリケーション アクティブ化の前に実行] を選択するには、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「起動クラスのコンフィグレーション」を参照してください。

次の図は、WebLogic Server でいつ起動クラスが実行されるかを簡単に示しています。

図 9-1 起動クラスの実行

詳細については、StartupClassMBean の詳細な Javadocs を参照してください。

既存のデプロイメントの対象リストの変更

WebLogic Server ドメインにアプリケーションまたはスタンドアロン モジュールをデプロイした後、新しい WebLogic Server インスタンスを追加したり、既存のサーバ インスタンスを削除したりして、対象サーバ リストを変更できます。対象サーバを削除した場合、対象リストだけが更新されます。デプロイメント ユニットは、明示的にアンデプロイするまで、削除したサーバにデプロイされた状態のままです。同様に、新しい対象サーバを追加した場合は、デプロイメント ユニットを新しいサーバに明示的にデプロイする必要があります。そうしないと、モジュールはそのサーバ上でアクティブになりません。

weblogic.Deployer を使用して新しいサーバを対象リストに追加するには、-deploy コマンドで対象サーバの新しいリストを指定します。次に例を示します。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -name mydeploymentname -deploy 
   -targets server1, newserver

Web アプリケーション デプロイメントからのファイルの削除

展開されたアーカイブ ディレクトリを使用して Web アプリケーションをデプロイする場合、ファイルを更新するか (「デプロイされたアプリケーションにおける静的ファイルの更新」を参照)、デプロイメントからファイルを削除することによって、Web アプリケーションの静的なコンテンツを更新できます。ファイルを削除するには、weblogic.Deployer ユーティリティに delete_files オプションを指定して使用します。次に例を示します。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -name mywebapp -delete_files mywebapp/copyright.html

更新されるファイルのパス名は、常に、展開されたアーカイブ ディレクトリの最上位レベルから指定します。上記の例では、Web アプリケーションは mywebapp という名前の展開されたアーカイブ ディレクトリにあります。

注意 : -delete_files オプションでは、指定されたすべてのファイル (ディレクトリを指定してディレクトリ内のファイルを指定していない場合は、指定されたディレクトリ内のすべてのファイル) が削除されるため、delete_files オプションは慎重に使用し、プロダクション環境では delete_files オプションを使用しないことをお勧めします。

長時間かかるデプロイメント タスクの管理

WebLogic Server のデプロイメント システムはデプロイメント タスクにユニークな ID を自動的に割り当てるので、デプロイメント タスクの進捗状況を追跡して管理できます。weblogic.Deployer では、デプロイメント コマンドで使用するために独自のタスク ID を割り当てたり、長時間かかるデプロイメント タスクのモニタや取り消しを行えます。

たとえば、以下のコマンドでは、redeployPatch2 というタスク ID を新しいデプロイメント処理に割り当てます。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -name mymodule -targets myserver -id redeployPatch2
   -nowait -deploy c:\localfiles\myapp.ear

このタスクのステータスを後でチェックできます。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -id redeployPatch2 -list

次のように、実行中のすべてのタスクの状況をチェックできます。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -listtask

タスクの完了に時間がかかりすぎる場合は、タスクを取り消すことができます。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -id redeployPatch2 -cancel

内部アプリケーションのオンデマンド デプロイメント

起動時に、多くの内部アプリケーションがデプロイされます。これらの内部アプリケーションは、メモリを消費し、デプロイメント時に CPU 時間を必要とします。その結果、WLS の起動時間と基本メモリの占有量が増えてしまいます。これらの多くの内部アプリケーションはすべてのユーザが必要なわけではないため、WLS は、これらのアプリケーションをサーバの起動時に常にデプロイするのではなく、最初のアクセス時に (必要なときに) 待機およびデプロイするように更新されました。これにより、起動時間が短縮され、メモリ占有量が少なくなります。

内部アプリケーションのタイプ

内部アプリケーションには、2 つの異なるタイプがあります。1 つ目のタイプは、ユーザ インタフェースを表示するものです。このタイプには、Administration Console、UDDI エクスプローラ、および WLS テスト クライアントがあります。2 つ目のタイプは、ユーザ インタフェースを表示しないものです。このタイプには、UDDI、デプロイメントと管理ファイル配布を行う内部サーブレットがあります。

ユーザ インタフェースを持つアプリケーションの場合、WLS によって、オンデマンド デプロイメントが実行中であることを示すステータス ページが表示されます。このページは、2 秒ごとに更新されます。内部アプリケーションがデプロイメントを完了すると、内部アプリケーションにリダイレクトされます。このステータス ページは、各アプリケーションの最初のアクセス時に表示されます。以降の呼び出しでは、アプリケーションはデプロイされず、内部アプリケーションのユーザ インタフェースに直接移動します。

オンデマンド デプロイメントのコンフィグレーション

開発ドメインの場合、デフォルトでは、内部アプリケーションが WLS によってオンデマンドでデプロイされます。プロダクション モード ドメインの場合、デフォルトでは、内部アプリケーションが WLS によってサーバ起動時にデプロイされます。デフォルトの動作は、ドメイン MBean の InternalAppsDeployOnDemandEnabled 属性をコンフィグレーションすることによって制御できます。コンフィグレーション設定は、Administration Console または WebLogic Scripting Tool (WLST) を使用して変更できます。

Administration Console を使用したオンデマンド デプロイメントのコンフィグレーション

Administration Console を使用して InternalAppsDeployOnDemandEnabled 属性を変更するには、次の手順を実行します。

1. [ロックして編集] ボタンで編集セッションを開始します。

2. ドメインを選択して、[コンフィグレーション｜全般] ページを開きます。

3. [内部アプリケーションのオンデマンド デプロイメントを有効化] チェック ボックスの設定を変更します。

4. [保存｜変更のアクティブ化] をクリックして変更をアクティブ化し、WLS の次の再起動でその変更が有効になるようにします。

WLST を使用したオンデマンド デプロイメントのコンフィグレーション

WLST を使用して InternalAppsDeployOnDemandEnabled 属性を変更するには、次の手順を実行します。

  connect()
  edit()
  startEdit()
  cmo.setInternalAppsDeployOnDemandEnabled(false)
  activate()