WebLogic Server アプリケーションのデプロイメント

weblogic.deployer によるアプリケーションおよびモジュールのデプロイ

以下の節では、weblogic.Deployer ユーティリティを使用して、コマンドライン ベースの対話的なデプロイメント タスクを実行する方法について説明します。

一般的なデプロイメント シナリオの概要

以下の節では、一般的なデプロイメント タスクをいくつかの一般的なカテゴリにまとめています。最も基本的なタスクから始まり、より高度なタスクへと進みます。アプリケーションをデプロイする前に、「プロダクション デプロイメントのためのアプリケーションのコンフィグレーション」で説明されている適切なタスクを実行します。

リモート クライアントからのデプロイメント ファイルのアップロード

ドメインにアプリケーションまたはモジュールをデプロイするには、デプロイメント ファイルがドメインの管理サーバからアクセス可能でなければなりません。デプロイメント ファイルが管理サーバ マシン上にない場合、またはネットワークにマウントされたディレクトリを通じて管理サーバ マシンから使用できない場合は、-upload オプションを使用して、デプロイする前にファイルをアップロードします。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -deploy -upload c:\localfiles\myapp.ear

展開されたアーカイブ ディレクトリをアップロードするには、アーカイブ ファイル名の代わりにディレクトリ名を指定します (たとえば、c:\localfiles\myappEar)。

管理サーバ マシンにファイルをアップロードすると、アーカイブ ファイルはサーバのアップロード ディレクトリに自動的に配置されます。このディレクトリのパスは、「サーバのデフォルト ステージング動作の変更」にある手順に従ってコンフィグレーションできます。

アプリケーションまたはプランを更新する場合のアップロードの動作

ローカルとリモート (アップロード) のデプロイメント操作を混在させる場合は、アプリケーションのデプロイの過程を追跡するプロセスを用いることが重要です。以下のような一連のイベントを検討してください。

この時点で、アプリケーション (c:\localfiles\myapp.ear) とデプロイメント プラン (c:\localfiles\productionEnvPlan.xml) から派生した動作を想定している管理者または開発者は、混乱してしまう可能性があります。管理者または開発者が、

単一サーバ ドメインへのデプロイ

1 つの管理サーバのみで構成される単一サーバの WebLogic Server ドメインは、アプリケーションまたはモジュールをデプロイするシナリオとしては最も単純なものになります。ドメインと同じマシンにあるファイルをデプロイする場合は、管理サーバの接続引数を指定して -deploy コマンドを使用し、ファイルの場所を指定します。次に例を示します。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -deploy c:\localfiles\myapp.ear

「デフォルト デプロイメント名について」で説明されているように、上記のコマンドで WebLogic Server は、myapp というデフォルト デプロイメント名を作成します。myapp はデプロイメント ファイルの名前から拡張子を除いたものです。デフォルト以外のデプロイメント名を指定する場合は、次のように -name オプションを使用します。

java weblogic.Deployer -adminurl http://localhost:7001 
   -user weblogic -password weblogic -deploy 
   -name myTestApplication c:\localfiles\myapp.ear

アプリケーションまたはモジュールを複数の対象にデプロイする方法については、「サーバ、クラスタ、および仮想ホストへのデプロイメントの対象指定」を参照してください。

デプロイメント プランによるアプリケーションのデプロイ

weblogic.Deployer を使用してアプリケーションをデプロイする場合、デプロイメント プランと WebLogic Server デプロイメント記述子では、対象の環境の有効なコンフィグレーションを定義する必要があります。定義されていない場合、デプロイメントは失敗します。つまり、アプリケーションの必須のリソース バインディングに対して null の変数を定義したデプロイメント プランを指定して、weblogic.Deployer を使用することはできません。

weblogic.Deployer を使用してアプリケーションとデプロイメント プランをデプロイするには、-deploy コマンドと一緒に -plan オプションを指定します。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
     -password weblogic -deploy -name myTestDeployment 
     -source /myDeployments/myApplication.ear
     -targets myCluster -stage 
     -plan /myDeployments/myAppPlan.xml

アプリケーションのルート ディレクトリからデプロイし、デプロイメント プランが /plan サブディレクトリにある場合でも、実際のデプロイメント ソース ファイルと、デプロイメントに使用するプランの両方を指定する必要があります。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
     -password weblogic -deploy -name myTestDeployment 
     -source /myDeployments/installedApps/myApplication/app/myApplication.ear
     -targets myCluster -stage
     -plan /myDeployments/installedApps/myApplication/plan/plan.xml

