Oracle Fusion Middleware Oracle WebLogic Server アプリケーションのデプロイメント 11g リリース 1 (10.3.1) B55511-01 |
|
![]() 戻る |
![]() 次へ |
以下の節では、weblogic.Deployer
ユーティリティを使用して、コマンドライン ベースの対話的なデプロイメント タスクを実行する方法について説明します。
以下の節では、一般的なデプロイメント タスクをいくつかの一般的なカテゴリにまとめています。最も基本的なタスクから始まり、より高度なタスクへと進みます。アプリケーションをデプロイする前に、「プロダクション デプロイメントのためのアプリケーションのコンフィグレーション」で説明されている適切なタスクを実行します。
「リモート クライアントからのデプロイメント ファイルのアップロード」 - アプリケーションまたはモジュールをリモート クライアントから管理サーバにアップロードする方法について説明します。
「単一サーバ ドメインへのデプロイ」 - アプリケーションまたはモジュールを単一サーバ WebLogic ドメインへデプロイする基本について説明します。
「デプロイメント プランによるアプリケーションのデプロイ」 - アプリケーションを完全にコンフィグレーションするデプロイメント プランと共にアプリケーションをデプロイする方法について説明します。
「preStart 期間中に JNDI からシステム リソースをルックアップするアプリケーションのデプロイ」 - JNDI を介してシステム リソースをルックアップするアプリケーションをデプロイする方法について説明します。
「サーバ、クラスタ、および仮想ホストへのデプロイメントの対象指定」 - WebLogic Server の対象のすべての種類と、デプロイメント時に対象を指定する方法について説明します。
「モジュール レベルの対象指定を使用したエンタープライズ アプリケーションのデプロイ」 - エンタープライズ アプリケーション内の個々のモジュールを別々の WebLogic Server 対象に割り当てる方法について説明します。
「JDBC、JMS、および WLDF アプリケーション モジュールのデプロイ」 - WebLogic Server ドメインで、スタンドアロンおよびアプリケーション スコープの JDBC、JMS、および WLDF モジュールをデプロイする方法について説明します。
「ステージング モードによるデプロイメント ファイルのコピーの制御」 - WebLogic Server のファイル コピーの動作を制御するために、デフォルト以外のステージング モードを使用する方法について説明します。
「プロダクション環境へのアプリケーションの分散」 - クライアント要求を処理できない状態にしておいて、新しいアプリケーションをプロダクション環境に直接デプロイしてテストする方法について説明します。
「共有 Java EE ライブラリおよびそれに依存するアプリケーションのデプロイ」 - Java EE ライブラリとオプション パッケージを WebLogic Server 環境にデプロイする方法、これらの共有リソースを参照するアプリケーションやモジュールをデプロイおよび管理する方法について説明します。
「アプリケーションのデプロイのベスト プラクティス」 - 主なデプロイメントのプラクティスをまとめています。
ドメインにアプリケーションまたはモジュールをデプロイするには、デプロイメント ファイルがドメインの管理サーバからアクセス可能でなければなりません。デプロイメント ファイルが管理サーバ マシン上にない場合、またはネットワークにマウントされたディレクトリを通じて管理サーバ マシンから使用できない場合は、-upload
オプションを使用して、デプロイする前にファイルをアップロードします。
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -deploy -upload c:\localfiles\myapp.ear
展開されたアーカイブ ディレクトリをアップロードするには、アーカイブ ファイル名の代わりにディレクトリ名を指定します (たとえば、c:\localfiles\myappEar
)。
管理サーバ マシンにファイルをアップロードすると、アーカイブ ファイルはサーバのアップロード ディレクトリに自動的に配置されます。このディレクトリのパスは、「サーバのデフォルト ステージング動作の変更」にある手順に従ってコンフィグレーションできます。
ローカルとリモート (アップロード) のデプロイメント操作を混在させる場合は、アプリケーションのデプロイの過程を追跡するプロセスを用いることが重要です。以下のような一連のイベントを検討してください。
管理者または開発者は、以下のコマンド使用して、管理対象サーバを持つ管理サーバに、アプリケーション (myapp.ear
) とデプロイメント プラン (productionEnvPlan.xml
) をデプロイします。
java weblogic.Deployer -adminurl http://test:7001 -user weblogic -password weblogic -deploy c:\localfiles\myapp.ear -plan c:\localfiles\productionEnvPlan.xml
管理者または開発者が管理対象サーバ上で WebLogic Portal を使用していて、myapp.ear
アプリケーションに対するコンフィグレーションの変更を保存する場合は、以下のコマンドを使用すると、アプリケーションが保存されるときに、WebLogic Portal がアプリケーションを更新します。
java weblogic.Deployer -adminurl http://test:7001 -user weblogic
-password weblogic -update -name myapp.ear -upload
-plan c:\localfiles\nuPlan.xml
リモート マシンにあるアプリケーションとデプロイメント プラン ファイルが、管理サーバのアップロード ディレクトリにアップロードされます。デプロイメントが更新され、コンフィグレーションでは c:\domain\servers\adminServerName\upload\plan\nuPlan.xml
のデプロイメント プランが使用されます。
この時点で、アプリケーション (c:\localfiles\myapp.ear
) とデプロイメント プラン (c:\localfiles\productionEnvPlan.xml
) から派生した動作を想定している管理者または開発者は、混乱してしまう可能性があります。管理者または開発者が、
アプリケーションとデプロイメント プラン ファイルを確認すると、ファイルは変更されていません。新しい動作の説明はつかないように見えます。
c:\localfiles\myapp.ear
アプリケーション ファイルまたは c:\localfiles\productionEnvPlan.xml
デプロイメント プラン 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 ルックアップは失敗します。たとえば、Administration Console で編集ロックを取得し、新しい JDBC システム リソースを作成して、同じ編集セッション中に (つまり、Administration Console で変更をアクティブ化する前に)、その JDBC システム リソースを使用するアプリケーションをデプロイする場合、システム リソースがアクティブになる前に preStart アプリケーション ライフサイクル リスナが呼び出されるため、JDBC システム リソースの JNDI ルックアップは失敗します。preStart ライフサイクル リスナで JNDI からシステム リソースをルックアップするには、起動時または別の編集セッションでシステム リソースを作成してから、システム リソースを使用するアプリケーションをデプロイすることをお勧めします。たとえば、次のようにします。
Administration Console で [ロックして編集] をクリックして、編集ロックを取得します。
必要なシステム リソースを作成します。詳細については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「JMS システム モジュールの作成」を参照してください。
Administration Console で [変更のアクティブ化] をクリックして、編集セッションを完了します。
Administration Console で [ロックして編集] をクリックして、別の編集ロックを取得します。
手順 2 で作成したシステム リソースを使用するアプリケーションをデプロイします。Administration Console からアプリケーションをデプロイする方法については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「アプリケーションおよびモジュールのデプロイ」を参照してください。
詳細については、『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションの開発』の「共有 Java EE ライブラリおよびオプション パッケージの概要」を参照してください。
ほとんどのプロダクション環境では、通常、WebLogic Server ドメインにコンフィグレーションされている 1 つまたは複数の管理対象サーバにアプリケーションをデプロイします。場合によっては、サーバが WebLogic Server クラスタに含まれていたり、仮想ホストが Web アプリケーションの要求の転送に使用されていることがあります。「デプロイメント対象」とは、アプリケーションまたはモジュールをデプロイできるサーバまたはサーバの集合のことです。
デプロイメント対象とは、アプリケーションまたはスタンドアロン モジュールをデプロイするサーバまたはサーバのグループです。デプロイメント プロセス中に、ドメインにコンフィグレーションされている使用可能な対象から対象のリストを選択します。モジュールをデプロイした後で対象のリストを変更することもできます。
次の表では、WebLogic Server のすべての有効なデプロイメント対象について説明し、各対象にデプロイできるモジュールの種類を示します。
表 6-1 WebLogic Server のデプロイメント対象
対象の種類 | 説明 | 有効なデプロイメント |
---|---|---|
WebLogic Server インスタンス |
単一サーバ ドメインの管理サーバ、管理対象サーバなどの WebLogic Server インスタンス。 |
Java EE アプリケーション Java EE モジュール JMS、JDBC、または WLDF モジュール Java EE ライブラリ |
クラスタ |
複数の WebLogic Server インスタンスのコンフィグレーション済みクラスタ。 |
Java EE アプリケーション Java EE モジュール JMS、JDBC、または WLDF モジュール Java EE ライブラリ |
仮想ホスト |
特定の DNS 名に対する要求を WebLogic Server インスタンスまたはクラスタにルーティングする、コンフィグレーション済みのホスト名。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server サーバ環境のコンフィグレーション』の「仮想ホスティングのコンフィグレーション」を参照。 |
Web アプリケーション |
JMS サーバ |
WebLogic Server ドメインでコンフィグレーションされている JMS サーバ。 |
JMS モジュール内に定義されている JMS キューまたはトピック * * スタンドアロン アプリケーション モジュールとしてデプロイされる場合、JMS、JDBC、または WLDF リソースは、Administration Console では Java EE デプロイメントとして表示される。 スタンドアロンの JMS アプリケーション モジュールは、サーバ、クラスタ、または仮想ホストの対象に割り当てることができる。JMS モジュール内で定義されているキューとトピックは、さらに、コンフィグレーション済み JMS サーバに割り当てることができる。サブモジュールの対象指定の詳細については、「JMS アプリケーション モジュールにおけるサブモジュールの対象指定の使用」を参照。 |
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 つのサーバだけにモジュールをデプロイする (モジュールをサーバに「固定」する) 場合は、対象として、クラスタではなく個別のサーバ インスタンス名を指定します。このタイプのデプロイメントはそれほど一般的ではなく、固定サービスが要求される特別な状況においてのみ行うようにする必要があります。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「クラスタのコンフィグレーションについて」を参照してください。
注意 : クラスタ内の (1 つのサーバではなく) 複数のサーバ インスタンスのサブセットにデプロイメントを固定することはお勧めできません。その場合は警告メッセージが生成されます。 |
アプリケーションをクラスタ対象にデプロイする場合、WebLogic Server は必ず、クラスタのすべての使用可能なメンバーにデプロイメントを正常にデプロイします。クラスタ内の使用可能な WebLogic Server インスタンスのうち、アプリケーションをデプロイできないインスタンスが 1 つでもあると、デプロイメント全体が失敗して、クラスタ内のどのサーバもそのアプリケーションを起動しません。つまり、デプロイメント処理は 1 つの論理単位として成功または失敗するので、クラスタにおける均一なデプロイメントが維持されます。
クラスタ化されたサーバが、(管理サーバと管理対象サーバの間にネットワーク障害がある、クラスタ メンバーが停止しているなどの理由で) デプロイメントの時点でアクセス不能である場合、そのサーバは、ネットワーク接続が回復するまでデプロイメント要求を受信しません。このデフォルトの動作によって、サーバがオフラインに置かれている場合でも、ほとんどのデプロイメント処理が成功します。
デフォルトのクラスタ デプロイメントの動作では、デプロイメントの時点でアクセス可能なすべてのクラスタ化サーバ インスタンスに対する、均一なデプロイメントが保証されます。ただし、ネットワークの停止が原因で、管理サーバが 1 つまたは複数のクラスタ化サーバにアクセスできない場合、それらのサーバは、ネットワーク接続が回復するまで、デプロイメント要求を受信しません。再デプロイメント処理の場合、この動作は、アクセス不能なサーバがデプロイ済みアプリケーションの古いバージョンを使用する一方で、アクセス可能なサーバは新しいバージョンを使用するという状況につながる可能性があります。ネットワーク接続が回復した場合、以前に接続できなかったサーバは、遅延した再デプロイメント要求を受信して、突然アプリケーションを更新することになります。
WebLogic Server ドメインの起動時に ClusterConstraintsEnabled
オプションを設定すると、クラスタに対する WebLogic Server のデフォルトのデプロイメント動作を変更することができます。ClusterConstraintsEnabled
オプションは、クラスタ内にコンフィグレーションされているすべてのサーバに対する、厳密なデプロイメントを強制します。クラスタ内のすべてのメンバーがアクセス可能で、指定したファイルをデプロイできる場合にのみ、クラスタへのデプロイメントが成功します。
警告 : 非常に信頼性の高いネットワーク コンフィグレーションを備えていて、すべてのクラスタ メンバーが常にデプロイメントおよび再デプロイメント要求を受信できる場合以外は、ClusterConstraintsEnabled オプションを使用しないでください。ClusterConstraintsEnabled を使用する場合、使用不能なクラスタ化サーバがあると、たとえば、保守のために 1 つでもサーバが停止していると、WebLogic Server ではクラスタへのすべてのデプロイメント処理が失敗します。 |
管理サーバの起動時にドメインに ClusterConstraintsEnabled
を設定するには、適切な起動引数を指定します。
-DClusterConstraintsEnabled=true
- ドメイン内のサーバに対する厳密なクラスタ デプロイメントを強制します。
-DClusterConstraintsEnabled=false
- すべての使用可能なクラスタ メンバーがアプリケーションまたはモジュールをデプロイするようにします。使用不能サーバが、使用可能なクラスタ化インスタンスへの正常なデプロイメントを妨げることはありません。これは、WebLogic Server のデフォルトのデプロイメント動作に相当します。
エンタープライズ アプリケーション (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
.ear
ファイルの一部である Web アプリケーション モジュールを割り当てるには、Web アプリケーションの context-root
名をモジュール名として使用するか、web-uri
を指定します。
たとえば、myEnterpriseApp.ear
ファイルの application.xml
ファイルで次のように定義されている場合は、
<module> <web> <web-uri>myweb.war</web-uri> <context-root>/welcome</context-root> </web> </module>
context-root
名を使用して 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>
context-root
名を使用して 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 アプリケーション モジュールは、スタンドアロンの Java EE モジュールと同じようにデプロイできます。スタンドアロンの JDBC、JMS、または WLDF アプリケーション モジュールの場合、対象のリストによって、モジュールを利用できる WebLogic Server ドメインが決まります。アプリケーション モジュール内で指定された JNDI 名はグローバル名としてバインドされ、クライアントから使用可能になります。たとえば、スタンドアロンの JDBC アプリケーション モジュールを 1 つのサーバ対象にデプロイした場合、その JDBC モジュールで定義されているリソースを必要とするアプリケーションは、同じサーバ インスタンスにのみデプロイできます。アプリケーション モジュールを複数のサーバに割り当てることも、WebLogic Server クラスタに割り当てて他のサーバでリソースを使用できるようにすることもできます。
JDBC、JMS、または WLDF リソースをドメイン内のすべてのサーバで使用できるようにする必要がある場合は、デプロイ可能なアプリケーション モジュールではなく、システム モジュールを作成します。『Oracle Fusion Middleware Oracle WebLogic Server JMS のコンフィグレーションと管理』の「基本 JMS システム リソースのコンフィグレーション」、『Oracle Fusion Middleware Oracle WebLogic Server JDBC のコンフィグレーションと管理』の「WebLogic JDBC リソースのコンフィグレーション」、および『Oracle Fusion Middleware Oracle WebLogic Server 診断フレームワークのコンフィグレーションと使い方』の「診断システム モジュールのコンフィグレーション」を参照してください。
注意 : JMS モジュールをデプロイしても、必ずしもそのモジュールが適切に割り当てられてアクティブになり、JNDI 名が使用可能になるわけではありません。JMS モジュールが適切に割り当てられるまで、JNDI 名は使用可能になりません。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server JMS のコンフィグレーションと管理』の「JMS リソースのコンフィグレーションについて」を参照してください。 |
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 サーバに加えて、WebLogic Server インスタンスやクラスタに割り当てることができます。
接続ファクトリ
外部サーバ
SAF インポート済み送り先
共通分散トピック
共通分散キュー
デプロイメント時またはアンデプロイメント時にサブモジュールの対象を指定するには、モジュール対象指定の構文を拡張して、weblogic.Deployer
に -submoduletargets
オプションを指定する必要があります。
Administration Console からデプロイするときには、『Oracle Fusion Middleware Oracle WebLogic Server JMS のコンフィグレーションと管理』の「JMS モジュールとサブデプロイメント リソースの対象指定」で説明されているように、WebLogic Server は、JMS アプリケーション モジュール内のサブモジュール用に、デフォルトの JMS サーバ対象を選択します。
WLST を使用してサブモジュールをデプロイするときには、以下のすべての条件が満たされる場合に、親モジュールの対象を JMS リソースのデフォルトの対象として使用できます。
アプリケーションに 1 つまたは複数の JMS モジュールが含まれている。
モジュール対象に関連付けられた JMS サーバ インスタンスが 1 つだけ存在する。
-submoduletargets
オプションが指定されていない。
defaultSubmoduleTargets オプションが true である。
『Oracle Fusion Middleware WebLogic Scripting Tool コマンド リファレンス』の「デプロイメント コマンド」を参照してください。
スタンドアロンの 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
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 送り先の削除が原因で、トランザクションが破棄されたり、メッセージが失われたりする可能性があります。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server JTA プログラマーズ ガイド』の「リソース登録解除の猶予期間」を参照してください。完全に削除するつもりのアプリケーションのみをアンデプロイするようにしてください。アプリケーションへのクライアント アクセスを一時的に停止するには、「weblogic.Deployer コマンドライン リファレンス」で説明するように、 |
JMS サブデプロイメントの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server JMS のコンフィグレーションと管理』の「JMS モジュールとサブデプロイメント リソースの対象指定」を参照してください。
デプロイメントのステージング モードにより、デプロイメント ファイルを、アプリケーションまたはスタンドアロン モジュールをデプロイする必要がある対象サーバから使用できるようにする方法が決まります。WebLogic Server のステージング モードには、stage モード、nostage モード、external_stage モードの 3 種類があります。
次の表では、デプロイメント ステージング モード別にそのモードを使用する場合の動作とベスト プラクティスについて説明します。
表 6-2 アプリケーション デプロイメントのステージング モード
デプロイメントのステージング モード | 動作 | 使用するタイミング |
---|---|---|
stage |
管理サーバは最初にデプロイメント ユニットのソース ファイルを対象サーバのステージング ディレクトリにコピーする (ステージング ディレクトリはデフォルトで 対象サーバは次にデプロイメント ファイルのローカル コピーを使用してデプロイする。 |
|
nostage |
管理サーバはデプロイメント ユニット ファイルをコピーしない。代わりに、すべてのサーバで同じデプロイメント ファイルの物理コピーを使用してデプロイする。それらのファイルは、管理サーバと対象サーバから直接アクセス可能でなければならない。 展開されたアーカイブ ディレクトリの nostage モード デプロイメントでは、WebLogic Server はデプロイメントの JSP またはサーブレットに対する変更を自動的に検出し、デプロイメントを更新する (この動作は必要に応じて無効にできる)。 |
|
external_stage |
管理サーバはデプロイメント ファイルをコピーしない。その代わりに、デプロイメントの前に、(たとえば、デプロイメントの前に手動でファイルをコピーするなどして) デプロイメント ファイルが正しいステージング ディレクトリの位置にコピーされていることを管理者が確認する必要がある。 external_stage デプロイメントでは、管理サーバは検証用にデプロイメント ファイルのコピーを必要とする。対象サーバのステージング ディレクトリ内に存在するデプロイメント ファイルのコピーは、デプロイメントの前には検証されない。
|
|
サーバのステージング ディレクトリは、管理サーバが stage モード デプロイメント用のデプロイメント ファイルをコピーするディレクトリです。また、external_stage モードを使用してアプリケーションをデプロイする前には、このディレクトリにデプロイメント ファイルが配置されている必要があります。
ほとんどのデプロイメントでは、stage モードまたは nostage モードを使用します。アプリケーションまたはモジュールをデプロイするときに、WebLogic Server のデプロイメント ツールは適切なモードを使用します。以下の節では、アプリケーションまたはモジュールをデプロイするときに、デプロイメントのステージング モードを明示的に設定する方法について説明します。
nostage モードでは、管理サーバはアーカイブ ファイルをソース位置からコピーしません。代わりに、各対象サーバは、デプロイメント用の単一のソース ディレクトリにあるアーカイブ ファイルにアクセスする必要があります。nostage デプロイメントでは、対象サーバのステージング ディレクトリは無視されます。
たとえば、Java EE アプリケーションをクラスタ内の 3 つのサーバにデプロイする場合、アプリケーションをデプロイするには各サーバが (共有またはネットワーク マウント ディレクトリの) 同じアプリケーション アーカイブ ファイルにアクセスできる必要があります。
注意 : nostage モードでは、デプロイメント ファイルのソースは、デプロイ時にユーザが指定するパスです (これに対し、stage モードでは各サーバのステージング ディレクトリのパスがソースになります)。ただし、WebLogic Server は、nostage モードの場合でもデプロイメント ファイルの一部を一時ディレクトリにコピーします。このため、ユーザがアーカイブ形式デプロイメントの全体または一部を更新することが可能です。 |
nostage モードでは、Web アプリケーション コンテナが JSP およびサーブレットに対する変更を自動的に検出します。また、アプリケーションの一部のみを後から更新することもできます。そのためには、該当する部分をファイル システムの 1 つの位置で更新し、再デプロイします。
Administration Console では、管理サーバのみにデプロイする場合 (単一サーバ ドメインの場合など) のデフォルト モードとして nostage モードが使用されます。weblogic.Deployer
では対象サーバのステージング モードを使用し、管理サーバでは 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 モードを使用してクラスタ内の 3 つのサーバに Java EE アプリケーションをデプロイする場合、管理サーバは 3 つのサーバ マシンのそれぞれのディレクトリにデプロイメント ファイルをコピーします。各サーバは、アーカイブ ファイルのローカル コピーを使用して Java EE アプリケーションをデプロイします。
ステージング ディレクトリにファイルをコピーするときに、管理サーバはデプロイメント名と同名のサブディレクトリを作成します。そのため、次のコマンドを使用してデプロイした場合、
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -name mytestear -stage -targets mycluster
-deploy c:\Oracle\Middleware\wlserver_10.3\samples\server\medrecd\dist\physicianEar
mycluster
の各サーバのステージング ディレクトリに新しいディレクトリ mytestear
が作成されます。デプロイメント名を指定しないと、次のようにデフォルトのデプロイメント名 (およびステージング サブディレクトリ) が使用されます。
展開されたアーカイブ デプロイメントの場合、デプロイメント名およびステージング サブディレクトリはデプロイするディレクトリの名前になります (上の例では physicianEar
)。
アーカイブされたデプロイメントの場合、デフォルトのデプロイメント名はアーカイブ ファイルの名前から拡張子を除いた名前になります (たとえば、physicianEar.ear
をデプロイする場合のデプロイメント名とステージング サブディレクトリは physicianEar
)。
Administration Console では、複数の WebLogic Server インスタンスにデプロイする場合のデフォルト モードとして、stage モードを使用します。weblogic.Deployer
ではデフォルトとして対象サーバのステージング モードを使用し、管理対象サーバではデフォルトで stage モードを使用します。
stage モードでは、ネットワーク停止により管理サーバがアクセス不能になった場合でも、各サーバがデプロイメント ファイルのローカル コピーを持つことが保証されます。ただし、非常に大きいアプリケーションを複数のサーバ、またはクラスタにデプロイする場合は、対象サーバへのファイルのコピーに要する時間がかなり長くなることがあります。大きいファイルを複数のサーバにコピーすることによるオーバーヘッドを防ぐには、nostage モードを検討してください。
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 モードでは stage モードと同様に、対象サーバはデプロイメント ファイルのローカル コピーを使用してデプロイします。ただし、external_stage モードでは、管理サーバは対象サーバにデプロイメント ファイルを自動的にコピーしません。そのため、デプロイメントの前に、各対象サーバのステージング ディレクトリにファイルをコピーする必要があります。手動でコピーすることも、自動化スクリプトを使用することもできます。
デプロイメント ファイルは、各対象サーバのステージング ディレクトリ内で、デプロイメント名を反映した名前を持つサブディレクトリに格納されている必要があります。この名前は、デプロイメントに対してユーザが入力する名前、またはデフォルトのデプロイメント名 (展開されたアーカイブ ディレクトリの名前、またはアーカイブ ファイル名からファイル拡張子を除いた名前) のどちらでもかまいません。
external_stage モードは、使用することが少ないデプロイメント ステージング モードです。このモードは、通常、必要なファイルの自動コピーをサードパーティのツールによって管理している環境でのみ使用します。非常に大きいアプリケーションを複数のマシンにデプロイする場合で共有ファイル システムがない (nostage モードを使用できない) 場合も、external_stage モードを使用できます。このような場合に external_stage モードを使用すると、デプロイメント時にファイルがコピーされないため、デプロイメントにかかる時間を短縮できます。
-noversion
オプションを使用すると、デプロイメント ファイルが管理サーバ上にあるという要件を無効にすることができます。ただし、-noversion オプションを使用するとバージョン情報は無視されるので、バージョン管理されているアプリケーションでは -noversion オプションを使用できません。詳細については、「共通の引数」を参照してください。
external_stage モードでアプリケーションをデプロイするには、次の手順に従います。
デプロイメント ファイルが管理サーバからアクセス可能であることを確認します。「リモート クライアントからのデプロイメント ファイルのアップロード」を参照してください。
デプロイメントの対象サーバごとに、デプロイメント名と同じ名前のサブディレクトリをステージング ディレクトリに作成します。たとえば、デプロイメント名として myEARExternal
を指定する場合は、各対象サーバのステージング ディレクトリに myEARExternal
というサブディレクトリを作成します。
注意 : デプロイメント時にデプロイメント名を指定しない場合、WebLogic Server によってデフォルトの名前が選択されます。詳細については、「デフォルト デプロイメント名について」を参照してください。 |
プロダクションの再デプロイメントで使用するためにバージョン管理されたアプリケーションをデプロイする場合は、デプロイするアプリケーションのバージョンに対応するサブディレクトリを、アプリケーション ディレクトリの下に作成します。たとえば、myEARExternal
をバージョン レベル 2.0Beta でデプロイする場合、各対象サーバの myEARExternal\2.0Beta
というステージング ディレクトリに、デプロイメント ファイルを置く必要があります。
上記の手順 2 または 3 で作成したステージング サブディレクトリにデプロイメント ファイルをコピーします。
weblogic.Deployer
ユーティリティを使用してアプリケーションまたはモジュールをデプロイします。次に例を示します。
java weblogic.Deployer -adminurl http://localhost:7001 -name weblogic
-password weblogic -external_stage -name myEARExternal
-deploy c:\myapps\myear
サーバのステージング モードは、デプロイ時に指定されたモードがない場合のデフォルトのデプロイメント モードになります。たとえば、weblogic.Deployer
を使用してアプリケーションまたはスタンドアロン モジュールをデプロイするときにステージング モードを指定しなかった場合、サーバのステージング モードが使用されます。
注意 : サーバのステージング モードは、Administration Console を使用するか、JMX を通じて ServerMBean を直接変更することによってのみ、変更できます。サーバのステージング モードを変更しても、既存のアプリケーションには影響しません。既存のアプリケーションのステージング モードを変更するには、アプリケーション デプロイメントをアンデプロイしてから、新しいステージング モードで再デプロイする必要があります。 |
Administration Console を使用してサーバのステージング モードを設定するには、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「サーバのステージング モードの設定」の手順に従ってください。ステージング モードの詳細については、表 6-2 を参照してください。
アプリケーションの分散とは、デプロイメント ファイルをすべての対象サーバにコピーして検証し、アプリケーションをデプロイメントの準備が整った状態にすることです。アプリケーションを分散したら、そのアプリケーションを管理モードで起動することができます。管理モードでは、アプリケーションに対するアクセスがコンフィグレーション済みの管理チャネルに制限されるので、外部のクライアント接続にアプリケーションを公開せずに、アプリケーションをプロダクション環境に分散 (またはアプリケーションの新しいバージョンを分散) することができます。
管理モードの間は、コンフィグレーション済みの管理チャネル経由でのみアプリケーションに接続できます。したがって、アプリケーションの最終 (状態) チェックを、クライアントを中断させることなくプロダクション環境で直接実行できます。最終テストを行ったら、アプリケーションをアンデプロイしてさらに変更を加えることも、アプリケーションを起動して一般のクライアントから利用できるようにすることもできます。
-adminmode
オプションを使用すると、アプリケーションを管理モードで起動できます。詳細については、「分散されたアプリケーションの管理モードでの起動」を参照してください。
WebLogic ドメイン間でデプロイを行う場合、CrossDomainConnector
ロールを使用して、外部ドメインからドメイン間呼び出しを実行することができます。すべてのセキュリティ ロールの完全なリストについては、『Oracle Fusion Middleware Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』の「デフォルト グローバル ロール」を参照してください。
アプリケーションを分散するには、weblogic.Deployer
-distribute
コマンドを使用します。
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -distribute -name myTestDeployment
/myDeployments/myApplication/
WebLogic Server がデプロイメント ファイルを分散したら、アプリケーションを管理モードで起動して、コンフィグレーション済みの管理チャネル経由でアプリケーションへのアクセスやテストを行えるようにします。管理チャネルをコンフィグレーションする方法については、『Oracle Fusion Middleware Oracle 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
WebLogic Server の Java EE ライブラリのサポートにより、複数のエンタープライズ アプリケーション間で、1 つまたは複数の Java EE モジュールまたは JAR ファイルを簡単に共有できます。Java EE ライブラリは、スタンドアロンの Java EE モジュール、エンタープライズ アプリケーション (EAR) 内にパッケージ化された複数の Java EE モジュール、またはデプロイメント時に Java EE アプリケーション コンテナに登録されるプレーンな JAR ファイルです。Java EE ライブラリが登録されたら、そのライブラリを参照するエンタープライズ アプリケーションをデプロイできます。参照側の各アプリケーションは、デプロイメントの際に共有 Java EE ライブラリ モジュールのコピーを受け取り、アプリケーションそのものの一部としてパッケージ化されているかのように、これらのモジュールを使用できます。
注意 : Oracle のドキュメントと WebLogic Server ユーティリティでは、「ライブラリ」という語を 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 ライブラリまたはオプション パッケージをアンデプロイすることはできません。共有ライブラリまたはパッケージをアンデプロイする必要がある場合は、まず、共有ライブラリを使用するすべてのアプリケーションをアンデプロイしてください。通常のアプリケーションの保守作業では、共有ライブラリまたはパッケージの新しいバージョンをデプロイしてから、共有ライブラリの新しいバージョンを使用するために参照側アプリケーションを再デプロイする必要があります。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションの開発』の「共有 Java EE ライブラリのマニフェスト属性の編集」を参照してください。
共有 Java EE ライブラリは、WebLogic Server コンテナにライブラリとして登録されている、標準の Java EE モジュールまたはエンタープライズ アプリケーションです。Java EE ライブラリを WebLogic Server コンテナに登録するには、次の手順を実行します。
操作するデプロイメント ファイルが有効な Java EE ライブラリまたはオプション パッケージであることを確認します。『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションの開発』の「共有 Java EE ライブラリおよびオプション パッケージの作成」を参照してください。
ライブラリまたはパッケージを登録する WebLogic Server 対象を選択します。共有ライブラリは、参照側アプリケーションをデプロイするのと同じ WebLogic Server インスタンスに登録する必要があります (後で必要に応じて参照側アプリケーションをデプロイできるように、ドメイン内のすべてのサーバにライブラリをデプロイしてもかまいません)。
ライブラリまたはパッケージを登録します。それには、選択した対象サーバにファイルをデプロイし、-library
オプションで、そのデプロイメントをライブラリまたはパッケージとして指定します。次に例を示します。
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -deploy -targets myserver1,myserver2
-library /deployments/myLibraryApplication/
ベスト プラクティスとして、開発チームでは常に、ライブラリまたはオプション パッケージのバージョン文字列情報を、デプロイメントのマニフェスト ファイルに含めるようにしてください。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションの開発』の「共有 Java EE ライブラリのマニフェスト属性の編集」を参照してください。
バージョン文字列情報を含まないライブラリまたはパッケージをデプロイする場合は、以下のいずれかまたは両方のオプションを使用して、コマンドラインで指定することができます。
libspecver
- ライブラリまたはパッケージの仕様のバージョンを定義します。
libimplver
- ライブラリまたはパッケージの実装のバージョンを指定します。
次に例を示します。
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/
注意 : マニフェスト ファイルと weblogic.Deployer コマンドラインの両方でバージョン情報を指定して、両者の値が一致していない場合、デプロイメントは失敗します。最初に仕様または実装のバージョンを指定しないでライブラリを登録した場合は、新しいバージョンを登録してバージョン文字列情報を指定する前に、ライブラリをアンデプロイする必要があります。 ライブラリまたはパッケージの複数のバージョンを登録できますが、各バージョンで同じバージョン文字列を使用する必要があります。たとえば、仕様のバージョンのみを持つライブラリを登録してから、仕様と実装の両方のバージョンを持つそのライブラリの新しいバージョンを登録することはできません。 |
必要なバージョンのライブラリおよびパッケージをデプロイしたら、そのライブラリを参照するエンタープライズ アプリケーションやモジュールをデプロイできます。参照側アプリケーションを正常にデプロイするには、次の 2 つの条件を満たす必要があります。
参照されるすべてのライブラリがアプリケーションの対象サーバに登録されている。
登録されたライブラリは参照側アプリケーションのバージョン要件を満たしている。
参照側アプリケーションをデプロイする特別な構文はありません。標準のエンタープライズ アプリケーションまたは Java EE モジュールの場合と同じようにアプリケーションをデプロイします。
注意 : 参照側アプリケーションは、共有ライブラリのさまざまなレベルのバージョン要件を指定してコンフィグレーションできます。 |
アプリケーションのコンフィグレーションでは以下のいずれかが必要です。
共有ライブラリまたはパッケージの最新バージョン (最新の登録済みバージョン)
ライブラリまたはパッケージの最小のバージョン (または最高のバージョン)
ライブラリまたはパッケージの厳密なバージョン
バージョン要件が原因で参照側アプリケーションをデプロイできない場合は、衝突しているライブラリまたはパッケージの必要なバージョンを登録してみてください。または、開発チームに相談して、アプリケーションのバージョン要件を緩和できるかどうかを判断してください。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションの開発』の「エンタープライズ アプリケーションでの共有 Java EE ライブラリの参照」を参照してください。
注意 : Web アプリケーション コンポーネントを含む EAR ライブラリがある場合は、コンテキスト パスの衝突が起きるため、ライブラリを参照する複数のアプリケーションをデプロイすることはできません。これは、EAR ライブラリ内の個々の Web アプリケーションに対して context-root を設定できないからです。context-root はライブラリ全体に対してのみ設定できます。 |
詳細については、『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションの開発』の「共有 Java EE ライブラリおよびオプション パッケージの概要」を参照してください。
アプリケーションをデプロイするときには、以下のベスト プラクティスをお勧めします。
複数サーバ ドメインの管理サーバは、管理の目的にのみ使用するようにしてください。複数サーバ ドメインの管理サーバにデプロイすることはできますが、開発中以外はお勧めしません。
デプロイメント ファイルを異なる複数のユーザまたは環境に配布するときには、そのファイルをアーカイブ形式 (.ear
、.jar
、.war
など) にパッケージ化します。
デプロイする前に、「デプロイするファイルのパッケージ化」で説明されているシナリオを確認してください。たいていの場合は、アーカイブ形式よりも展開形式の方がアプリケーションのデプロイメントには便利です。
Administration Console、weblogic.Deployer
ツール、wldeploy
Ant タスク、および WLST はすべて、アプリケーションをデプロイするための同様の機能を提供します。
Administration Console は、デプロイメント ファイルの正確な位置、対象サーバ、またはデプロイされるアプリケーションの正確な名前などが不明な場合に、対話形式でデプロイメント セッションを行うために使用します。
weblogic.Deployer
は、デプロイメント コマンドを既存の管理シェル スクリプトまたは自動化されたバッチ プロセスと統合するために使用します。
wldeploy
は、新しいアプリケーションを開発してデプロイするために分割開発ディレクトリと一緒に使用します。wldeploy
は、シェル スクリプトではなく Ant を使用する管理環境で weblogic.Deployer
の代わりとして使用することもできます。
デプロイメント タスクを実行する自動化スクリプトを作成する場合は、WLST を使用します。
開発時に独自のアプリケーションをデプロイするには、autodeploy
ディレクトリではなく wldeploy
を使用します。autodeploy
ディレクトリは、テスト環境または一時的な環境で新しいアプリケーションを素早く実行するのに最適です。たとえばサンプル アプリケーションをダウンロードしてその機能を評価する場合は、autodeploy
ディレクトリを使用すると、アプリケーションを開発サーバに素早くデプロイできます。