Oracle® Fusion Middleware Oracle WebLogic Server 12.1.3へのアプリケーションのデプロイ 12c (12.1.3) E56252-03 |
|
![]() 前 |
![]() 次 |
この章では、weblogic.Deployer
ユーティリティを使用して、WebLogic Server 12.1.3の管理者がコマンド行ベースの対話的なデプロイメント・タスクを実行する方法について説明します。
この章には次の項が含まれます:
以下の節では、一般的なデプロイメント・タスクをいくつかの一般的なカテゴリにまとめています。最も基本的なタスクから始まり、より高度なタスクへと進みます。アプリケーションをデプロイする前に、「本番デプロイメントのためのアプリケーションの構成」で説明されている適切なタスクを実行します。
「リモート・クライアントからのデプロイメント・ファイルのアップロード」 - アプリケーションまたはモジュールをリモート・クライアントから管理サーバーにアップロードする方法について説明します。
「単一サーバー・ドメインへのデプロイ」 - アプリケーションまたはモジュールを単一サーバー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 -username weblogic
-password weblogic -deploy -upload c:\localfiles\myapp.ear
展開されたアーカイブ・ディレクトリをアップロードするには、アーカイブ・ファイル名のかわりにディレクトリ名を指定します(たとえば、c:\localfiles\myappEar
)。
管理サーバー・マシンにファイルをアップロードすると、アーカイブ・ファイルはサーバーのアップロード・ディレクトリに自動的に配置されます。このディレクトリのパスは、「サーバーのデフォルト・ステージング動作の変更」にある手順にしたがって構成できます。
ローカルとリモート(アップロード)のデプロイメント操作を混在させる場合は、アプリケーションのデプロイの過程を追跡するプロセスを用いることが重要です。以下のような一連のイベントを検討してください。
管理者または開発者は、次の情報を使用して、管理対象サーバーを持つ管理サーバーに、デプロイメント・プラン(productionEnvPlan.xml
)を含めたアプリケーション(myapp.ear
)をデプロイした場合。
java weblogic.Deployer -adminurl http://test:7001 -username 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 -username 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 -username weblogic
-password weblogic -deploy c:\localfiles\myapp.ear
「デフォルト・デプロイメント名の理解」
で説明されているように、上記のコマンドでWebLogic Serverは、myappというデフォルト・デプロイメント名を作成します。myapp
はデプロイメント・ファイルの名前から拡張子を除いたものです。デフォルト以外のデプロイメント名を指定する場合は、次のように-name
オプションを使用します。
java weblogic.Deployer -adminurl http://localhost:7001
-username 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 -username 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 -username 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ルックアップは失敗します。たとえば、WebLogic Server管理コンソールで編集ロックを取得し、新しいJDBCシステム・リソースを作成して、同じ編集セッション中に(つまり、WebLogic Server管理コンソールで変更をアクティブ化する前に)、そのJDBCシステム・リソースを使用するアプリケーションをデプロイする場合、システム・リソースがアクティブになる前にpreStartアプリケーション・ライフサイクル・リスナーが呼び出されるため、JDBCシステム・リソースのJNDIルックアップは失敗します。preStartライフサイクル・リスナーでJNDIからシステム・リソースをルックアップするには、起動時または別の編集セッションでシステム・リソースを作成してから、システム・リソースを使用するアプリケーションをデプロイすることをお薦めします。例:
WebLogic Server管理コンソールで「ロックして編集」をクリックして、編集ロックを取得します。
必要なシステム・リソースを作成します。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSシステム・モジュールの作成に関する項を参照してください。
WebLogic Server管理コンソールで「変更のアクティブ化」をクリックして、編集セッションを完了します。
WebLogic Server管理コンソールで「ロックして編集」をクリックして、別の編集ロックを取得します。
ステップ2で作成したシステム・リソースを使用するアプリケーションをデプロイします。WebLogic Server管理コンソールからアプリケーションをデプロイする方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのアプリケーションおよびモジュールのデプロイに関する項を参照してください。
詳細は、『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 WebLogic Serverサーバー環境の管理』の仮想ホスティングの構成に関する項を参照してください。 |
Webアプリケーション |
JMSサーバー |
WebLogic Serverドメインで構成されているJMSサーバー。 |
JMSモジュール内に定義されているJMSキューまたはトピック* *スタンドアロン・アプリケーション・モジュールとしてデプロイされた場合、JMS、JDBCまたはWLDFリソースは、WebLogic Server管理コンソールではJava EEデプロイメントとして表示されます。 スタンドアロンのJMSアプリケーション・モジュールは、サーバー、クラスタ、または仮想ホストのターゲットに割り当てることができます。JMSモジュール内で定義されているキューおよびトピックは、さらに、構成済JMSサーバーに割り当てることができます。サブモジュールのターゲット指定の詳細については、「JMSアプリケーション・モジュールにおけるサブモジュールのターゲット指定の使用」を参照。 |
1つのWebLogic Serverターゲットにデプロイするには、weblogic.Deployer
の-targets
オプションの後に、構成済みのターゲット名を指定します。たとえば、companyHost
という名前の構成済み仮想ホストにWebアプリケーションをデプロイするには、次のコマンドを使用します。
java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
-password weblogic -deploy -targets companyHost c:\localfiles\myWebApp.ear
複数のターゲットは、カンマ区切りのリストを使用して指定します。
java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
-password weblogic -deploy -targets ManagedServer-1,ManagedServer-2
c:\localfiles\myapp.ear
(-targets
mycluster
を使用して)クラスタ・ターゲットを指定すると、WebLogic Serverはデフォルトでクラスタ内のすべてのサーバー・インスタンスをターゲットに指定します。これは、ほとんどのクラスタにおいて薦められる均質なモジュール・デプロイメントに対応しています。クラスタ内の1つのサーバーのみにモジュールをデプロイする(モジュールをサーバーに「固定」する)場合は、ターゲットとして、クラスタではなく個別のサーバー・インスタンス名を指定します。このタイプのデプロイメントは一般的ではなく、固定されたサービスが必須とされる特別な状況においてのみ行うようにする必要があります。詳細は、『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アーカイブ)を含むことができるため、他のデプロイメント・ユニットとは異なります。WebLogic Server管理コンソールを使用してエンタープライズ・アプリケーションをデプロイする場合は、アーカイブのすべてのモジュールを1つのデプロイメント・ユニットとして一緒に割り当てることも、個々のモジュールを別々のサーバー、クラスタまたは仮想ホストに割り当てることもできます。
モジュール・レベルのターゲット指定を使用して、EAR内にあるモジュールのサブセットのみをデプロイすることもできます。複数のモジュールを1つの配布可能なEARにパッケージ化し、各ドメインに必要なモジュールのみを割り当てることによって、アプリケーションのパッケージ化と配布を簡素化することができます。
エンタープライズ・アプリケーション内の個々のモジュールを割り当てるには、module_name
@target_name
構文を使用します。例:
java weblogic.Deployer -adminurl http://localhost:7001 -username 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 -username weblogic -password weblogic -name mywebapplication -targets /welcome@myserver1 -stage -deploy c:\localfiles\myEnterpriseApp.ear
web-uri
を使用して、Webアプリケーション・モジュールのみをデプロイできます。
java weblogic.Deployer -adminurl http://localhost:7001 -username 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 -username weblogic -password weblogic -name mywebapplication -targets /@myserver1 -stage -deploy c:\localfiles\myEnterpriseApp.ear
各子モジュールは、次の手順を実行すると起動または停止できます。
java weblogic.Deployer -username weblogic -password weblogic -adminurl t3://localhost:7001 -name appName -start -targets moduls1@myserver1 java weblogic.Deployer -username weblogic -password weblogic -adminurl t3://localhost:7001 -name appName -stop -targets moduls1@myserver1
注意: モジュールに依存関係がある場合、本番環境でのモジュールの起動および停止に関する注意を参照してください。 |
スタンドアロンのJDBC、JMS、およびWLDFアプリケーション・モジュールは、スタンドアロンのJava EEモジュールと同様にデプロイできます。スタンドアロンのJDBC、JMS、またはWLDFアプリケーション・モジュールの場合、ターゲットのリストによって、モジュールを利用できるWebLogic Serverドメインが決定されます。アプリケーション・モジュール内で指定したJNDI名はグローバル名としてバインドされ、クライアントから使用可能になります。たとえば、スタンドアロンのJDBCアプリケーション・モジュールを1つのサーバー・ターゲットにデプロイした場合、そのJDBCモジュールで定義されているリソースを必要とするアプリケーションは、同じサーバー・インスタンスにのみデプロイできます。アプリケーション・モジュールを複数のサーバーに割り当てることも、WebLogic Serverクラスタに割り当てて他のサーバーでリソースを使用できるようにすることもできます。
JDBC、JMS、またはWLDFリソースをドメイン内のすべてのサーバーで使用できるようにする必要がある場合は、デプロイ可能なアプリケーション・モジュールではなく、システム・モジュールを作成します。『Oracle WebLogic Server JMSリソースの管理』のJMSシステム・リソースの構成に関する項、『Oracle WebLogic Server JDBCデータ・ソースの管理』のWebLogic JDBCリソースの構成に関する項および『Oracle WebLogic Server診断フレームワークの構成と使用』の診断システム・モジュールの構成に関する項を参照してください。
注意: JMSモジュールをデプロイしても、必ずしもそのモジュールが適切に割り当てられてアクティブになり、JNDI名が使用可能になっているとは限りません。JMSモジュールが適切に割り当てられるまで、JNDI名は使用可能になりません。詳細は、『Oracle WebLogic Server JMSリソースの管理』のJMSリソース構成の理解に関する項を参照してください。 |
JMS、JDBC、およびWLDFアプリケーション・モジュールは、アプリケーション・スコープのリソース・モジュールとして、エンタープライズ・アプリケーションに含まれる場合もあります。必要に応じて、デプロイメント時にモジュール・レベルのターゲット指定構文を使用して、アプリケーション・スコープのリソース・モジュールを、他のEARモジュールとは別に割り当てることができます。例:
java weblogic.Deployer -adminurl http://localhost:7001 -username 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
オプションを指定する必要があります。
『Oracle WebLogic Server JMSリソースの管理』のJMSモジュールとリソースのサブデプロイメントのターゲット指定に関する項で説明されているように、WebLogic Server管理コンソールからデプロイするときに、WebLogic Serverは、JMSアプリケーション・モジュール内のサブモジュール用に、デフォルトのJMSサーバー・ターゲットを選択します。
WLSTを使用してサブモジュールをデプロイするときには、以下のすべての条件が満たされる場合に、親モジュールのターゲットをJMSリソースのデフォルトのターゲットとして使用できます。
アプリケーションに1つまたは複数のJMSモジュールが含まれています。
モジュール・ターゲットに関連付けられたJMSサーバー・インスタンスが1つのみ存在します。
-submoduletargets
オプションが指定されていません。
defaultSubmoduleTargetsオプションがtrueです。
『WebLogic Scripting Tool』のデプロイメント・コマンドに関する項を参照してください。
スタンドアロンのJMSモジュールの場合、サブモジュールのターゲット指定の構文は-submoduletargets
submodule_name
@
target_name
になります。たとえば、1つのサーバー・インスタンスにスタンドアロンのJMSモジュールをデプロイする場合、JMSServer1というJMSサーバーにサブモジュールmyQueue
を割り当てるには、次のコマンドを入力します。
java weblogic.Deployer -adminurl http://localhost:7001 -username 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 -username weblogic
-password weblogic -name myJMSModule
-undeploy -submoduletargets myQueue@JMSServer1
EAR内のアプリケーション・スコープのJMSモジュールの場合は、submodule_name
@
module_name
@
target_name
という構文を使用して、サブモジュールを割り当てます。たとえば、上記の例のキューがエンタープライズ・アプリケーションの一部としてパッケージ化されている場合は、次のコマンドを使用します。
java weblogic.Deployer -adminurl http://localhost:7001 -username 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 -username weblogic
-password weblogic -name myEnterpriseApp
-undeploy -submoduletargets myQueue@myJMSModule@JMSServer1
警告: アプリケーション・スコープのリソースを含むアプリケーションをアンデプロイすると、そのリソースはアプリケーションと一緒に削除されます。そのため、JMS宛先の削除が原因で、トランザクションが破棄されたり、メッセージが失われたりする可能性があります。詳細は、『Oracle WebLogic Server JTAアプリケーションの開発』のリソース登録解除の猶予期間に関する項を参照してください。完全に削除するアプリケーションのみをアンデプロイするようにしてください。アプリケーションへのクライアント・アクセスを一時的に停止するには、 |
JMSサブデプロイメントの詳細は、『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のデプロイメント・ツールは適切なモードを使用します。たとえば、weblogic.DeployerまたはWLSTを使用してWebLogic Serverでアプリケーションをデプロイするとき、stageモードを指定しない場合、デフォルトのstageモードが使用されます。管理サーバーでは、デフォルトのstageモードはnostageで、管理対象サーバーではstageです。
以下の節では、アプリケーションまたはモジュールをデプロイするときに、デプロイメントのステージング・モードを明示的に設定する方法について説明します。
nostageモードでは、管理サーバーはアーカイブ・ファイルをソース位置からコピーしません。かわりに、各ターゲット・サーバーは、デプロイメント用の単一のソース・ディレクトリにあるアーカイブ・ファイルにアクセスする必要があります。nostageデプロイメントでは、ターゲット・サーバーのステージング・ディレクトリは無視されます。
たとえば、Java EEアプリケーションをクラスタ内の3つのサーバーにデプロイする場合、アプリケーションをデプロイするには各サーバーが(共有またはネットワーク・マウント・ディレクトリの)同じアプリケーション・アーカイブ・ファイルにアクセスできる必要があります。
注意: nostageモードでは、デプロイメント・ファイルのソースは、デプロイ時にユーザーが指定するパスです(これに対し、stageモードでは各サーバーのステージング・ディレクトリのパスがソースになります)。ただし、WebLogic Serverは、nostageモードの場合でもデプロイメント・ファイルの一部を一時ディレクトリにコピーします。このため、ユーザーがアーカイブ形式デプロイメントの全体または一部を更新することが可能です。 |
nostageモードでは、Webアプリケーション・コンテナがJSPおよびサーブレットに対する変更を自動的に検出します。また、アプリケーションの一部のみを後から更新することもできます。そのためには、該当する部分をファイル・システムの1つの位置で更新し、再デプロイします。
WebLogic Server管理コンソールでは、管理サーバーのみにデプロイする場合(単一サーバー・ドメインの場合など)のデフォルト・モードとしてnostageモードが使用されます。weblogic.Deployer
では対象サーバーのステージング・モードを使用し、管理サーバーではnostageモードをデフォルトで使用します。同じマシンでサーバー・インスタンスのクラスタを実行する場合、または共有ディレクトリにアクセスできる複数のマシンに非常に大きいアプリケーションをデプロイする場合も、nostageモードを選択できます。非常に大きいアプリケーションをnostageモードでデプロイすると、ファイルがコピーされないため、デプロイ時間を短縮できます。
nostageモードを使用するには、weblogic.Deployer
のオプションとして-nostage
を指定します。
java weblogic.Deployer -adminurl http://localhost:7001 -username 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 -username weblogic
-password weblogic -name mytestear -stage -targets mycluster
-deploy c:\Oracle\Middleware\wlserver_12.1\samples\server\medrecd\dist\physicianEar
mycluster
の各サーバーのステージング・ディレクトリに新しいディレクトリmytestear
が作成されます。デプロイメント名を指定しないと、次のようにデフォルトのデプロイメント名(およびステージング・サブディレクトリ)が使用されます。
展開されたアーカイブ・デプロイメントの場合、デプロイメント名およびステージング・サブディレクトリはデプロイするディレクトリの名前になります(上の例ではphysicianEar
)。
アーカイブされたデプロイメントの場合、デフォルトのデプロイメント名はアーカイブ・ファイルの名前から拡張子を除いた名前になります(たとえば、physicianEar.ear
をデプロイする場合のデプロイメント名とステージング・サブディレクトリはphysicianEar
)。
WebLogic Server管理コンソールでは、複数のWebLogic Serverインスタンスにデプロイする場合のデフォルト・モードとして、stageモードを使用します。weblogic.Deployer
ではデフォルトとしてターゲット・サーバーのステージング・モードを使用し、管理対象サーバーではデフォルトでstageモードを使用します。
stageモードでは、ネットワーク停止により管理サーバーがアクセス不能になった場合でも、各サーバーがデプロイメント・ファイルのローカル・コピーを持つことが保証されます。ただし、非常に大きいアプリケーションを複数のサーバー、またはクラスタにデプロイする場合は、ターゲット・サーバーへのファイルのコピーに要する時間がかなり長くなることがあります。大きいファイルを複数のサーバーにコピーすることによるオーバーヘッドを防ぐには、nostageモードを検討してください。
stageモードを使用するには、weblogic.Deployer
のオプションとして-stage
を指定します。
java weblogic.Deployer -adminurl http://localhost:7001 -username 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
というサブディレクトリを作成します。
本番再デプロイメントで使用するためにバージョン管理されたアプリケーションをデプロイする場合は、デプロイするアプリケーションのバージョンに対応するサブディレクトリを、アプリケーション・ディレクトリの下に作成します。たとえば、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
を使用してアプリケーションまたはスタンドアロン・モジュールをデプロイするときにステージング・モードを指定しなかった場合、サーバーのステージング・モードが使用されます。デフォルトのステージング・モードは、管理サーバーではnostageで、管理対象サーバーではstageです。
注意: サーバーのステージング・モードは、WebLogic Server管理コンソールを使用するか、JMXを通じてServerMBeanを直接変更することによってのみ、変更できます。サーバーのステージング・モードを変更しても、既存のアプリケーションには影響しません。既存のアプリケーションのステージング・モードを変更するには、アプリケーション・デプロイメントをアンデプロイしてから、新しいステージング・モードで再デプロイする必要があります。 |
WebLogic Server管理コンソールを使用してサーバーのステージング・モードを設定するには、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのサーバーのステージング・モードの設定に関する項の手順に従ってください。ステージング・モードの詳細は、表6-2を参照してください。
アプリケーション・アーカイブとは別に、アプリケーションのデプロイメント・プランをステージングできます。これにより、アプリケーションがステージングされていない場合にデプロイメント・プランのステージングが可能になります。WebLogic Serverでは、weblogic.Deployer
を使用したデプロイメント・プランのステージングには次の3つのオプションがあります。
-planstage
: デプロイメント・プランをターゲット・サーバーのステージング・ディレクトリにコピーします。
-plannostage
: デプロイメント・プランをターゲット・サーバーにコピーせず、所定の場所に配置します。
-planexternal_stage
: デプロイメント・プランをターゲット・サーバーにコピーしません。かわりに、デプロイメント・プランがターゲット・サーバーのステージング・ディレクトリの正しいサブディレクトリにコピーされたことを確認する必要があります。デプロイメント・プランを手動でコピーしたり、サード・パーティのツールやスクリプトを使用することができます。
ステージング・モードが指定されていない場合は、デフォルトとしてアプリケーションのステージングに指定された値がデプロイメント・プランに使用されます。
たとえば、デプロイメント・プランのステージングが指定されていない場合、およびアプリケーションのステージングがstage
に設定されている場合は、デプロイメント・プランのステージング・モードはplanstage
に設定されます。
デプロイメント・プランのステージングおよびアプリケーションのステージングの両方が指定されていない場合は、デフォルトのアプリケーションのステージング・モードとしてサーバー設定が使用されます。たとえば、サーバー設定がステージングしないである場合、デプロイメント・プランのステージング・モードはplannostage
に設定されます。この場合に、デプロイメント・プランのステージングが必要な場合は、指定する必要があります。
アプリケーションの分散とは、デプロイメント・ファイルをすべてのターゲット・サーバーにコピーして検証し、アプリケーションをデプロイメントの準備が整った状態にすることです。アプリケーションを分散したら、そのアプリケーションを管理モードで起動できます。管理モードでは、アプリケーションに対するアクセスが構成済の管理チャネルに制限されるので、外部のクライアント接続にアプリケーションを公開せずに、アプリケーションを本番環境に分散(またはアプリケーションの新しいバージョンを分散)できます。
管理モードの間は、構成済の管理チャネル経由でのみアプリケーションに接続できます。したがって、アプリケーションの最終(状態)チェックを、クライアントを中断させることなく本番環境で直接実行できます。最終テストを行ったら、アプリケーションをアンデプロイしてさらに変更を加えることも、アプリケーションを起動して一般のクライアントから利用できるようにすることもできます。
-adminmode
オプションを使用すると、アプリケーションを管理モードで起動できます。詳細は、「配布されたアプリケーションの管理モードでの起動」を参照してください。
WebLogicドメインを超えてデポロイする場合、CrossDomainConnector
ロールにより、外部のドメインからドメイン間の呼び出しを実行することができます。すべてのセキュリティ・ロールの完全なリストは、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のデフォルトのグローバル・ロールに関する項を参照してください。
アプリケーションを配布するには、次の示すようにweblogic.Deployer
-distribute
コマンドを使用します。
java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
-password weblogic -distribute -name myTestDeployment
/myDeployments/myApplication/
WebLogic Serverがデプロイメント・ファイルを配布したら、アプリケーションを管理モードで起動して、構成済の管理チャネル経由でアプリケーションへのアクセスやテストを行えるようにします。管理チャネルを構成する方法は、『Oracle WebLogic Serverサーバー環境の管理』のネットワーク・リソースの構成に関する項を参照してください。
配布されたアプリケーションを管理モードで起動するには、-adminmode
オプションを指定して-start
コマンドを使用します。
java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
-password weblogic -start -adminmode -name myTestDeployment
/myDeployments/myApplication/
構成済の管理チャネルを使用して配布されたアプリケーションの最終テストを行ったら、-adminmode
オプションを指定せずにweblogic.Deployer -start
コマンドを使用して、アプリケーションを新しいクライアント接続にオープンできます。
java weblogic.Deployer -adminurl http://localhost:7001 -username 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 WebLogic Serverアプリケーションの開発』の共有ライブラリのマニフェスト属性の編集に関する項を参照してください。
共有Java EEライブラリは、WebLogic Serverコンテナにライブラリとして登録されている、標準のJava EEモジュールまたはエンタープライズ・アプリケーションです。Java EEライブラリをWebLogic Serverコンテナに登録するには、次の手順を実行します。
操作するデプロイメント・ファイルが有効なJava EEライブラリまたはオプション・パッケージであることを確認します。『Oracle WebLogic Serverアプリケーションの開発』の共有Java EEライブラリの作成に関する項を参照してください。
ライブラリまたはパッケージを登録するWebLogic Serverターゲットを選択します。共有ライブラリは、参照側アプリケーションをデプロイするのと同じWebLogic Serverインスタンスに登録する必要があります。(後で必要に応じて参照側アプリケーションをデプロイできるように、ドメイン内のすべてのサーバーにライブラリをデプロイしてもかまいません。)
ライブラリまたはパッケージを登録します。それには、選択した対象サーバーにファイルをデプロイし、-library
オプションで、そのデプロイメントをライブラリまたはパッケージとして指定します。例:
java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
-password weblogic -deploy -targets myserver1,myserver2
-library /deployments/myLibraryApplication/
ベスト・プラクティスとして、開発チームでは常に、ライブラリまたはオプション・パッケージのバージョン文字列情報を、デプロイメントのマニフェスト・ファイルに含めるようにしてください。詳細は、『Oracle WebLogic Serverアプリケーションの開発』の共有ライブラリのマニフェスト属性の編集に関する項を参照してください。
バージョン文字列情報を含まないライブラリまたはパッケージをデプロイする場合は、以下のいずれかまたは両方のオプションを使用して、コマンド行で指定することができます。
libspecver
- ライブラリまたはパッケージの仕様のバージョンを定義します。
libimplver
- ライブラリまたはパッケージの実装のバージョンを指定します。
例:
java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
-password weblogic -deploy -targets myserver1,myserver2
-library -libspecver 700 -libimplversion 7.0.0.1Beta
/deployments/myLibraryApplication/
注意: マニフェスト・ファイルとweblogic.Deployerコマンド行の両方でバージョン情報を指定して、両者の値が一致していない場合、デプロイメントは失敗します。最初に仕様または実装のバージョンを指定しないでライブラリを登録した場合は、新しいバージョンを登録してバージョン文字列情報を指定する前に、ライブラリをアンデプロイする必要があります。 ライブラリまたはパッケージの複数のバージョンを登録できますが、各バージョンで同じバージョン文字列を使用する必要があります。たとえば、仕様のバージョンのみを持つライブラリを登録してから、仕様と実装の両方のバージョンを持つそのライブラリの新しいバージョンを登録することはできません。 |
必要なバージョンのライブラリおよびパッケージをデプロイしたら、そのライブラリを参照するエンタープライズ・アプリケーションやモジュールをデプロイできます。参照側アプリケーションを正常にデプロイするには、次の2つの条件を満たす必要があります。
参照されるすべてのライブラリがアプリケーションのターゲット・サーバーに登録されています。
登録されたライブラリは参照側アプリケーションのバージョン要件を満たしています。
参照側アプリケーションをデプロイする特別な構文はありません。標準のエンタープライズ・アプリケーションまたはJava EEモジュールの場合と同様にアプリケーションをデプロイします。
注意: 参照側アプリケーションは、共有ライブラリの様々なレベルのバージョン要件を指定して構成できます。 |
アプリケーションの構成では以下のいずれかが必要です。
共有ライブラリまたはパッケージの最新バージョン(最新の登録済みバージョン)
ライブラリまたはパッケージの最小のバージョン(または最高のバージョン)
ライブラリまたはパッケージの厳密なバージョン
バージョン要件が原因で参照側アプリケーションをデプロイできない場合は、競合しているライブラリまたはパッケージの必要なバージョンを登録してみてください。または、開発チームに相談して、アプリケーションのバージョン要件を緩和できるかどうかを判断してください。詳細は、『Oracle WebLogic Serverアプリケーションの開発』のエンタープライズ・アプリケーション内のライブラリ参照に関する項を参照してください。
注意: Webアプリケーション・コンポーネントを含むEARライブラリがある場合は、コンテキスト・パスの競合が起きるため、ライブラリを参照する複数のアプリケーションをデプロイすることはできません。これは、EARライブラリ内の個々のWebアプリケーションに対してcontext-rootを設定できないからです。context-rootはライブラリ全体に対してのみ設定できます。 |
詳細は、『Oracle WebLogic Serverアプリケーションの開発』のJava EEライブラリおよびオプション・パッケージの概要に関する項を参照してください。
アプリケーションをデプロイするときには、以下のベスト・プラクティスをお薦めします。
複数サーバー・ドメインの管理サーバーは、管理の目的にのみ使用するようにしてください。複数サーバー・ドメインの管理サーバーにデプロイすることはできますが、開発中以外はお薦めしません。
デプロイメント・ファイルを異なる複数のユーザーまたは環境に配布するときには、そのファイルをアーカイブ形式(.ear
、.jar
、.war
など)にパッケージ化します。
デプロイする前に、「デプロイするファイルのパッケージ化」で説明されているシナリオを確認してください。たいていの場合は、アーカイブ形式よりも展開形式の方がアプリケーションのデプロイメントには便利です。
WebLogic Server管理コンソール、weblogic.Deployer
ツール、wldeploy
AntタスクおよびWLSTはすべて、アプリケーションをデプロイするための同様の機能を提供します。
WebLogic Server管理コンソールは、デプロイメント・ファイルの正確な位置や、ターゲット・サーバーまたはデプロイされるアプリケーションの正確な名前などが不明な場合に、対話形式でデプロイメント・セッションを行うために使用します。
weblogic.Deployer
は、デプロイメント・コマンドを既存の管理シェル・スクリプトまたは自動化されたバッチ・プロセスと統合するために使用します。
wldeploy
は、新しいアプリケーションを開発してデプロイするために分割開発ディレクトリと一緒に使用します。wldeploy
は、シェル・スクリプトではなくAntを使用する管理環境でweblogic.Deployer
の代わりとして使用することもできます。
デプロイメント・タスクを実行する自動化スクリプトを作成する場合は、WLSTを使用します。
開発時に独自のアプリケーションをデプロイするには、autodeploy
ディレクトリではなくwldeploy
を使用します。autodeploy
ディレクトリは、テスト環境または一時的な環境で新しいアプリケーションを素早く実行するのに最適です。たとえばサンプル・アプリケーションをダウンロードしてその機能を評価する場合は、autodeploy
ディレクトリを使用すると、アプリケーションを開発サーバーに素早くデプロイできます。