デプロイメント プランを指定してアプリケーションをデプロイまたは分散する場合、アプリケーションのソース ファイルと一緒に、デプロイメント プランと生成済みデプロイメント記述子が対象サーバのステージング ディレクトリにコピーされます。

preStart 期間中に JNDI からシステム リソースをルックアップするアプリケーションのデプロイ

preStart アプリケーション ライフサイクル リスナはアプリケーションの準備フェーズ中 (編集セッションがアクティブなときに発生) に呼び出されるため、同じ編集セッション中に新しいシステム リソースを作成し、そのシステム リソースを使用するアプリケーションをデプロイすると、システム リソースの JNDI ルックアップは失敗します。たとえば、Administration Console で編集ロックを取得し、新しい JDBC システム リソースを作成して、同じ編集セッション中に (つまり、Administration Console で変更をアクティブ化する前に)、その JDBC システム リソースを使用するアプリケーションをデプロイする場合、システム リソースがアクティブになる前に preStart アプリケーション ライフサイクル リスナが呼び出されるため、JDBC システム リソースの JNDI ルックアップは失敗します。preStart ライフサイクル リスナで JNDI からシステム リソースをルックアップするには、起動時または別の編集セッションでシステム リソースを作成してから、システム リソースを使用するアプリケーションをデプロイすることをお勧めします。たとえば、次のようにします。

詳細については、『WebLogic Server アプリケーションの開発』の「共有 Java EE ライブラリおよびオプション パッケージの概要」を参照してください。

サーバ、クラスタ、および仮想ホストへのデプロイメントの対象指定

ほとんどのプロダクション環境では、通常、WebLogic Server ドメインにコンフィグレーションされている 1 つまたは複数の管理対象サーバにアプリケーションをデプロイします。場合によっては、サーバが WebLogic Server クラスタに含まれていたり、仮想ホストが Web アプリケーションの要求の転送に使用されていることがあります。「デプロイメント対象」とは、アプリケーションまたはモジュールをデプロイできるサーバまたはサーバの集合のことです。

デプロイメント対象について

デプロイメント対象とは、アプリケーションまたはスタンドアロン モジュールをデプロイするサーバまたはサーバのグループです。デプロイメント プロセス中に、ドメインにコンフィグレーションされている使用可能な対象から対象のリストを選択します。モジュールをデプロイした後で対象のリストを変更することもできます。

次の表では、WebLogic Server のすべての有効なデプロイメント対象について説明し、各対象にデプロイできるモジュールの種類を示します。

1 つまたは複数の対象へのデプロイ

1 つの WebLogic Server 対象にデプロイするには、weblogic.Deployer の -targets オプションの後に、コンフィグレーション済みの対象名を指定します。たとえば、companyHost という名前のコンフィグレーション済み仮想ホストに Web アプリケーションをデプロイするには、次のコマンドを使用します。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -deploy -targets companyHost c:\localfiles\myWebApp.ear

複数の対象は、カンマ区切りのリストを使用して指定します。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -deploy -targets ManagedServer-1,ManagedServer-2 
   c:\localfiles\myapp.ear

クラスタ対象へのデプロイ

(-targets mycluster を使用して) クラスタ対象を指定すると、WebLogic Server はデフォルトでは、クラスタ内のすべてのサーバ インスタンスを対象に指定します。これは、ほとんどのクラスタにおいて推奨される、均一なモジュール デプロイメントに対応しています。クラスタ内の 1 つのサーバだけにモジュールをデプロイする (モジュールをサーバに「固定」する) 場合は、対象として、クラスタではなく個別のサーバ インスタンス名を指定します。このタイプのデプロイメントはそれほど一般的ではなく、固定サービスが要求される特別な状況においてのみ行うようにする必要があります。詳細については、『クラスタの使用』の「クラスタのコンフィグレーションについて」を参照してください。

アプリケーションをクラスタ対象にデプロイする場合、WebLogic Server は必ず、クラスタのすべての使用可能なメンバーにデプロイメントを正常にデプロイします。クラスタ内の使用可能な WebLogic Server インスタンスのうち、アプリケーションをデプロイできないインスタンスが 1 つでもあると、デプロイメント全体が失敗して、クラスタ内のどのサーバもそのアプリケーションを起動しません。つまり、デプロイメント処理は 1 つの論理単位として成功または失敗するので、クラスタにおける均一なデプロイメントが維持されます。

