| Oracle Containers for J2EEデプロイメント・ガイド 10g（10.1.3.5.0） B56032-01 |
|
 戻る |
 次へ |
Oracle Enterprise Manager 10g Application Server Controlでは、特定のOC4Jインスタンスまたはグループ内の全OC4Jインスタンスで同時に一連のデプロイ関連タスクを実行する、Webベースのインタフェースが提供されます。グループは、同じクラスタ・トポロジ（2つ以上の粗結合のOracle Application Serverノード）に属するOC4Jインスタンスの同期セットです。
Application Server Controlでは次のデプロイ操作を実行できます。
アプリケーション（EAR）、スタンドアロンWebモジュール（WAR）、スタンドアロンEJBモジュール（EJB JAR）またはスタンドアロン・リソース・アダプタ（RAR）をデプロイする。
アプリケーション、Webモジュール、EJBモジュールまたはリソース・アダプタをアンデプロイする。
共有ライブラリを作成、変更または削除する。
アプリケーションを起動、再起動または停止する。
OC4Jインスタンスやインスタンス・グループを再起動または停止する。
データソースと接続プールを管理する。
JMSリソースを管理する。
再利用可能なデプロイ・プランを作成または編集する。
アプリケーション固有セキュリティやアプリケーション・クラスタリング構成を設定する。
提供されている様々な機能の使用方法の詳細は、Application Server Controlのオンライン・ヘルプを参照してください。
Antタスクまたはadmin_client.jarコマンドライン・ユーティリティで同様のデプロイ・タスクを実行できます。第10章「デプロイに対するOC4J Antタスクの使用方法」では、デプロイ用のOC4J Antタスクおよびその使用方法を説明します。第11章「デプロイに対するadmin_client.jarユーティリティの使用方法」では、デプロイ・タスクに対するadmin_client.jarの使用方法を説明します。
次の項目について説明します。
Application Server Controlは、OC4Jをインストールすると自動的にインストールされて構成されます。次の項目について説明します。
このインタフェースの使用方法の詳細は、Application Server Controlのオンライン・ヘルプを参照してください。
Application Server Controlは、OC4Jソフトウェアをインストールすると自動的にインストールされて構成されます。デフォルトでは、OC4Jの起動時に起動されます。
Application Server Controlにはdefault Webサイトからアクセスします。このサイトは、ポート8888でHTTPリクエストをリスニングするように構成されています。Application Server Controlにアクセスするには、Webブラウザに次のURLを入力します。
http://hostname:8888/em
Application Server Controlは、Oracle Universal Installerを使用してOC4Jをインストールするときに自動的にインストールされて構成されます。
OPMNコマンドライン・ツールを使用すると、インストールされている他のすべてのOracle Application ServerコンポーネントとともにApplication Server Controlを起動できます。OPMNコマンドライン・ツールopmnctlは、各サーバー・ノードのORACLE_HOME/opmn/binディレクトリにインストールされています。次のコマンドを発行して、インストールされているすべてのコンポーネントを起動します。
cd ORACLE_HOME/opmn/bin
opmnctl startall
|
注意: 複数のOC4Jインスタンスを含むクラスタ・トポロジでは、startallの後に-sequentialフラグを使用して、全インスタンスを並行して起動した場合に起こり得るリソースの競合を防止してください。クラスタ・トポロジ用のOPMN構成ファイル、opmn.xmlでは-sequentialオプションを次のように指定できます。
<ias-component id="default_group">
<process-type id="home" module-id="OC4J" status="enabled">
<module-data>
<category id="start-parameters">
<data id="oc4j-options" value="-sequential"
</category>
...
</module-data>
</process-type>
</ias-component>
|
典型的なOracle Application Serverのインストールでは、Application Server Controlも含むすべてのWebアプリケーションにOracle HTTP Server（OHS）からアクセスします。次のURLを使用してApplication Server Controlにアクセスします。
http://ohs_host_address:port/em
ohs_host_addressは、OHSホスト・マシンのアドレスです。たとえば、server07.company.comと指定します。
portは、OPMNによってOHSに割り当てられたHTTPリスナー・ポートです。OHSホスト・マシンで次のopmnctlコマンドを実行して、OPMNから割り当てられたリスナー・ポートのリストを取得します。
opmnctl status -l
次のように、OPMNステータス出力でhttp1に示されたポートを、portの値として指定します。
HTTP_Server | HTTP_Server | 6412 | Alive | 1970872013 | 1
6396 | 0:48:01 | https1:4443,http2:722,http1:7779
OC4J 10g（10.1.3.5.0）では、ログ出力用のログ・レベルをApplication Server Controlで次のように設定できます。
OC4Jのホームページで「管理」をクリックします。
管理タスクから「ログ出力の構成」を選択して、「ログ出力の構成」ページを表示します。
「すべてを開く」をクリックして、現在OC4Jにロードされているすべてのログ出力リストを表示します。
ページに表示されている任意のログ出力のログ・レベルを選択します。
Application Server Controlを使用すると、特定のOC4JインスタンスまたはOC4Jインスタンス・グループにアプリケーションをデプロイすることができます。
Application Server Controlのホームページの「クラスタ・トポロジ」をクリックします。次の内容がページに表示されます。
現在クラスタ・トポロジに含まれているすべてのOracle Application Serverインスタンス
各Oracle Application Serverインスタンス内のアクティブなOC4Jインスタンス
各OC4Jインスタンスにデプロイされているアプリケーション
次のようにデプロイ・ターゲットを選択します。
特定のOC4Jインスタンスにデプロイするには、アプリケーションをデプロイするターゲット・インスタンスのリンクをクリックします。
OC4Jインスタンスのグループにデプロイする場合は、ページの一番下の「グループ」の下にあるグループの名前をクリックします。
ターゲット・インスタンスにアクセスしたら、次の項目の説明に従ってアプリケーションをデプロイします。
Application Server Controlには3ページのデプロイ・ウィザードがあり、ユーザーフレンドリで簡単な方法でデプロイ・プロセスを実行できます。
|
注意: デプロイ・ウィザードの使用中に、ブラウザが非アクティブになったためにHTTPセッションがタイムアウトになると、デプロイ・プロセスを最初からやりなおす必要があります。 |
OC4Jインスタンスに対する「アプリケーション」タブをクリックしてから「デプロイ」ボタンをクリックして、デプロイ・ウィザードにアクセスします。
ウィザードの最初のページで、OC4Jサーバーにアップロードするアーカイブを選択します。
既存のデプロイ・プランの場所にナビゲートすることもできます。既存のデプロイ・プランは、アーカイブに適用したり、新しいデプロイ・プランのテンプレートとして使用したりすることができます。デプロイ・プランを指定しないと、デフォルトで新しいデプロイ・プランが作成されます。詳細は、第8章「デプロイ・プランについて」を参照してください。
デプロイ・ウィザードの2番目のページでは、アプリケーションの属性を設定し、WebアプリケーションをWebサイトにバインドします。
アプリケーションまたはモジュールの名前を指定します。これは、OC4J内でアプリケーションを識別するために使用されます。この名前はApplication Server Controlにも表示されます。
次に、デプロイするアプリケーションまたはモジュールの親アプリケーションを選択します。親アプリケーションが指定されていない場合は、defaultアプリケーションが使用されます。
最後に、Webアプリケーションをデプロイする場合は、アプリケーションへのアクセスに使用するWebサイトにアプリケーションをバインドします。Webサイトを定義するXML構成ファイルの名前をリストから選択することで、バインドが行われます。
リストには、OC4Jサーバー・インスタンスに現在定義されているすべてのWebサイトが含まれます。ほとんどの場合、アプリケーションは、default-web-site.xml構成ファイルで定義されているdefault Webサイトにバインドされます。
デプロイ・ウィザードの3番目のページではアーカイブをデプロイする前に、デプロイ・タスクの完了またはデプロイ・プランの直接編集、あるいはその両方を行います。
この最後の画面では、アプリケーションをデプロイする前に、いくつもの構成タスクを完了することができます。これらのタスクは、デプロイ・プランの編集のかわりに使用することができます。デプロイ・プランには、デプロイ時に生成されるOC4Jデプロイメント・ディスクリプタに設定される構成データが含まれます。各オプション・タスクの詳細は、「デプロイ前の構成タスクの完了」を参照してください。
アーカイブをデプロイする直前にデプロイ・プランを編集することもできます。編集したデプロイ・プランは再利用するために保存できます。デプロイ・プランの作成と編集の詳細は、第8章「デプロイ・プランについて」を参照してください。
アプリケーションをデプロイします。
アーカイブは「デプロイ」ボタンをクリックしないと実際にはデプロイされません。この時点までクライアント・サイドのみに存在していたデプロイ・プランも、アーカイブと一緒にOC4Jサーバーに送信されます。一旦デプロイ・プロセスが開始すると、Webブラウザを閉じても続行します。
スケジュールされたジョブを含むアプリケーションを再デプロイする場合、再デプロイの前にすべてのジョブを削除して、その後それらのジョブを再発行しなければ、それらのジョブはスケジュールされたジョブとして実行されません。
スケジュールされたジョブを含むアプリケーションを再デプロイする手順:
スケジュールされたすべてのジョブを削除します。
アプリケーションを再デプロイします。
すべてのジョブを再発行します。
Application Server Controlのデプロイ・ウィザードの3番目のページでは、アプリケーションをデプロイする前にいくつもの構成タスクを完了することができます。「Oracle JDeveloperでのデプロイ・プランの作成または編集」に説明されているように、同じタスクをデプロイ・プラン・エディタで完了することもできます。
デプロイ・プラン・エディタの場合と同じく、様々なデプロイ・タスク・ページで設定された値が、デプロイ時にOC4J固有の適切なデプロイメント・ディスクリプタに書き込まれます。次の項目では、デプロイのための構成タスクについて説明します。
OC4Jでは、2つのタイプのプロバイダがサポートされます。アプリケーション開発モード用のXMLおよび本番環境用のLDAPです。どちらのタイプのプロバイダでも、プロバイダ・データの格納、取得および管理を集中管理するセキュアなリポジトリが実装されます。
XMLベース・プロバイダを使用するには、「ファイルベースのセキュリティ・プロバイダ」を選択します。
XMLベース・プロバイダは、開発環境でプロトタイプ作成中のアプリケーションに適した軽量の実装です。ユーザー、レルムおよびポリシーの情報は、XMLファイル（通常はsystem-jazn-data.xml）に格納されます。
LDAPベースのOracle Internet Directoryプロバイダを使用するには、「Oracle Identity Managementセキュリティ・プロバイダ」を選択します。
このセキュリティ・プロバイダは、本番環境にデプロイするアプリケーションで役立ちます。ユーザー、レルムおよびポリシーの情報は、LDAPベースのOracle Internet Directory（OID）に保持されます。
アプリケーションでOracle Internet Directoryを使用するように構成する前に、Oracle Internet Directoryを使用するようにOC4Jインスタンスを構成する必要があることに注意してください。
Oracle以外のLDAPプロバイダを使用するには、「サード・パーティのLDAPサーバー用のOracleセキュリティ・プロバイダ」を選択します。
アプリケーションでActive Directory、Sun Directory Serverまたはその他のLDAPサーバーを使用するように構成するときは、このオプションを選択します。レルムやプリンシパルの管理には、LDAPサーバー・ベンダーから提供されるツールを使用します。
既存のユーザーおよびユーザー・グループに、アプリケーションで定義したセキュリティ・ロールをマップします。アプリケーションでセキュリティ・ロールを定義した場合は、そのロールをセキュリティ・グループまたはロールにマップできます。この画面ではセキュリティ・グループやユーザーの定義は行いません。
デプロイしているアプリケーションにパッケージされているEnterprise JavaBeans（EJB）モジュールに対して、いくつものプロパティを構成できます。
アプリケーションにパッケージされている各エンティティBeanについて次のプロパティを構成します。示している値はデフォルト値です。
表9-1 エンティティBeanのプロパティ
| プロパティ | 値 |
|---|---|
|
永続性タイプ |
Bean管理永続性とコンテナ管理永続性のどちらをBeanで使用するかを指定します。 |
|
最小インスタンス数 |
インスタンス化つまりプーリングしておくBean実装インスタンスの最小数を設定します。 |
|
最大インスタンス数 |
メモリー内でインスタンス化つまりプーリングが可能なBeanインスタンスの最大数を定義します。 |
|
最大トランザクション再試行 |
システムレベルでの障害のためにロールバックされたトランザクションを再試行する回数を指定します。 |
|
プール・キャッシュのタイムアウト |
ステートレス・セッションがプールにキャッシュされる期間（秒）を設定します。プールのすべての未割当てBeanは、ここに指定した間隔で削除されます。 |
|
JNDI名 |
このEJBモジュールがバインドされるJNDI名を定義します。 |
エンティティBeanを含むEJBモジュールに関連付けるデータ・ソースを選択します。
デフォルトでは、OC4JにデプロイされるすべてのエンティティBeanではOracle TopLink永続性マネージャを使用します。データ・ソースは、Application Server Controlの「JDBCリソース」ページで作成できます。このページに移動するには、OC4Jのホームページの「管理」タブで、「サービス」の下にある「JDBCリソース」を選択します。
アプリケーションにパッケージされている各セッションBeanについて次のプロパティを構成します。示している値はデフォルト値です。
表9-2 セッションBeanのプロパティ
| プロパティ | 値 |
|---|---|
|
最小インスタンス数 |
インスタンス化つまりプーリングしておくBean実装インスタンスの最小数を設定します。 |
|
最大インスタンス数 |
メモリー内でインスタンス化つまりプーリングが可能なBeanインスタンスの最大数を定義します。 |
|
最大トランザクション再試行 |
システムレベルでの障害のためにロールバックされたトランザクションを再試行する回数を指定します。 |
|
コール・タイムアウト |
任意のリソースがビジネス・メソッドまたはライフサイクル・メソッドを起動するまで待機する最長時間（ミリ秒）を指定します。 |
|
プール・キャッシュのタイムアウト |
ステートレス・セッションがプールにキャッシュされる期間（秒）を設定します。プールのすべての未割当てBeanは、ここに指定した間隔で削除されます。 |
|
JNDI名 |
EJBモジュールがバインドされるJNDI名を定義します。 |
アプリケーションにパッケージされている各メッセージドリブンBeanについて次のプロパティを構成します。示している値はデフォルト値です。
表9-3 メッセージドリブンBeanのプロパティ
| プロパティ | 値 |
|---|---|
|
デキュー再試行回数 |
データベースのフェイルオーバーが発生した後で、リスナー・スレッドがJMSセッションの再取得を試行する頻度を指定します。コンテナ管理トランザクションのみで有効です。 |
|
デキュー再試行間隔 |
JMSセッションの再取得を試行する間隔を指定します。 |
|
トランザクション・タイムアウト |
すべてのコンテナ管理トランザクションMDBのトランザクション・タイムアウト間隔（秒）を設定します。 |
|
リスナー・スレッド数 |
トピックまたはキューでの受信JMSメッセージのリスニングのために生成されるリスナー・スレッド数を設定します。トピックに指定できるスレッドは1つのみです。キューには複数のスレッドを指定できます。 |
EJBモジュールのデプロイの詳細は、第3章「Enterprise JavaBeansモジュールのデプロイ」を参照してください。デプロイ済アプリケーションにおけるEJBモジュールの更新の詳細は、「更新されたEJBモジュールの増分再デプロイ」を参照してください。
アプリケーションによってインポートされるライブラリを管理します。デフォルトでは、アプリケーションは、親アプリケーションに存在するものと同じ共有ライブラリのセットを継承します。これには、defaultアプリケーションから継承されるすべての共有ライブラリが含まれます。
デフォルト・ページには、OC4Jサーバー・インスタンスに現在インストールされているすべての共有ライブラリが表示されます。共有ライブラリは、インポートするOC4Jサーバー・インスタンスにすでにインストールされている必要があります。
インポートする各共有ライブラリの横の「インポート」ボックスを選択します。インストールされている最新バージョンのライブラリを使用するには、バージョン番号を指定しないでください。
インポートする共有ライブラリの最小バージョンまたは最大バージョンを指定します。
この機能を使用して、アプリケーションの親から継承したものとは異なるバージョンの共有ライブラリをインポートします。たとえば、インポートする最大バージョンを指定すると、OC4Jのdefaultアプリケーションから継承されるものよりも前のバージョンのOracle JDBCドライバをインポートできます。
親アプリケーションから継承しない共有ライブラリについては、「インポート」ボックスの選択を解除します。
継承するすべての共有ライブラリを削除するには、「親アプリケーションのインポートされた共有ライブラリを継承」チェック・ボックスの選択を解除します。この操作により、デプロイ時にアプリケーションに対して生成されるorion-application.xmlファイルに、次のように<remove-inherited>要素が追加されます。
<imported-shared-libraries> <remove-inherited name="*" /> </imported-shared-libraries>
OC4Jインスタンスにライブラリ・パスとして追加するコード・ソースを指定します（オプション）。
コード・ソースを追加するには、アーカイブの相対パス、絶対パスまたはURLを指定します。OC4Jサーバーの起動時に、ロードするアーカイブを検出するために指定のディレクトリがスキャンされます。
各Webモジュールに作成されるクラス・ローダーを管理します。
OC4Jは、WARとしてサーバー・インスタンスにデプロイされる各Webモジュールにクラス・ローダー・インスタンスを作成します。
「最初にローカル・クラスを検索」チェック・ボックスを選択すると、クラスローダーによって、WARにパッケージされたクラスやリソースを含むJARがロードされてから、WARの外部のJARがロードされます。
たとえば、WARにパッケージされているlog4jのバージョンをWebモジュールで使用し、OC4Jインスタンスにデプロイされるリソース・アダプタにバンドルされているlog4jのバージョンは使用しないとします。このオプションを選択すると、クラス・ローダーによって、WARに含まれるローカルのlog4j JARファイルが強制的にロードされます。
WARにMANIFEST.MFが含まれる場合は、「WAR manifestのクラスパスを含める」ボックスを選択することで、名前付き拡張機能として宣言されているJARを強制的にロードできます。また、ロードされるクラスまたはリソースを含む1つ以上の追加コード・ソースの相対パスまたは絶対パスを、「クラスパス」フィールドに指定することもできます。これらの機能のいずれかを使用すると、Webモジュールのクラス・ローダーによって、クラスがWARにパッケージされているかのようにロードされます。
OC4Jクラスタリング・フレームワークでは、OC4Jインスタンス全体のHTTPセッションまたはステートフル・セッションEJBモジュールのインスタンスに含まれる、オブジェクトと値のレプリケーションがサポートされます。
デフォルトでは、アプリケーションは、親アプリケーションレベルで設定されたクラスタリング構成を継承します。ただし、デプロイ時にアプリケーションレベルでクラスタリングを構成することもできます。アプリケーションレベルで設定される構成プロパティは、親アプリケーションから継承した対応する値をオーバーライドします。
クラスタリングの有効化を選択すると、アプリケーションでのクラスタリングのサポートが有効になります。選択した値によって、アプリケーションの親から継承した設定がオーバーライドされます。
クラスタリングが親アプリケーションレベルで有効になっている場合は、親の構成がデフォルトで適用されます。
ピアツーピア・レプリケーションを選択すると、peer-to-peerレプリケーション・メカニズムが有効になります。使用されるメカニズムはOC4Jのインストール・タイプによって異なります。
Oracle Application Server内のOC4Jインスタンス
クラスタ・トポロジでは、OC4Jインスタンスが互いを動的に検出して通信できるように、動的peer-to-peer検出が使用されます。
クラスタリングが有効な場合は、デフォルトで動的peer-to-peer検出が使用されます。その他の構成は必要ありません。
バインドするネットワーク・インタフェース・カード（NIC）のIPアドレスを指定できます。これは、複数のネットワーク・カードがあるOC4Jホスト・マシンを使用しており、各ネットワーク・カードに特定のIPアドレスがある場合に役立ちます。
スタンドアロンOC4Jインストール
スタンドアロン構成では、OC4Jインスタンスの各JVMが他の少なくとも1つのピアJVMを認識するように静的に構成できます。1つのJVMがピアを認識すると、JVMはそのピアに対応するピアも認識するようになり、結果としてOC4Jインスタンス内のすべてのJVMが互いを認識するようになります。
マルチキャスト・レプリケーションを選択すると、HTTPセッションBeanおよびステートフル・セッションBeanの状態変化をOC4Jがマルチキャスト・パッケージを介して送受信するように構成されます。
これは、スタンドアロンOC4Jインストールで使用されるデフォルトのレプリケーション・プロトコルです。マルチキャストのアドレスとポートは、クラスタのすべてのインスタンスに対して同一であることが必要です。OC4Jのデフォルト・アドレスは230.230.0.1、デフォルト・ポートは45566です。
オプションで、バインドするネットワーク・インタフェース・カード（NIC）のIPアドレスを指定できることに注意してください。これは、複数のネットワーク・カードがあるOC4Jホスト・マシンを使用しており、各ネットワーク・カードに特定のIPアドレスがある場合に役立ちます。
「データベース・レプリケーション」を選択すると、アプリケーションの状態がデータベースにレプリケートされます。
データベースとの接続を提供するデータ・ソースのJNDI名を、「データベースのJNDIロケーション」プルダウン・メニューから選択します。データ・ソースの定義と使用の詳細は、『Oracle Containers for J2EEサービス・ガイド』を参照してください。
デプロイしているEARファイルに含まれるすべてのリソースは、Application Server Controlに表示されます。アプリケーションのすべての環境参照を、現在の操作環境に存在する物理エンティティにマップします。これには、JMSトピックおよびキュー、データ・ソースおよびリソース・アダプタが含まれます。
アプリケーション内のリソース（データ・ソースまたはメール・キュー）に対する参照を、OC4Jコンテナに現在存在する物理エンティティにマップします。特定のリソースが必要な場合、この手順でリソースを対応させるためには、アプリケーションをデプロイする前にそのリソースをOC4Jコンテナに追加しておくことが必要です。
ほとんどのアプリケーションで指定する必要があるリソース参照は、データ・ソースのJNDI名です。Application Server Controlのデプロイ・タスクを通じてデータ・ソース情報を構成することはできません。この設定では、すでに構成済のデータ・ソース、または後から構成可能なデータ・ソースを指定できます。アプリケーションが使用するデータ・ソースのJNDIロケーション名を指定します。
EARファイルにMDBがあるとき、場合によってはサブスクリプションまたはトピックについて情報を追加する必要があります。CMPエンティティBeanのDataSourceオブジェクトを定義している場合は、それらのDataSourceオブジェクトにJNDIロケーションを追加することができます。
並行アプリケーション・アップグレードにより、旧バージョンのアプリケーションの1つ以上のアクティブ・インスタンスを正常に完了しながら、新規バージョンのアプリケーションのホット・デプロイを実行できます。この機能には、アプリケーションのデフォルト・バージョンの変更、異なるバージョンのデプロイとアンデプロイ、バージョンのリタイアなどのバージョン管理機能が含まれます。
並行アプリケーション・アップグレードを使用することで、あるバージョンのJ2EEアプリケーションを実行しながら別のバージョンのアプリケーションをデプロイできるため、エンド・ユーザーは停止時間を経験せずに済みます。新規バージョンのアプリケーションをエンド・ユーザーに公開する前に、本番環境にデプロイされた時点で新規バージョンをテストできます。このテストにより、アプリケーションが本番環境用に正しく構成されていることが保証されます。
並行アプリケーション・アップグレードが機能するための最小限のアーキテクチャは、Oracle Application Serverインスタンス内でOPMNにより管理される2つの独立したOC4Jインスタンスと、1つのOHSインスタンスで構成されます。各OC4Jインスタンスには、内部HTTP Webサイト（このサイトを通じてリクエストは直接OC4Jに移動する）とAJP Webサイト（このサイトを通じてOHSはリクエストをOC4Jにルーティングする）が存在する必要があります。どちらのOC4Jインスタンスも、アプリケーションを実行している必要があります。図9-1は、並行アプリケーション・アップグレードを使用して新規アプリケーション・バージョンをデプロイする前の2つのOC4Jインスタンスの初期状態を示しています。
各OC4Jインスタンスは、同じグループのメンバーである必要はありません。同じグループである場合は、グループ操作を使用してアプリケーションの初期デプロイおよび構成を行うことができます。ただし、並行アプリケーション・アップグレードのデプロイ・タスクは、一度に1つのOC4Jインスタンスに対して実行する必要があります（そのインスタンスがグループのメンバーであるかどうかは関係ありません）。
並行アプリケーション・アップグレードの手順では、2番目のOC4Jインスタンスでバージョン1のアプリケーションの実行を継続し、セッション状態を維持しながら、1番目のインスタンスのアプリケーションを停止します。これにより、本番Webサイト（AJP）に対するすべての新規トラフィックを強制的に2番目のインスタンスに移行します。次に、1番目のインスタンスにバージョン2のアプリケーションをデプロイし、バージョン2をテスト目的でHTTP Webサイトにバインドします。テストに成功したら、バージョン2をAJP Webサイトにバインドして、一般ユーザーに公開できます。本番システムが安定した後で、2番目のOC4Jインスタンスのバージョン1を停止し、そこにバージョン2をデプロイしてテストします。
この手順を使用するには、2つのアプリケーション・バージョンにより処理されるリクエストに互換性が存在し、バージョン1およびバージョン2がそこにルーティングされるリクエストと共存できる必要があります。状態レプリケーションを使用してバージョン1とバージョン2の両方で状態を維持する場合、両方のアプリケーション・バージョン間で維持する状態に互換性が存在する必要があります。
この項では、並行アプリケーション・アップグレードを使用して、主にApplication Server Controlでアプリケーションをデプロイする方法について説明します。デプロイ・タスクは、Antタスク（第10章「デプロイに対するOC4J Antタスクの使用方法」を参照）またはadmin_client.jarコマンド（第11章「デプロイに対するadmin_client.jarユーティリティの使用方法」を参照）を使用して実行することもできます。
OC4Jインスタンスには、デフォルトでAJPリスナーが含まれます。ajpプロトコルを使用するデフォルトの公開Webサイトに加え、httpプロトコルを使用する内部Webサイトを割り当てるように、OC4Jインスタンスに追加のHTTPリスナーを作成できます。その後、AJP Webサイトでエンド・ユーザーにアプリケーションを提供する前に、テスト目的でそのアプリケーションをHTTP Webサイトにバインドできます。
OC4Jインスタンスで追加のHTTPリスナーを作成する手順:
ORACLE_HOME/j2ee/instance/config/server.xmlファイルを編集して、次のように<web-site>要素を追加します。
<web-site default="false" path="./internal-web-site.xml" />
新規*-web-site.xmlファイルを作成して、AJP Webサイト用のポートとは異なるポート番号を指定します。
例9-1は、c:\OracleAS\j2ee\blue1\config\internal-web-site.xmlというファイルの内容を示しています。
例9-1 HTTPリスナーを追加する*-web-site.xmlファイル
<?xml version="1.0"?>
<web-site xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://xmlns.oracle.com/oracleas/schema /web-site-10_0.xsd"
port="9999" protocol="http" display-name="Internal HTTP Site"
schema-major-version="10" schema-minor-version="0" >
<default-web-app application="default" name="defaultWebApp" root="/j2ee" />
<access-log path="../log/internal-web-access.log" split="day" />
</web-site>
opmn.xmlファイルを編集して、OC4Jインスタンスの新規ポート・エントリを追加します。
<start timeout="600" retry="2"/>
<stop timeout="120"/>
<restart timeout="720" retry="2"/>
<port id="default-web-site" range="7700" protocol="ajp"/>
<port id="internal-web-site" range="9999" protocol="http"/>
<port id="rmi" range="12401-12500"/>
<port id="rmis" range="12701-12800"/>
<port id="jms" range="12601-12700"/>
<process-set id="default_group" numprocs="1"/>
opmn.xmlファイルをリロードします。
OC4Jインスタンスを再起動します。
これで、OHS（AJP）からのリクエストを処理する外部リスナーと、OC4Jインスタンスに直接送信されるリクエストを処理する内部リスナーを使用できます。次のように、opmnctl status -lコマンドによる出力で、HTTPポートを参照できます。
Processes in Instance: ohs_j2ee_changed ---------------------------------+--------------------+---------+----------+-- ----------+----------+-----------+------ ias-component | process-type | pid | status | uid | memused | uptime | ports ---------------------------------+--------------------+---------+----------+-- ----------+----------+-----------+------ OC4JGroup:default_group | OC4J:foo | 4856 | Alive | 768545086 | 194428 | 0:05:56 | jms:12601,ajp:12501,http:9999,rmis:12701,aussie-tripper:3762,rmi:12401
新規HTTPリスナーに移動し、リスナーが有効であり、リクエストを受信できることを確認してください。
図9-2に示すとおり、Application Server Controlの「ランタイム・ポート」ページでWebサイトのポートとプロトコルを管理することもできます。
Webサイトの作成および構成の詳細は、『Oracle Containers for J2EE構成および管理ガイド』の「OC4JでのWebサイトの管理」を参照してください。
並行アプリケーション・アップグレードでは、単一のOracle Application Server 10gリリース3（10.1.3.5.0）インスタンス内の2つのOC4Jインスタンスを対象に、アプリケーションの旧バージョンを維持しながら新規バージョンをデプロイできます。Oracle Application Serverインスタンスには、ApacheベースのOracle HTTP Server（OHS）も含まれます。この設定により、アプリケーションのインプレース・アップグレードを実行できます。
並行アプリケーション・アップグレードによりアプリケーションをデプロイする手順:
図9-1のとおり、OHSをフロントエンドとする2つのOC4Jインスタンスを設定して、AJPリスナーとHTTPリスナーの両方を割り当てます。
AJPリスナーでは、OHSからルーティングされる通常のユーザー・トラフィックを処理します。HTTPリスナーは、内部テスト目的に使用できます。アプリケーション・インスタンスは、通常の状態で実行中のときはAJPリスナーにバインドされます。
HTTPリスナーの追加方法の詳細は、「OC4Jインスタンスでの追加のHTTPリスナーの作成方法」を参照してください。
同じバージョンのアプリケーションが2つのOC4Jインスタンスで実行されている状態で、各リクエストが正しく処理されていることを確認します。
1番目のOC4Jインスタンスのアプリケーションを次のように停止します。
Application Server Controlの「クラスタ・トポロジ」ページで、1番目のOC4Jインスタンスの名前をクリックします。
「OC4J」ページで「アプリケーション」をクリックします。
アプリケーション名をクリックします。
「アプリケーション」ページで「停止」をクリックします。
アプリケーションを停止すると、図9-3に示すとおり、完了と同時に処理中のリクエストが静止され、アプリケーション・インスタンスに新規トラフィックが送信されなくなります。
1番目のOC4Jインスタンスのアプリケーションで処理中のすべてのリクエストが静止されるまで2分間待機します。
少し時間が経つと（通常は2分以内）、処理中のすべてのリクエストは静止されます。この待機時間は、実際のアプリケーションに応じて調整できます。
1番目のOC4Jインスタンスのアプリケーションを次のようにアンデプロイします。
Application Server Controlの「クラスタ・トポロジ」ページで、1番目のOC4Jインスタンスの名前をクリックします。
「OC4J」ページで「アプリケーション」をクリックします。
アプリケーション名をクリックします。
「アプリケーション」ページで「アンデプロイ」をクリックします。
「戻る」をクリックします。
これで1番目のOC4Jインスタンスからアプリケーションがアンデプロイされ、図9-4のようになります。
|
注意: HTTP Webサイトが再デプロイ用に選択されていれば、「アンデプロイ」や「デプロイ」のかわりに「再デプロイ」も並行アプリケーション・アップグレードの有効なオプションです。アプリケーションの再デプロイでは、その既存の設定を維持できます。アプリケーションをアンデプロイした後に新規バージョンをデプロイすると、アプリケーションはその構成とともに削除され、新しくデプロイされます。 |
新規バージョンのアプリケーションを1番目のOC4Jインスタンスにデプロイし、OHSがトラフィックを新規バージョンにルーティングしないようにアプリケーションをHTTP Webサイトにバインドします。
1番目のOC4Jインスタンスの「OC4J」ページにある「アプリケーション」タブで、「デプロイ」をクリックします。
EARファイルの場所を指定して「次へ」をクリックします。
アプリケーション名を指定します。
ドロップダウン・メニューからHTTP Webサイトを選択します。
「次へ」をクリックします。
「デプロイ」をクリックします。
「戻る」をクリックします。
これで、新規バージョンのアプリケーションが1番目のOC4Jインスタンスにデプロイされ、内部Webサイトに公開されました。図9-5は、2つの異なるバージョンのアプリケーションを実行するOC4Jインスタンスの状態を示しています。
図9-5 1番目のOC4Jインスタンスの内部Webサイトにデプロイされた新規バージョンのアプリケーション
1番目のOC4Jインスタンスで、内部的にアプリケーションにアクセスできるHTTPリスナーを通じて新規バージョンのアプリケーションをテストします。
アプリケーションが予想どおりに動作することを確認します。
新規バージョンのアプリケーションは、次の内部Webサイトから使用できます。
http://host_name:port_number/application_name
旧バージョンのアプリケーションは、次の外部Webサイトから使用できます。
https://host_name:port_number/application_name
新規バージョンのアプリケーションをAJPリスナーにバインドし、OHSサーバーでそのアプリケーションにリクエストをルーティングできるようにします。
現行ディレクトリを次のように1番目のOC4Jインスタンスのホーム・ディレクトリに変更します。
CD c:\OracleAS\j2ee\blue1
次のようなadmin_client.jar -bindWebAppコマンドを発行します。
java -jar admin_client.jar deployer:oc4j:opmn://hostname/blue1 oc4jadmin password -bindWebApp -appName testApp -webModuleName testAppWeb -webSiteName default-web-site
図9-6は、OC4Jインスタンスの本番Webサイトでそれぞれ並行して稼働する新規バージョンと旧バージョンのアプリケーションを示しています。
手順3〜8を繰り返し、2番目のOC4Jインスタンスに新規バージョンのアプリケーションをデプロイしてテストします。
図9-7は、2番目のOC4Jインスタンスで静止された旧バージョンのアプリケーションを示しています。
図9-8は、1番目のOC4Jインスタンスの本番Webサイトで稼働し続ける新規バージョンのアプリケーションと、2番目のOC4Jインスタンスからアンデプロイされた旧バージョンのアプリケーションを示しています。
図9-9は、テスト目的で2番目のOC4JインスタンスのHTTP Webサイトにデプロイされた新規バージョンのアプリケーションを示しています。
図9-9 テスト目的で2番目のOC4Jインスタンスの内部Webサイトにバインドされた新規アプリケーション
新規バージョンのアプリケーションを2番目のOC4JインスタンスのAJPリスナーにバインドした後で、新規バージョンが2つのOC4Jインスタンスの本番Webサイトで実行されていることを確認します。
図9-10は、並行アプリケーション・アップグレードを使用してアプリケーションをデプロイした後のOC4Jインスタンスの状態を示しています。
図9-10 並行アプリケーション・アップグレードの実行後に新規バージョンのアプリケーションが稼働するOC4Jインスタンス
アプリケーションまたはモジュールをアンデプロイすると、OC4Jランタイムからコードが削除され、Webサイトに対する既存のバインドがすべて削除されます。
「アプリケーション」タブ→「アンデプロイ」ボタンをクリックします。
アプリケーションを選択して、「アンデプロイ」ボタンをクリックします。
新しい共有ライブラリの作成、共有ライブラリからのアーカイブの追加または削除、他の共有ライブラリの既存共有ライブラリへのインポートなどをApplication Server Controlで実行できます。
OC4Jインスタンスで有効な共有ライブラリを管理する手順:
OC4Jインスタンスに対するOC4Jのホームページにナビゲートします。
「管理」をクリックしてOC4Jの「管理」ページを表示します。ページには、このOC4Jインスタンスに対して実行できる各種の管理タスクの一覧表があります。
必要に応じて、拡張アイコンをクリックするか「すべてを開く」をクリックして、表の「プロパティ」セクションを開きます。
表の「共有ライブラリ」行のタスク・アイコンをクリックします。
Application Server Controlには「共有ライブラリ」ページが表示され、OC4Jインスタンスで現在使用できる共有ライブラリが一覧表示されます。OC4Jインスタンスから共有ライブラリを追加または削除することもできます。
ページのオプションの詳細を参照するには「ヘルプ」をクリックします。
Application Server Controlによる共有ライブラリの作成および管理の詳細は、オンライン・ヘルプのトピックを参照してください。
OC4Jインスタンスにデプロイされているアプリケーションを起動、再起動または停止する手順は、次のとおりです。
OC4Jインスタンスに対するOC4Jのホームページにナビゲートします。
「アプリケーション」をクリックします。
アプリケーションを選択します。
「起動」、「再起動」または「停止」ボタンをクリックします。
|
注意: アプリケーションのホームページからアプリケーションを起動、停止または再起動することもできます。 |
デプロイ済アプリケーションの起動、停止または再起動には次の制約があります。
親アプリケーション（defaultアプリケーションなど）を停止すると、Application Server Controlはその親アプリケーションに依存するすべての子アプリケーションを自動的に停止します。
子アプリケーションを起動すると、Enterprise Managerは必要な親アプリケーションを自動的に起動します。
ascontrolアプリケーションはApplication Server Controlを表し、アプリケーション・サーバー環境の管理に使用されるため、このアプリケーションにおける管理タスクをApplication Server Controlで実行することはできません。
1つのスタンドアロンOC4Jインスタンスを管理している場合は、ascontrolアプリケーションを停止、起動または再起動することはできません。このアプリケーションを停止すると、Application Server Controlの表示または使用が不可能になります。
複数のOC4Jインスタンスを管理しているクラスタ環境にある場合は、デプロイ先のOC4Jインスタンスと同様に、「クラスタ・トポロジ」ページを使用してascontrolアプリケーションを起動、停止または再起動できます。ただし、Application Server Controlにはアクティブなascontrolアプリケーションの停止を暗示する警告が表示されます。
「クラスタ・トポロジ」ページを使用して複数のOC4Jインスタンスを管理していると、OC4Jインスタンスのそれぞれにascontrolアプリケーションが含まれることに気づくはずです。ほとんどの場合、アクティブなascontrolアプリケーションのみが起動して実行されています。
ログ・ビューワを使用してリモートOC4Jインスタンスに対するログ・ファイルを表示しようとすると、Application Server Controlでは、リモートOracle Application Serverインスタンス内のOC4Jインスタンスでascontrolアプリケーションが実行中かどうか確認されます。そのアプリケーション・サーバー・インスタンスでどのascontrolアプリケーションも実行されていない場合は、リモートascontrolを起動する必要性を示すメッセージが表示されます。
次に、リモートascontrolアプリケーションの起動か、操作の中止を選択します。ログ・ビューワからのascontrolの起動を選択した場合、リモートascontrolはOracle HTTP ServerからHTTPリクエストを受信するようには設定されないので注意してください。ただし、「クラスタ・トポロジ」ページからそのリモートascontrolが実行中であることを確認できます。ログ・ビューワによるリモート・ログ・ファイルの表示および管理が終了した後は、「クラスタ・トポロジ」ページからリモートascontrolを停止できます。
Application Server Controlを使用して、Oracle Application Server環境でOC4JインスタンスまたはOC4Jインスタンス・グループを再起動または停止できます。
Application Server ControlでOC4Jインスタンスを再起動または停止する手順:
OC4Jのホームページにナビゲートします。
停止したときの状態でOC4Jインスタンスを再起動するには、「再起動」ボタンをクリックします。
OC4Jインスタンスを停止するには、「停止」ボタンをクリックします。
「クラスタ・トポロジ」ページから「メンバー」セクションでインスタンスを選択し、「再起動」または「停止」ボタンをクリックすることでOC4Jインスタンスを再起動または停止することもできます。
Application Server ControlでOC4Jインスタンス・グループを再起動または停止する手順:
「クラスタ・トポロジ」ページの「グループ」セクションでグループを選択します。
停止したときの状態でOC4Jインスタンス・グループを再起動するには、「起動」ボタンをクリックします。
OC4Jインスタンス・グループを停止するには、「停止」ボタンをクリックします。
Application Server Controlを使用して、Oracle Application Server環境でOC4JインスタンスまたはOC4Jインスタンス・グループのデータソースおよび接続プール（JDBCリソース）を表示、作成および削除できます。
Application Server ControlでOC4Jインスタンスのデータソースと接続プールを管理する手順:
OC4Jインスタンスに対するOC4Jのホームページにナビゲートします。
「管理」をクリックしてOC4Jの「管理」ページを表示します。ページには、このOC4Jインスタンスに対して実行できる各種の管理タスクの一覧表があります。
必要に応じて、拡張アイコンをクリックするか「すべてを開く」をクリックして、表の「サービス」セクションを開きます。
表の「JDBCリソース」行のタスク・アイコンをクリックします。
Application Server Controlには「JDBCリソース」ページが表示され、OC4Jインスタンスで現在使用できるデータソースおよび接続プールが一覧表示されます。
ドロップダウン・メニューを使用して、対象のデプロイ済アプリケーション固有のデータソースおよび接続プールを表示します。
データソースおよび接続プールの表示、作成および削除の詳細を参照するには、「ヘルプ」をクリックします。
Application Server ControlでOC4Jインスタンス・グループのデータソースと接続プールを管理する手順:
「クラスタ・トポロジ」ページにナビゲートします。
ページの「グループ」セクションをスクロールして、構成するグループの名前をクリックします。
「管理」をクリックしてグループの「管理」ページを表示します。ページには、このグループに対して実行できる各種の管理タスクの一覧表があります。
必要に応じて、拡張アイコンをクリックするか「すべてを開く」をクリックして、表の「サービス」セクションを開きます。
表の「JDBCリソース」行のタスク・アイコンをクリックします。
Application Server Controlには「JDBCリソース」ページが表示され、グループ内のOC4Jインスタンスで現在使用できるデータソースおよび接続プールが一覧表示されます。ドロップダウン・メニューを使用して、対象のデプロイ済アプリケーション固有のデータソースおよび接続プールを表示します。
データソースおよび接続プールの表示、作成および削除の詳細を参照するには、「ヘルプ」をクリックします。
Application Server ControlでJMS宛先を管理する手順は、次のとおりです。
OC4Jインスタンスに対するOC4Jのホームページにナビゲートします。
「管理」をクリックしてOC4Jの「管理」ページを表示します。ページには、このOC4Jインスタンスに対して実行できる各種の管理タスクの一覧表があります。
必要に応じて、拡張アイコンをクリックするか「すべてを開く」をクリックして、表の「サービス」セクションを開きます。
表の「JMS宛先」行のタスク・アイコンをクリックします。
Application Server Controlには「JMS宛先」ページが表示され、OC4Jインスタンスで使用できるJMS宛先が一覧表示されます。次に、その他のJMS宛先の作成、または既存のJMS宛先の削除を実行できます。
Application Server ControlによるJMSリソースの管理の詳細は、オンライン・ヘルプのトピックを参照してください。
