WebLogic Server 9.0 アプリケーションのデプロイメント
![]() |
![]() |
![]() |
![]() |
以下の節では、weblogic.Deployer
ユーティリティを使用して、基本的および高度なデプロイメント タスクを実行する方法について説明します。
以下の節では、一般的なデプロイメント タスクをいくつかの一般的なカテゴリにまとめています。最も基本的なタスクから始まり、より高度なタスクへと進みます。アプリケーションをデプロイする前に、「プロダクション デプロイメントのためのアプリケーションのコンフィグレーション」で説明されている適切なタスクを実行します。
ドメインにアプリケーションまたはモジュールをデプロイするには、デプロイメント ファイルがドメインの管理サーバからアクセス可能でなければなりません。デプロイメント ファイルが管理サーバ マシン上にない場合、またはネットワークにマウントされたディレクトリを通じて管理サーバ マシンから使用できない場合は、-upload
オプションを使用して、デプロイする前にファイルをアップロードします。
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -deploy -upload c:\localfiles\myapp.ear
展開されたアーカイブ ディレクトリをアップロードするには、アーカイブ ファイル名の代わりにディレクトリ名を指定します (たとえば、c:\localfiles\myappEar
)。
管理サーバ マシンにファイルをアップロードすると、アーカイブ ファイルはサーバのアップロード ディレクトリに自動的に配置されます。このディレクトリのパスは、「サーバのデフォルト ステージング動作の変更」にある手順に従ってコンフィグレーションできます。
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 からシステム リソースをルックアップするには、起動時または別の編集セッションでシステム リソースを作成してから、システム リソースを使用するアプリケーションをデプロイすることをお勧めします。たとえば、次のようにします。
手順 2 で作成したシステム リソースを使用するアプリケーションをデプロイします。Administration Console からアプリケーションをデプロイする方法については、Administration Console オンライン ヘルプの「アプリケーションおよびモジュールのデプロイ」を参照してください。
詳細については、『WebLogic Server アプリケーションの開発』の「Overview of Shared J2EE Libraries and Optional Packages」を参照してください。
ほとんどのプロダクション環境では、通常、WebLogic Server ドメインにコンフィグレーションされている 1 つまたは複数の管理対象サーバにアプリケーションをデプロイします。場合によっては、サーバが WebLogic Server クラスタに含まれていたり、仮想ホストが Web アプリケーションの要求の転送に使用されていることがあります。「デプロイメント対象」とは、アプリケーションまたはモジュールをデプロイできるサーバまたはサーバの集合のことです。
デプロイメント対象とは、アプリケーションまたはスタンドアロン モジュールをデプロイするサーバまたはサーバのグループです。デプロイメント プロセス中に、ドメインにコンフィグレーションされている使用可能な対象から対象のリストを選択します。モジュールをデプロイした後で対象のリストを変更することもできます。
次の表では、WebLogic Server のすべての有効なデプロイメント対象について説明し、各対象にデプロイできるモジュールの種類を示します。
表 5-1 WebLogic Server 9.0 のデプロイメント対象
|
||
|
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 クラスタ ユーザーズ ガイド』の「クラスタのコンフィグレーションとアプリケーションのデプロイメント」を参照してください。
注意 : クラスタ内の (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 アプリケーションのコンテキスト ルート名をモジュール名として使用します。たとえば、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
スタンドアロンの JDBC、JMS、および WLDF アプリケーション モジュールは、スタンドアロンの J2EE モジュールと同じようにデプロイできます。スタンドアロンの JDBC、JMS、または WLDF アプリケーション モジュールの場合、対象のリストによって、モジュールを利用できる WebLogic Server ドメインが決まります。アプリケーション モジュール内で指定された JNDI 名はグローバル名としてバインドされ、クライアントから使用可能になります。たとえば、スタンドアロンの JDBC アプリケーション モジュールを 1 つのサーバ対象にデプロイした場合、その JDBC モジュールで定義されているリソースを必要とするアプリケーションは、同じサーバ インスタンスにのみデプロイできます。アプリケーション モジュールを複数のサーバに割り当てることも、WebLogic Server クラスタに割り当てて他のサーバでリソースを使用できるようにすることもできます。
JDBC、JMS、または WLDF リソースをドメイン内のすべてのサーバで使用できるようにする必要がある場合は、デプロイ可能なアプリケーション モジュールではなく、システム モジュールを作成します。詳細については、『WebLogic JMS プログラマーズ ガイド』、『WebLogic JDBC プログラマーズ ガイド』、『WebLogic 診断フレームワークのコンフィグレーションと使い方』を参照してください。
注意 : JMS モジュールをデプロイしても、必ずしもそのモジュールが適切に割り当てられてアクティブになり、JNDI 名が使用可能になるわけではありません。JMS モジュールが適切に割り当てられるまで、JNDI 名は使用可能になりません。詳細については、『WebLogic 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 インスタンスやクラスタに割り当てることができます。
『WebLogic JMS プログラマーズ ガイド』で説明されているように、デプロイメント時に、WebLogic Server は、JMS アプリケーション モジュール内のサブモジュール用に、デフォルトの JMS サーバ対象を選択します。デプロイメント時またはアンデプロイメント時にサブモジュールの対象を指定するには、モジュール対象指定の構文を拡張して、weblogic.Deployer
に -submoduletargets
オプションを指定する必要があります。
スタンドアロンの 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 送り先の削除が原因で、トランザクションが破棄されたり、メッセージが失われたりする可能性があります。詳細については、『WebLogic JTA プログラマーズ ガイド』の「Unregister Resource Grace Period」を参照してください。
警告 : 完全に削除するつもりのアプリケーションのみをアンデプロイするようにしてください。アプリケーションへのクライアント アクセスを一時的に停止するには、「weblogic.Deployer コマンドライン リファレンス」で説明するように、-stop コマンドを使用します。
JMS サブデプロイメントの詳細については、『WebLogic JMS のコンフィグレーションと管理』の「JMS モジュールとサブデプロイメント リソースの対象指定」を参照してください。
デプロイメントのステージング モードにより、デプロイメント ファイルを、アプリケーションまたはスタンドアロン モジュールをデプロイする必要がある対象サーバから使用できるようにする方法が決まります。WebLogic Server のステージング モードには、stage モード、nostage モード、external_stage モードの 3 種類があります。次の表では、デプロイメント ステージング モード別にそのモードを使用する場合の動作とベスト プラクティスについて説明します。
表 5-2 アプリケーション デプロイメントのステージング モード
|
||
|
||
|
サーバのステージング ディレクトリは、管理サーバが stage モード デプロイメント用のデプロイメント ファイルをコピーするディレクトリです。また、external_stage モードを使用してアプリケーションをデプロイする前には、このディレクトリにデプロイメント ファイルが配置されている必要があります。
ほとんどのデプロイメントでは、stage モードまたは nostage モードを使用します。アプリケーションまたはモジュールをデプロイするときに、WebLogic Server のデプロイメント ツールは適切なモードを使用します。以下の節では、アプリケーションまたはモジュールをデプロイするときに、デプロイメントのステージング モードを明示的に設定する方法について説明します。
nostage モードでは、管理サーバはアーカイブ ファイルをソース位置からコピーしません。代わりに、各対象サーバは、デプロイメント用の単一のソース ディレクトリにあるアーカイブ ファイルにアクセスする必要があります。nostage デプロイメントでは、対象サーバのステージング ディレクトリは無視されます。
たとえば、J2EE アプリケーションをクラスタ内の 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 つのサーバに J2EE アプリケーションをデプロイする場合、管理サーバは 3 つのサーバ マシンのそれぞれのディレクトリにデプロイメント ファイルをコピーします。各サーバは、アーカイブ ファイルのローカル コピーを使用して J2EE アプリケーションをデプロイします。
ステージング ディレクトリにファイルをコピーするときに、管理サーバはデプロイメント名と同名のサブディレクトリを作成します。そのため、次のコマンドを使用してデプロイした場合、
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -name mytestear -stage -targets mycluster
-deploy c:\bea\weblogic81\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
というステージング ディレクトリに、デプロイメント ファイルを置く必要があります。
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 を使用してサーバのステージング モードを設定するには、Administration Console オンライン ヘルプの「サーバのステージング モードの設定」の手順に従ってください。ステージング モードの詳細については、表 5-2 を参照してください。
アプリケーションの分散とは、デプロイメント ファイルをすべての対象サーバにコピーして検証し、アプリケーションをデプロイメントの準備が整った状態にすることです。アプリケーションを分散したら、そのアプリケーションを管理モードで起動することができます。管理モードでは、アプリケーションに対するアクセスがコンフィグレーション済みの管理チャネルに制限されるので、外部のクライアント接続にアプリケーションを公開せずに、アプリケーションをプロダクション環境に分散 (またはアプリケーションの新しいバージョンを分散) することができます。
管理モードの間は、コンフィグレーション済みの管理チャネル経由でのみアプリケーションに接続できます。したがって、アプリケーションの最終 (状態) チェックを、クライアントを中断させることなくプロダクション環境で直接実行できます。最終テストを行ったら、アプリケーションをアンデプロイしてさらに変更を加えることも、アプリケーションを起動して一般のクライアントから利用できるようにすることもできます。
-adminmode
オプションを使用すると、アプリケーションを管理モードで起動できます。詳細については、「分散されたアプリケーションの管理モードでの起動」を参照してください。
アプリケーションを分散するには、weblogic.Deployer
-distribute コマンドを使用します。
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -distribute -name myTestDeployment
/myDeployments/myApplication/
WebLogic Server がデプロイメント ファイルを分散したら、アプリケーションを管理モードで起動して、コンフィグレーション済みの管理チャネル経由でアプリケーションへのアクセスやテストを行えるようにします。『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 9.0 の J2EE ライブラリのサポートにより、複数のエンタープライズ アプリケーション間で、1 つまたは複数の J2EE モジュールまたは JAR ファイルを簡単に共有できます。J2EE ライブラリは、スタンドアロンの J2EE モジュール、エンタープライズ アプリケーション (EAR) 内にパッケージ化された複数の J2EE モジュール、またはデプロイメント時に J2EE アプリケーション コンテナに登録されるプレーンな JAR ファイルです。J2EE ライブラリが登録されたら、そのライブラリを参照するエンタープライズ アプリケーションをデプロイできます。参照側の各アプリケーションは、デプロイメントの際に共有 J2EE ライブラリ モジュールのコピーを受け取り、アプリケーションそのものの一部としてパッケージ化されているかのように、これらのモジュールを使用できます。
注意 : BEA のドキュメントと WebLogic Server ユーティリティでは、「ライブラリ」という語を J2EE ライブラリとオプション パッケージの両方の意味で使用します。必要な場合にのみオプション パッケージと呼びます。
WebLogic Server 9.0 では、参照側アプリケーションがデプロイされるときに共有ファイルと参照側アプリケーションを結合することによって、共有 J2EE ライブラリをサポートしています。
まず、ライブラリをデプロイして、そのデプロイメントがライブラリであることを示すことによって、1 つまたは複数の WebLogic Server インスタンスまたはクラスタに J2EE ライブラリまたはオプション パッケージを登録します (「WebLogic Server でのライブラリの登録」を参照)。ライブラリまたはパッケージをデプロイしても、そのデプロイメントは対象サーバ上でアクティブにはなりません。代わりに、WebLogic Server はデプロイメント ファイルを対象サーバに分散し (nostage デプロイメント モードが使用されている場合)、デプロイメント ファイルの場所、デプロイメント名、ライブラリまたはパッケージのバージョン文字列情報などを記録します。
共有ライブラリまたはパッケージを参照するアプリケーションがデプロイされると、WebLogic Server は名前とバージョン文字列の要件を、サーバに登録済みのライブラリに照らしてチェックします。ライブラリまたはパッケージ名に完全に一致するものが見つからない場合、またはバージョン要件が満たされない場合、そのアプリケーションのデプロイメントは失敗します。
アプリケーションで参照されているすべてのライブラリと名前およびバージョン文字列が一致するものが見つかったら、WebLogic Server はそのライブラリのクラスを参照側アプリケーションのクラスパスに追加し、メモリ内でアプリケーションとライブラリの両方のデプロイメント記述子を結合します。結果としてデプロイされるアプリケーションは、参照されるライブラリがアプリケーションそのものにバンドルされているかのように見えます。
J2EE ライブラリの内容は、エンタープライズ アプリケーション内の他の J2EE モジュールと同様にクラスローダにロードされます。たとえば、EJB モジュールは参照側アプリケーションのクラスローダの一部としてロードされますが、Web アプリケーション モジュールはアプリケーション クラスローダの下のクラスローダにロードされます。共有 J2EE ライブラリが EAR からなる場合は、その EAR の APP-INF/lib
または APP-INF/classes
サブディレクトリに格納されているクラスも、参照側アプリケーションから使用できるようになります。
現在デプロイされているアプリケーションによって参照されている J2EE ライブラリまたはオプション パッケージをアンデプロイすることはできません。共有ライブラリまたはパッケージをアンデプロイする必要がある場合は、まず、共有ライブラリを使用するすべてのアプリケーションをアンデプロイしてください。通常のアプリケーションの保守作業では、共有ライブラリまたはパッケージの新しいバージョンをデプロイしてから、共有ライブラリの新しいバージョンを使用するために参照側アプリケーションを再デプロイする必要があります。詳細については、『WebLogic Server アプリケーションの開発』の「Editing Manifest Attributes for Shared J2EE Libraries」を参照してください。
共有 J2EE ライブラリは、WebLogic Server コンテナにライブラリとして登録されている、標準の J2EE モジュールまたはエンタープライズ アプリケーションです。J2EE ライブラリを WebLogic Server コンテナに登録するには、次の手順を実行します。
-library
オプションで、そのデプロイメントをライブラリまたはパッケージとして指定します。次に例を示します。
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -deploy -targets myserver1,myserver2
-library /deployments/myLibraryApplication/
ベスト プラクティスとして、開発チームでは常に、ライブラリまたはオプション パッケージのバージョン文字列情報を、デプロイメントのマニフェスト ファイルに含めるようにしてください。バージョン文字列の要件とベスト プラクティスの詳細については、『WebLogic Server アプリケーションの開発』の「Editing Manifest Attributes for Shared Libraries」を参照してください。
バージョン文字列情報を含まないライブラリまたはパッケージをデプロイする場合は、以下のいずれかまたは両方のオプションを使用して、コマンドラインで指定することができます。
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 つの条件を満たす必要があります。
参照側アプリケーションをデプロイする特別な構文はありません。標準のエンタープライズ アプリケーションまたは J2EE モジュールの場合と同じようにアプリケーションをデプロイします。
共有ライブラリのさまざまなレベルのバージョン要件を指定して参照側アプリケーションをコンフィグレーションすることはできません。アプリケーションのコンフィグレーションでは以下のいずれかが必要です。
バージョン要件が原因で参照側アプリケーションをデプロイできない場合は、衝突しているライブラリまたはパッケージの必要なバージョンを登録してみてください。または、開発チームに相談して、アプリケーションのバージョン要件を緩和できるかどうかを判断してください。詳細については、『WebLogic Server アプリケーションの開発』の「Referencing Shared J2EE Libraries in an Enterprise Application」を参照してください。
注意 : Web アプリケーション コンポーネントを含む EAR ライブラリがある場合は、コンテキスト パスの衝突が起きるため、ライブラリを参照する複数のアプリケーションをデプロイすることはできません。これは、EAR ライブラリ内の個々の Web アプリケーションに対して context-root
を設定できないからです。context-root
はライブラリ全体に対してのみ設定できます。
詳細については、『WebLogic Server アプリケーションの開発』の「Overview of Shared J2EE Libraries and Optional Packages」を参照してください。
注意 : 自動デプロイメントは、評価またはテストのために、スタンドアロン サーバ (管理サーバ) にアプリケーションを迅速にデプロイするための手段です。自動デプロイメントは、単一サーバの開発環境でのみ使用してください。自動デプロイメントをプロダクション環境で使用したり、管理対象サーバへのデプロイメントに使用することはお勧めしません。
アプリケーションのデプロイ時には、自動デプロイではなく、WebLogic Server の分割開発ディレクトリおよび wldeploy
Ant タスクを使用することをお勧めします。『WebLogic Server アプリケーションの開発』の「Creating a Split Development Directory Environment」を参照してください。
自動デプロイメントが有効な場合は、アプリケーションが管理サーバの \autodeploy
ディレクトリにコピーされると、その管理サーバは新しいアプリケーションの存在を検出し、それを自動的にデプロイします (管理サーバが動作している場合)。アプリケーションを \autodeploy
ディレクトリにコピーしたときに WebLogic Server が稼働していない場合、そのアプリケーションは WebLogic Server の管理サーバが次に起動したときにデプロイされます。自動デプロイメントは管理サーバに対してのみデプロイします。
注意 : Windows のファイル ロックの制限により、アプリケーションが展開された場合、アプリケーション内のすべてのモジュールも展開されます。つまり、展開するアプリケーションまたはモジュールに JAR ファイルが含まれる場合、自動デプロイメントは使用できません。
自動デプロイメントは、開発環境において単一サーバの対象で使用することを想定されています。Administration Console など、他のツールを使用して自動デプロイ済みの展開されたアプリケーションに対象を追加した場合、アプリケーションを再デプロイしても新しい対象サーバに変更は伝わりません。
WebLogic Server ドメインは、開発環境とプロダクション環境の 2 つの異なるモードで実行できます。
開発モードでは、WebLogic Server インスタンスは domain_name/autodeploy
ディレクトリ (domain_name
は WebLogic Server ドメインの名前) にあるアプリケーションを自動的にデプロイおよび更新できます。つまり、開発モードでは自動デプロイメント機能を使用することになります。プロダクション モードでは自動デプロイメント機能が無効になり、プロダクション モードに切り替えた後で autodeploy
ディレクトリに置いたアプリケーションはデプロイされません。開発モードからプロダクション モードに切り替えた場合、以前に autodeploy
ディレクトリからデプロイされたアプリケーションはデプロイされたままになります。プロダクション モードに切り替えた後でそのようなアプリケーションをアンデプロイまたは再デプロイする場合は、手動でアンデプロイまたは再デプロイする必要があります (たとえば、「weblogic.Deployer コマンドライン リファレンス」で説明するように、weblogic.Deployer
コマンドと -undeploy
または -redeploy
オプションを使用します)。
デフォルトでは、WebLogic Server ドメインは開発モードで稼働します。ドメインのモードを指定するには、『コンフィグレーション ウィザードを使用した WebLogic ドメインの作成』を参照してください。
アーカイブされたアプリケーションを自動デプロイするには、そのアーカイブ ファイルを /autodeploy
ディレクトリにコピーします。WebLogic Server はアプリケーションのデプロイメント モードを自動的に stage モードに設定します。
自動デプロイされたデプロイメント ユニットは、サーバの稼働時に動的に再デプロイできます。動的に再デプロイするには、アーカイブ ファイルの新バージョンを /autodeploy
ディレクトリ内の既存ファイルに上書きコピーします。
自動デプロイ済みのアーカイブされたデプロイメント ユニットをアンデプロイするには、/autodeploy
ディレクトリからアプリケーションを削除します。WebLogic Server は、アプリケーションを停止してコンフィグレーションから削除します。
注意 : サーバがアクティブでないときに /autodeploy
ディレクトリからアプリケーションを削除すると、サーバが再びアクティブな状態になった場合でも、WebLogic Server はアプリケーションが削除されたことを検出しません。ドメイン ツリーの同期を保つために、サーバがアクティブな状態の場合にのみ /autodeploy
ディレクトリからアプリケーションを削除することをお勧めします。
展開されたアーカイブ形式でアプリケーションを自動デプロイするには、展開されたアーカイブ ディレクトリ全体を /autodeploy
ディレクトリにコピーします。WebLogic Server は、nostage デプロイメント モードを使用して、展開されたアーカイブ アプリケーションを自動的にデプロイします。
注意 : Windows のファイル ロックの制限により、展開された EAR ディレクトリをデプロイするとき、そのディレクトリにアーカイブされたモジュール (JAR ファイル) が含まれてる場合、JAR ファイルはデプロイメント中はロックされて、削除できなくなります。したがって、自動デプロイするアプリケーションが展開されている場合は、そこに含まれているモジュールもすべて展開しておく必要があります。
展開されたアーカイブ ディレクトリ全体の内容が /autodeploy
ディレクトリ内にない場合に、アプリケーションを展開されたアーカイブ形式でデプロイしようとすると、自動デプロイメントは失敗します。展開されたアーカイブ形式の大きなアプリケーションを /autodeploy
ディレクトリへコピーするのは時間がかかるため、サーバが非アクティブ状態にあるときに、展開されたアーカイブ ディレクトリを /autodeploy
ディレクトリにコピーすることをお勧めします。展開されたアーカイブ ディレクトリ全体が /autodeploy
ディレクトリにコピーされた後で、サーバをアクティブ状態に戻すと、アプリケーションは自動デプロイされます。または、大きなアプリケーションは weblogic.Deployer
を使用してデプロイすることをお勧めします。「weblogic.Deployer コマンドライン リファレンス」を参照してください。
アプリケーションが展開されたアーカイブ形式で自動デプロイされている場合、管理サーバは、展開されたアプリケーションのディレクトリ内で REDEPLOY
というファイルを定期的に検索します。このファイルのタイムスタンプが変更されている場合、管理サーバは展開ディレクトリを再デプロイします。
展開されたアプリケーション ディレクトリ内のファイルを再デプロイするには、次の手順に従います。
REDEPLOY
という名前の空のファイルを作成し、そのファイルを、デプロイするアプリケーションのタイプに応じて、WEB-INF または META-INF
ディレクトリに配置します。展開されたエンタープライズ アプリケーションには、最上位に META-INF
ディレクトリがあり、このディレクトリに application.xml ファイルがあります。
展開された Web アプリケーションには、最上位に WEB-INF
ディレクトリがあり、このディレクトリに web.xml ファイルがあります。
展開された EJB アプリケーションには、最上位に META-INF
ディレクトリがあり、このディレクトリに ejb-jar.xml ファイルがあります。
展開されたコネクタには、最上位に META-INF
ディレクトリがあり、このディレクトリに ra.xml ファイルがあります。
注意 : REDEPLOY
ファイルは、デプロイされたアプリケーション全体またはスタンドアロン モジュールに対してのみ機能します。展開されたエンタープライズ アプリケーションをデプロイした場合、REDEPLOY
ファイルは、個別のモジュール (Web アプリケーションなど) ではなく、アプリケーション全体の再デプロイを制御します。Web アプリケーション自体を展開されたアーカイブ ディレクトリとしてデプロイする場合、REDEPLOY
ファイルは Web アプリケーション全体の再デプロイメントを制御します。
管理サーバは、タイムスタンプの変更を検出すると、展開ディレクトリのコンテンツを再デプロイします。
注意 : 自動デプロイしたアプリケーションの再デプロイを開始する場合は常に、REDEPLOY
ファイルを touch
する (タイムスタンプを変更する) 必要があります。サーバが停止状態のときにアプリケーションを変更する場合でも、REDEPLOY
ファイルを touch
し、次回のサーバ起動時に変更が確実に適用されるようにする必要があります。
展開形式で自動デプロイしたアプリケーションをアンデプロイするには、weblogic.Deployer
-undeploy
コマンドを使用するか、または Administration Console を使用して、デプロイメントのコンフィグレーションを削除します。次に、/autodeploy
ディレクトリからアプリケーション ファイルを削除します。
注意 : サーバがアクティブでないときに /autodeploy
ディレクトリからアプリケーション ファイルを削除すると、サーバが再びアクティブな状態になった場合でも、WebLogic Server はアプリケーション ファイルが削除されたことを検出しません。ドメイン ツリーの同期を保つために、サーバがアクティブな状態の場合にのみ /autodeploy
ディレクトリからアプリケーション ファイルを削除することをお勧めします。
アプリケーションをデプロイするときには、以下のベスト プラクティスをお勧めします。
.ear
、.jar
、.war
など) にパッケージ化します。weblogic.Deployer
ツール、wldeploy
Ant タスク、および WLST はすべて、アプリケーションをデプロイするための同様の機能を提供します。weblogic.Deployer
は、デプロイメント コマンドを既存の管理シェル スクリプトまたは自動化されたバッチ プロセスと統合するために使用します。wldeploy
は、新しいアプリケーションを開発してデプロイするために分割開発ディレクトリと一緒に使用します。wldeploy
は、シェル スクリプトではなく Ant を使用する管理環境で weblogic.Deployer
の代わりとして使用することもできます。autodeploy
ディレクトリではなく wldeploy
を使用します。autodeploy
ディレクトリは、テスト環境または一時的な環境で新しいアプリケーションを素早く実行するのに最適です。たとえばサンプル アプリケーションをダウンロードしてその機能を評価する場合は、autodeploy
ディレクトリを使用すると、アプリケーションを開発サーバに素早くデプロイできます。
![]() ![]() |
![]() |
![]() |