クラスタ化されたサーバが、(管理サーバと管理対象サーバの間にネットワーク障害がある、クラスタ メンバーが停止しているなどの理由で) デプロイメントの時点でアクセス不能である場合、そのサーバは、ネットワーク接続が回復するまでデプロイメント要求を受信しません。このデフォルトの動作によって、サーバがオフラインに置かれている場合でも、ほとんどのデプロイメント処理が成功します。

すべてのコンフィグレーション済みクラスタ メンバーへの一貫性のあるデプロイメントの強制

デフォルトのクラスタ デプロイメントの動作では、デプロイメントの時点でアクセス可能なすべてのクラスタ化サーバ インスタンスに対する、均一なデプロイメントが保証されます。ただし、ネットワークの停止が原因で、管理サーバが 1 つまたは複数のクラスタ化サーバにアクセスできない場合、それらのサーバは、ネットワーク接続が回復するまで、デプロイメント要求を受信しません。再デプロイメント処理の場合、この動作は、アクセス不能なサーバがデプロイ済みアプリケーションの古いバージョンを使用する一方で、アクセス可能なサーバは新しいバージョンを使用するという状況につながる可能性があります。ネットワーク接続が回復した場合、以前に接続できなかったサーバは、遅延した再デプロイメント要求を受信して、突然アプリケーションを更新することになります。

WebLogic Server ドメインの起動時に ClusterConstraintsEnabled オプションを設定すると、クラスタに対する WebLogic Server のデフォルトのデプロイメント動作を変更することができます。ClusterConstraintsEnabled オプションは、クラスタ内にコンフィグレーションされているすべてのサーバに対する、厳密なデプロイメントを強制します。クラスタ内のすべてのメンバーがアクセス可能で、指定したファイルをデプロイできる場合にのみ、クラスタへのデプロイメントが成功します。

管理サーバの起動時にドメインに ClusterConstraintsEnabled を設定するには、適切な起動引数を指定します。

モジュール レベルの対象指定を使用したエンタープライズ アプリケーションのデプロイ

エンタープライズ アプリケーション (EAR ファイル) は、他のモジュール タイプ (WAR および JAR アーカイブ) を含むことができるので、他のデプロイメント ユニットとは異なります。Administration Console を使用してエンタープライズ アプリケーションをデプロイする場合は、アーカイブのすべてのモジュールを 1 つのデプロイメント ユニットとして一緒に割り当てることも、個々のモジュールを別々のサーバ、クラスタ、または仮想ホストに割り当てることもできます。

モジュール レベルの対象指定を使用して、EAR 内にあるモジュールのサブセットのみをデプロイすることもできます。複数のモジュールを 1 つの分散可能な EAR にパッケージ化し、各ドメインに必要なモジュールだけを割り当てることによって、アプリケーションのパッケージ化と分散を簡素化することができます。

モジュール対象指定の構文

エンタープライズ アプリケーション内の個々のモジュールを割り当てるには、module_name@target_name 構文を使用します。次に例を示します。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -name myEnterpriseApp
   -targets module1@myserver1,module2@myserver2,module3@myserver3 
   -stage -deploy c:\localfiles\myEnterpriseApp.ear

Web アプリケーション モジュールの対象指定

.ear ファイルの一部である Web アプリケーション モジュールを割り当てるには、Web アプリケーションのコンテキスト ルート名をモジュール名として使用するか、web-uri を指定します。

たとえば、myEnterpriseApp.ear ファイルの application.xml ファイルで次のように定義されている場合は、

<module>
  <web>
    <web-uri>myweb.war</web-uri>
    <context-root>/welcome</context-root>
  </web>
</module>

コンテキスト ルート名を使用して Web アプリケーション モジュールのみをデプロイできます。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -name mywebapplication -targets /welcome@myserver1
   -stage -deploy c:\localfiles\myEnterpriseApp.ear

web-uri を使用して、Web アプリケーション モジュールのみをデプロイできます。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -name mywebapplication -targets myweb.war@myserver1
   -stage -deploy c:\localfiles\myEnterpriseApp.ear

Web アプリケーションをデフォルト Web アプリケーションとしてデプロイするには、context-root 要素の値を「/」に設定します。たとえば、myEnterpriseApp.ear ファイルの application.xml ファイルで次のように定義されている場合は、

<module>
  <web>
    <web-uri>myweb.war</web-uri>
    <context-root>/</context-root>
  </web>
</module>

コンテキスト ルート名を使用して Web アプリケーション モジュールのみをデプロイできます。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -name mywebapplication -targets /@myserver1
   -stage -deploy c:\localfiles\myEnterpriseApp.ear

JDBC、JMS、および WLDF アプリケーション モジュールのデプロイ

スタンドアロンの JDBC、JMS、および WLDF アプリケーション モジュールは、スタンドアロンの Java EE モジュールと同じようにデプロイできます。スタンドアロンの JDBC、JMS、または WLDF アプリケーション モジュールの場合、対象のリストによって、モジュールを利用できる WebLogic Server ドメインが決まります。アプリケーション モジュール内で指定された JNDI 名はグローバル名としてバインドされ、クライアントから使用可能になります。たとえば、スタンドアロンの JDBC アプリケーション モジュールを 1 つのサーバ対象にデプロイした場合、その JDBC モジュールで定義されているリソースを必要とするアプリケーションは、同じサーバ インスタンスにのみデプロイできます。アプリケーション モジュールを複数のサーバに割り当てることも、WebLogic Server クラスタに割り当てて他のサーバでリソースを使用できるようにすることもできます。

JDBC、JMS、または WLDF リソースをドメイン内のすべてのサーバで使用できるようにする必要がある場合は、デプロイ可能なアプリケーション モジュールではなく、システム モジュールを作成します。『WebLogic JMS のコンフィグレーションと管理』の「基本 JMS システム リソースのコンフィグレーション」、『WebLogic JDBC のコンフィグレーションと管理』の「WebLogic JDBC リソースのコンフィグレーション」、および『WebLogic 診断フレームワークのコンフィグレーションと使い方』の「診断システム モジュールのコンフィグレーション」を参照してください。

アプリケーション スコープの JMS、JDBC、および WLDF モジュールの対象指定

JDBC、JMS、および WLDF アプリケーション モジュールは、アプリケーション スコープのリソース モジュールとして、エンタープライズ アプリケーションに含まれる場合もあります。必要な場合は、デプロイメント時にモジュール レベルの対象指定構文を使用して、アプリケーション スコープのリソース モジュールを、他の EAR モジュールとは別に割り当てることができます。次に例を示します。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -name myEnterpriseApp
   -targets myWebApp@myCluster,myJDBCModule@myserver1,myEJBModule@myserver1 
   -stage -deploy c:\localfiles\myEnterpriseApp.ear

JMS アプリケーション モジュールにおけるサブモジュールの対象指定の使用

JMS アプリケーション モジュールの内部で定義されている特定の JMS リソースを、そのモジュールの対象で使用可能になっている JMS サーバに、デプロイメント時にさらに割り当てることができます。このようなリソースをサブモジュールといいます。次のタイプのサブモジュールは JMS サーバにデプロイする必要があります。

他のサブモジュールは、JMS サーバに加えて、WebLogic Server インスタンスやクラスタに割り当てることができます。

デプロイメント時またはアンデプロイメント時にサブモジュールの対象を指定するには、モジュール対象指定の構文を拡張して、weblogic.Deployer に -submoduletargets オプションを指定する必要があります。

デフォルトのサブモジュールの対象指定

Administration Console からデプロイするときには、『WebLogic JMS のコンフィグレーションと管理』の「JMS システム モジュールとリソースのサブデプロイメントの対象指定」で説明されているように、WebLogic Server は、JMS アプリケーション モジュール内のサブモジュール用に、デフォルトの JMS サーバ対象を選択します。

WLST を使用してサブモジュールをデプロイするときには、以下のすべての条件が満たされる場合に、親モジュールの対象を JMS リソースのデフォルトの対象として使用できます。

『WebLogic Scripting Tool ガイド』の「デプロイメント コマンド」を参照してください。

スタンドアロン JMS モジュールにおけるサブモジュールの対象指定

スタンドアロンの JMS モジュールの場合、サブモジュールの対象指定の構文は -submoduletargets submodule_name@target_name になります。たとえば、1 つのサーバ インスタンスにスタンドアロンの JMS モジュールをデプロイするとき、JMSServer1 という JMS サーバにサブモジュール myQueue を割り当てるには、次のコマンドを入力します。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -name myJMSModule
   -targets ManagedServer1 -submoduletargets myQueue@JMSServer1
   -deploy c:\localfiles\myJMSModule.xml

同じ JMS モジュールをアンデプロイするには、次のコマンドを入力します。このコマンドでは、myJMSModule の中に複数のサブモジュールがあると想定し、myQueue サブモジュールのみをアンデプロイします。他のサブモジュールは影響を受けません。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -name myJMSModule
   -undeploy -submoduletargets myQueue@JMSServer1

アプリケーション スコープの JMS モジュールにおけるサブモジュールの対象指定

EAR 内のアプリケーション スコープの JMS モジュールの場合は、submodule_name@module_name@target_name という構文を使用して、サブモジュールを割り当てます。たとえば、上記の例のキューがエンタープライズ アプリケーションの一部としてパッケージ化されている場合は、次のコマンドを使用します。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -name myEnterpriseApp
   -targets ManagedServer1 -submoduletargets myQueue@myJMSModule@JMSServer1
   -deploy c:\localfiles\myEnterpriseApp.ear

同じ JMS モジュールをアンデプロイするには、次のコマンドを入力します。このコマンドでは、myEnterpriseApp の中に複数のサブモジュールがあると想定し、myQueue サブモジュールのみをアンデプロイします。他のサブモジュールは影響を受けません。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -name myEnterpriseApp
   -undeploy -submoduletargets myQueue@myJMSModule@JMSServer1

JMS サブデプロイメントの詳細については、『WebLogic JMS のコンフィグレーションと管理』の「JMS システム モジュールとリソースのサブデプロイメントの対象指定」を参照してください。

ステージング モードによるデプロイメント ファイルのコピーの制御

デプロイメントのステージング モードにより、デプロイメント ファイルを、アプリケーションまたはスタンドアロン モジュールをデプロイする必要がある対象サーバから使用できるようにする方法が決まります。WebLogic Server のステージング モードには、stage モード、nostage モード、external_stage モードの 3 種類があります。

ステージング モードとベスト プラクティス

次の表では、デプロイメント ステージング モード別にそのモードを使用する場合の動作とベスト プラクティスについて説明します。

サーバのステージング ディレクトリは、管理サーバが stage モード デプロイメント用のデプロイメント ファイルをコピーするディレクトリです。また、external_stage モードを使用してアプリケーションをデプロイする前には、このディレクトリにデプロイメント ファイルが配置されている必要があります。

ほとんどのデプロイメントでは、stage モードまたは nostage モードを使用します。アプリケーションまたはモジュールをデプロイするときに、WebLogic Server のデプロイメント ツールは適切なモードを使用します。以下の節では、アプリケーションまたはモジュールをデプロイするときに、デプロイメントのステージング モードを明示的に設定する方法について説明します。

nostage モードのデプロイメントの使用

nostage モードでは、管理サーバはアーカイブ ファイルをソース位置からコピーしません。代わりに、各対象サーバは、デプロイメント用の単一のソース ディレクトリにあるアーカイブ ファイルにアクセスする必要があります。nostage デプロイメントでは、対象サーバのステージング ディレクトリは無視されます。

たとえば、Java EE アプリケーションをクラスタ内の 3 つのサーバにデプロイする場合、アプリケーションをデプロイするには各サーバが (共有またはネットワーク マウント ディレクトリの) 同じアプリケーション アーカイブ ファイルにアクセスできる必要があります。

nostage モードでは、Web アプリケーション コンテナが JSP およびサーブレットに対する変更を自動的に検出します。また、アプリケーションの一部のみを後から更新することもできます。そのためには、該当する部分をファイル システムの 1 つの位置で更新し、再デプロイします。

Administration Console では、管理サーバのみにデプロイする場合 (単一サーバ ドメインの場合など) のデフォルト モードとして nostage モードが使用されます。weblogic.Deployer では対象サーバのステージング モードを使用し、管理サーバでは nostage モードをデフォルトで使用します。同じマシンでサーバ インスタンスのクラスタを実行する場合、または共有ディレクトリにアクセスできる複数のマシンに非常に大きいアプリケーションをデプロイする場合も、nostage モードを選択できます。非常に大きいアプリケーションを nostage モードでデプロイすると、ファイルがコピーされないため、デプロイ時間を短縮できます。

nostage モードの構文

nostage モードを使用するには、weblogic.Deployer のオプションとして -nostage を指定します。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -name mydeploymentname 
   -targets myserver1,myserver2,myserver3 -nostage 
   -deploy c:\localfiles\myapp.ear

stage モードのデプロイメントの使用

stage モードでは、管理サーバはマシンの元の位置から各対象サーバのステージング ディレクトリにデプロイメント ファイルをコピーします。たとえば、stage モードを使用してクラスタ内の 3 つのサーバに Java EE アプリケーションをデプロイする場合、管理サーバは 3 つのサーバ マシンのそれぞれのディレクトリにデプロイメント ファイルをコピーします。各サーバは、アーカイブ ファイルのローカル コピーを使用して Java EE アプリケーションをデプロイします。

ステージング ディレクトリにファイルをコピーするときに、管理サーバはデプロイメント名と同名のサブディレクトリを作成します。そのため、次のコマンドを使用してデプロイした場合、

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -name mytestear -stage -targets mycluster 
   -deploy c:\bea\wlserver_10.3\samples\server\medrecd\dist\physicianEar

mycluster の各サーバのステージング ディレクトリに新しいディレクトリ mytestear が作成されます。デプロイメント名を指定しないと、次のようにデフォルトのデプロイメント名 (およびステージング サブディレクトリ) が使用されます。

Administration Console では、複数の WebLogic Server インスタンスにデプロイする場合のデフォルト モードとして、stage モードを使用します。weblogic.Deployer ではデフォルトとして対象サーバのステージング モードを使用し、管理対象サーバではデフォルトで stage モードを使用します。

stage モードでは、ネットワーク停止により管理サーバがアクセス不能になった場合でも、各サーバがデプロイメント ファイルのローカル コピーを持つことが保証されます。ただし、非常に大きいアプリケーションを複数のサーバ、またはクラスタにデプロイする場合は、対象サーバへのファイルのコピーに要する時間がかなり長くなることがあります。大きいファイルを複数のサーバにコピーすることによるオーバーヘッドを防ぐには、nostage モードを検討してください。

stage モードの構文

stage モードを使用するには、weblogic.Deployer のオプションとして -stage を指定します。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -name mydeploymentname 
   -targets myserver1,myserver2,myserver3 -stage 
   -deploy c:\localfiles\myapp.ear

external_stage モードのデプロイメントの使用

external_stage モードでは stage モードと同様に、対象サーバはデプロイメント ファイルのローカル コピーを使用してデプロイします。ただし、external_stage モードでは、管理サーバは対象サーバにデプロイメント ファイルを自動的にコピーしません。そのため、デプロイメントの前に、各対象サーバのステージング ディレクトリにファイルをコピーする必要があります。手動でコピーすることも、自動化スクリプトを使用することもできます。

デプロイメント ファイルは、各対象サーバのステージング ディレクトリ内で、デプロイメント名を反映した名前を持つサブディレクトリに格納されている必要があります。この名前は、デプロイメントに対してユーザが入力する名前、またはデフォルトのデプロイメント名 (展開されたアーカイブ ディレクトリの名前、またはアーカイブ ファイル名からファイル拡張子を除いた名前) のどちらでもかまいません。

external_stage モードは、使用することが少ないデプロイメント ステージング モードです。このモードは、通常、必要なファイルの自動コピーをサードパーティのツールによって管理している環境でのみ使用します。非常に大きいアプリケーションを複数のマシンにデプロイする場合で共有ファイル システムがない (nostage モードを使用できない) 場合も、external_stage モードを使用できます。このような場合に external_stage モードを使用すると、デプロイメント時にファイルがコピーされないため、デプロイメントにかかる時間を短縮できます。

-noversion オプションを使用すると、デプロイメント ファイルが管理サーバ上にあるという要件を無効にすることができます。ただし、-noversion オプションを使用するとバージョン情報は無視されるので、バージョン管理されているアプリケーションでは -noversion オプションを使用できません。詳細については、「共通の引数」を参照してください。

external_stage モードの構文

external_stage モードでアプリケーションをデプロイするには、次の手順に従います。

サーバのデフォルト ステージング動作の変更

サーバのステージング モードは、デプロイ時に指定されたモードがない場合のデフォルトのデプロイメント モードになります。たとえば、weblogic.Deployer を使用してアプリケーションまたはスタンドアロン モジュールをデプロイするときにステージング モードを指定しなかった場合、サーバのステージング モードが使用されます。

Administration Console を使用してサーバのステージング モードを設定するには、Administration Console オンライン ヘルプの「サーバのステージング モードの設定」の手順に従ってください。ステージング モードの詳細については、表 6-2 を参照してください。

プロダクション環境へのアプリケーションの分散

アプリケーションの分散とは、デプロイメント ファイルをすべての対象サーバにコピーして検証し、アプリケーションをデプロイメントの準備が整った状態にすることです。アプリケーションを分散したら、そのアプリケーションを管理モードで起動することができます。管理モードでは、アプリケーションに対するアクセスがコンフィグレーション済みの管理チャネルに制限されるので、外部のクライアント接続にアプリケーションを公開せずに、アプリケーションをプロダクション環境に分散 (またはアプリケーションの新しいバージョンを分散) することができます。

管理モードの間は、コンフィグレーション済みの管理チャネル経由でのみアプリケーションに接続できます。したがって、アプリケーションの最終 (状態) チェックを、クライアントを中断させることなくプロダクション環境で直接実行できます。最終テストを行ったら、アプリケーションをアンデプロイしてさらに変更を加えることも、アプリケーションを起動して一般のクライアントから利用できるようにすることもできます。

-adminmode オプションを使用すると、アプリケーションを管理モードで起動できます。詳細については、「分散されたアプリケーションの管理モードでの起動」を参照してください。

WebLogic ドメイン間でデプロイを行う場合、CrossDomainConnector ロールを使用して、外部ドメインからドメイン間呼び出しを実行することができます。すべてのセキュリティ ロールの完全なリストについては、『ロールおよびポリシーによる WebLogic リソースの保護』の「デフォルト グローバル ロール」を参照してください。

アプリケーションの分散

アプリケーションを分散するには、weblogic.Deployer -distribute コマンドを使用します。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
     -password weblogic -distribute -name myTestDeployment
     /myDeployments/myApplication/

分散されたアプリケーションの管理モードでの起動

WebLogic Server がデプロイメント ファイルを分散したら、アプリケーションを管理モードで起動して、コンフィグレーション済みの管理チャネル経由でアプリケーションへのアクセスやテストを行えるようにします。管理チャネルをコンフィグレーションする方法については、『サーバ環境のコンフィグレーション』の「ネットワーク リソースのコンフィグレーション」を参照してください。

分散されたアプリケーションを管理モードで起動するには、-adminmode オプションを指定して -start コマンドを使用します。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
     -password weblogic -start -adminmode -name myTestDeployment
     /myDeployments/myApplication/

分散されたアプリケーションの起動

コンフィグレーション済みの管理チャネルを使用して分散されたアプリケーションの最終テストを行ったら、-adminmode オプションを指定せずに weblogic.Deployer -start コマンドを使用すると、アプリケーションを新しいクライアント接続に公開できます。

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

共有 Java EE ライブラリおよびそれに依存するアプリケーションのデプロイ

WebLogic Server の Java EE ライブラリのサポートにより、複数のエンタープライズ アプリケーション間で、1 つまたは複数の Java EE モジュールまたは JAR ファイルを簡単に共有できます。Java EE ライブラリは、スタンドアロンの Java EE モジュール、エンタープライズ アプリケーション (EAR) 内にパッケージ化された複数の Java EE モジュール、またはデプロイメント時に Java EE アプリケーション コンテナに登録されるプレーンな JAR ファイルです。Java EE ライブラリが登録されたら、そのライブラリを参照するエンタープライズ アプリケーションをデプロイできます。参照側の各アプリケーションは、デプロイメントの際に共有 Java EE ライブラリ モジュールのコピーを受け取り、アプリケーションそのものの一部としてパッケージ化されているかのように、これらのモジュールを使用できます。

共有ライブラリに対するデプロイメント動作について

WebLogic Server では、参照側アプリケーションがデプロイされるときに共有ファイルと参照側アプリケーションを結合することによって、共有 Java EE ライブラリをサポートしています。

まず、Java EE ライブラリをデプロイして、そのデプロイメントがライブラリであることを示すことによって、1 つまたは複数の WebLogic Server インスタンスまたはクラスタに Java EE ライブラリまたはオプション パッケージを登録します (「WebLogic Server でのライブラリの登録」を参照)。ライブラリまたはパッケージをデプロイしても、そのデプロイメントは対象サーバ上でアクティブにはなりません。代わりに、WebLogic Server はデプロイメント ファイルを対象サーバに分散し (nostage デプロイメント モードが使用されている場合)、デプロイメント ファイルの場所、デプロイメント名、ライブラリまたはパッケージのバージョン文字列情報などを記録します。

共有ライブラリまたはパッケージを参照するアプリケーションがデプロイされると、WebLogic Server は名前とバージョン文字列の要件を、サーバに登録済みのライブラリに照らしてチェックします。ライブラリまたはパッケージ名に完全に一致するものが見つからない場合、またはバージョン要件が満たされない場合、そのアプリケーションのデプロイメントは失敗します。

アプリケーションで参照されているすべてのライブラリと名前およびバージョン文字列が一致するものが見つかったら、WebLogic Server はそのライブラリのクラスを参照側アプリケーションのクラスパスに追加し、メモリ内でアプリケーションとライブラリの両方のデプロイメント記述子を結合します。結果としてデプロイされるアプリケーションは、参照されるライブラリがアプリケーションそのものにバンドルされているかのように見えます。

Java EE ライブラリの内容は、エンタープライズ アプリケーション内の他の Java EE モジュールと同様にクラスローダにロードされます。たとえば、EJB モジュールは参照側アプリケーションのクラスローダの一部としてロードされますが、Web アプリケーション モジュールはアプリケーション クラスローダの下のクラスローダにロードされます。共有 Java EE ライブラリが EAR からなる場合は、その EAR の APP-INF/lib または APP-INF/classes サブディレクトリに格納されているクラスも、参照側アプリケーションから使用できるようになります。

現在デプロイされているアプリケーションによって参照されている Java EE ライブラリまたはオプション パッケージをアンデプロイすることはできません。共有ライブラリまたはパッケージをアンデプロイする必要がある場合は、まず、共有ライブラリを使用するすべてのアプリケーションをアンデプロイしてください。通常のアプリケーションの保守作業では、共有ライブラリまたはパッケージの新しいバージョンをデプロイしてから、共有ライブラリの新しいバージョンを使用するために参照側アプリケーションを再デプロイする必要があります。詳細については、『WebLogic Server アプリケーションの開発』の「共有 Java EE ライブラリのマニフェスト属性の編集」を参照してください。

WebLogic Server でのライブラリの登録

共有 Java EE ライブラリは、WebLogic Server コンテナにライブラリとして登録されている、標準の Java EE モジュールまたはエンタープライズ アプリケーションです。Java EE ライブラリを WebLogic Server コンテナに登録するには、次の手順を実行します。

デプロイメント時のライブラリのバージョン指定

ベスト プラクティスとして、開発チームでは常に、ライブラリまたはオプション パッケージのバージョン文字列情報を、デプロイメントのマニフェスト ファイルに含めるようにしてください。バージョン文字列の要件とベスト プラクティスの詳細については、『WebLogic Server アプリケーションの開発』の「共有 Java EE ライブラリのマニフェスト属性の編集」を参照してください。

バージョン文字列情報を含まないライブラリまたはパッケージをデプロイする場合は、以下のいずれかまたは両方のオプションを使用して、コマンドラインで指定することができます。

次に例を示します。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
     -password weblogic -deploy -targets myserver1,myserver2
     -library -libspecver 700 -libimplversion 7.0.0.1Beta 
     /deployments/myLibraryApplication/

ライブラリを参照するアプリケーションのデプロイ

必要なバージョンのライブラリおよびパッケージをデプロイしたら、そのライブラリを参照するエンタープライズ アプリケーションやモジュールをデプロイできます。参照側アプリケーションを正常にデプロイするには、次の 2 つの条件を満たす必要があります。

参照側アプリケーションをデプロイする特別な構文はありません。標準のエンタープライズ アプリケーションまたは Java EE モジュールの場合と同じようにアプリケーションをデプロイします。

アプリケーションのコンフィグレーションでは以下のいずれかが必要です。

バージョン要件が原因で参照側アプリケーションをデプロイできない場合は、衝突しているライブラリまたはパッケージの必要なバージョンを登録してみてください。または、開発チームに相談して、アプリケーションのバージョン要件を緩和できるかどうかを判断してください。詳細については、『WebLogic Server アプリケーションの開発』の「エンタープライズ アプリケーションでの共有 Java EE ライブラリの参照」を参照してください。

詳細については、『WebLogic Server アプリケーションの開発』の「共有 Java EE ライブラリおよびオプション パッケージの概要」を参照してください。

アプリケーションのデプロイのベスト プラクティス

アプリケーションをデプロイするときには、以下のベスト プラクティスをお勧めします。