WebSphere Application Server は、Web サーバーと連動して作動し、Web
アプリケーションからの動的コンテンツ (サーブレットなど) の要求経路を定めます。Web サーバーは、
ブラウザーから WebSphere Application Server で稼働するアプリケーションに
トラフィックを送信するために必要です。Web サーバー・プラグインは、
XML 構成ファイルを使用して、要求が WebSphere Application Server に関するものであるかどうかを判別します。
始める前に
- Web サーバーがまだインストールされていない場合はインストールします。
IBM HTTP Server for WebSphere Application Server を使用する場合は、
IBM HTTP Server のインストール
を参照してください。
使用しない場合は、Web サーバーで提供されているインストール情報を参照してください。
- GET や POST などの Web アプリケーションで必要な操作を行うように
、Web サーバーを構成するようにしてください。
一般に、この構成作業には、Web サーバー構成ファイル (IBM HTTP Server の httpd.conf ファイルなど) での
ディレクティブの設定作業が含まれています。Web サーバー資料の説明を参照してください。
何らかの操作を必要とするサーブレットや JSP ファイルにアクセスする際に、
その操作を使用できない場合は、IBM HTTP Server から次のようなエラー・メッセージが表示されます。
HTTP method POST is not supported by this URL.
- Web サーバーに適切なプラグイン・ファイルがインストールされており、この Web サーバーの Web サーバー定義を作成し、構成するために、configureWeb_server_name スクリプトが実行されていることを確認してください。
分散プラットフォーム Web サーバーを使用している場合は、「Plug-in Installation」ウィザードを使用して、Web サーバーに適切なプラグイン・ファイルをインストールします。次に、このウィザードで作成された configureWeb_server_name スクリプトを実行して、WebSphere 構成リポジトリー内に Web サーバーの定義を作成し、それを構成します。
このタスクについて
以下のステップが、プラグインのインストール・プロセス中に実行されます。
追加情報については、Plug-in Installation Roadmap を参照してください。
- ノードが作成されます。
Web サーバーが
Application Server とは異なるコンピューター上にある場合は、管理対象外ノードが作成されます。
管理対象外ノードとは、そのノード上で WebSphere ノード・エージェントが稼働していないノードのことです。
管理対象外ノードを使用すると、WebSphere Application Server は、
その構成トポロジー内のアプリケーション・サーバーとは異なるサーバーを
代表することができます。
これにより、これらのサーバーおよびアプリケーション・サーバー間の
接続情報を保守することができます。
ノードの管理
では、
ノードの作成方法について説明します。
- Web サーバー定義が作成されます。
Web サーバー定義を作成するには、
管理コンソールを使用することも、ConfigureWebServerDefintion.jacl スクリプトを使用することもできます。
管理コンソールを使用する場合は、以下を行います。
- 直前のステップで作成されたノードを選択し、Server 名フィールドに
、Web サーバー定義の作成で対象にした Web サーバーのローカル名を入力します。
- ウィザードを使用して Web サーバー定義を完了します。
- アプリケーションまたはモジュールは、Web サーバーにマップされます。
この Web サーバーと併用するアプリケーションがすでにインストール
されている場合、そのアプリケーションは、自動的に Web サーバーにマップされます。
アプリケーションがインストールされていない場合は、アプリケーション
のインストール・プロセスにおいてモジュールをサーバーにマップするステ
ップの実行中に、この Web サーバーを選択します。
- マスター・リポジトリーが更新されて保管されます。
プラグインをインストールする場合、そのプラグインの構成ファイルが自動的に作成されます。
この構成ファイルで、プロパティーのデフォルト設定の変更や細かな調整を行うことができます。
いずれかの設定値を変更する場合は、このファイルを再生成して、変更内容を有効にする必要があります。
構成ファイルの生成または再生成は、完了までに時間がかかる場合があります。
これが終了すると、管理セル内のすべてのオブジェクトはそれぞれの最新の
設定を使用しますが、Web サーバーはそれらの設定にアクセスすることができ
ます。Application Server サーバーが Web サーバーと同じ物理マシン上に
ある場合、通常再生成が完了するまでに 30 秒から 60 秒かかります。
再生成を行う場合に、これらのサーバーが共に同一マシン上にない場合、
さらに時間がかかります。
以下の手順では、SSL および Web サーバー調整の構成を含め、
プラグイン構成ファイルを更新するためのステップについて説明します。
プロシージャー
- 管理コンソールを使用して、プラグイン構成ファイルで設定を変更します。
Web サーバー・プラグインをセットアップする場合、
構成の変更に応じて、構成を自動的に生成するかどうかを決定する必要があります。
Web サーバー・プラグイン構成サービスが使用可能になっていて、
以下のいずれかの状態が発生した場合には、プラグイン構成ファイルは自動的に生成されます。
- Web サーバーが作成されるか、保管される場合。
- アプリケーションがインストールされる場合。
- アプリケーションがアンインストールされる場合。
- 仮想ホスト定義が更新される場合
plugin-cfg.xml ファイルの再生成は、管理コンソールを使用して行うことも、GenPluginCfg コマンドを実行して行うこともできます。
管理コンソールを使用するには、次の手順を実行します。
- 「サーバー」>「Web サーバー」>「webserver」>「plug-in properties」と選択します。
- 「プラグイン構成ファイルの自動生成」を選択するか、
以下のトピックを 1 つ以上クリックして、plugin-cfg.xml ファイルを手動で構成します。
- キャッシング
- 要求および応答
- 要求ルーティング
- カスタム・プロパティー
Web サーバー・プラグイン構成プロパティーは、
各プロパティーを上記のトピックのいずれかにマップします。
注: 手動で plugin-cfg.xml ファイルを更新することはお勧めできません。
特定の Web サーバーに対して行った手動更新は、
その Web サーバーの plugin-cfg.xml ファイルが再生成されると
必ず上書きされます。
- 「OK」をクリックします。
- Web サーバーで plugin-cfg.xml ファイルを
見つけられるようにするには、アプリケーション・サーバーを停止して、
再度アプリケーション・サーバーを始動する必要があります。
オプション: プラグイン構成ファイルを編集します。
構成ファイルは編集する必要はありません。このファイルを編集する場合、以下のことに注意してください。
- このファイルは ASCII フォーマットです (ISO-98859-1)。
- ファイルに対して行うすべての手動の変更は、次にファイルが再生成されたときに
上書きされます。
- この構成で Secure Sockets Layer (SSL) を使用するには、
プラグインのインストール・ウィザードを使用して、ワークステーション上に適切な
GSKIT インストール・イメージ・ファイルをインストールします。
GSKIT の構成方法については、Secure Sockets Layer 用 Web サーバー・プラグインの構成
を参照してください。
- Application Server で、Web サーバー・プラグインが送信するプライベート・ヘッダーを使用できるようにする
には、使用しているトランスポートが SSL 用に構成済みであり、信頼されていることを確認してください。
ご使用のトランスポートがトランスポート・チェーンの場合、トラスト・ファイル定義を組み込むそのチェーン用の
SSL レパートリーを定義する必要があります。
トラスト・ファイル定義が組み込まれていない場合、プライベート・ヘッダーは無視され、
アプリケーション・サーバーは、要求されたアプリケーションを見つけられない場合があります。
HTTP トランスポートを使用する場合は、
そのトランスポートが SSL 用に構成され、
トランスポート用の トラステッド・カスタム・プロパティーが false に設定されていることを確認してください。
プライベート・ヘッダーを使用できるようにすると、
このトランスポートは、受信するすべてのインバウンド・プライベート・ヘッダーを信頼するようになります。
このため、このトランスポートへのすべてのインバウンド・パスが信頼できるものであることを確認する必要があります。
- Web サーバーを調整します。 詳しくは、Web サーバーのチューニング
を参照してください。
- プラグイン構成を伝搬します。
Web サーバー・プラグイン構成サービスが使用可能になっていて、以下のいずれかが当てはまる場合は、
プラグイン構成ファイル (plugin-cfg.xml) が自動的に Web サーバーに伝搬されます。
- Web サーバーがローカル Web サーバーである場合。(Web サーバーが、
アプリケーション・サーバーとして同一マシン上に配置されている場合。)
- Web サーバーが、IBM HTTP Server 管理サーバーが稼働しているリモートの IBM HTTP Server バージョン 6.0 である場合。
これらの条件がいずれも当てはまらない場合、plugin-cfg.xml ファイルを手動で
リモート Web サーバーのインストール・ロケーションにコピーする必要があります。
重要: FTP 機能を使用してコピーを行ったときに、構成の再ロードに障害が起こる場合には、plugin-cfg.xml
ファイルのファイル・アクセス権を確認して、rw-r--r-- に設定されていることを確認してください。
ファイル・アクセス権が正しくない場合、Web サーバーは、新規バージョンのファイルにアクセスできないので、構成の
再ロードに障害が起こる原因となります。
ファイル・アクセス権が正しくない場合は、
以下のコマンドを発行して、ファイル・アクセス権を適切な設定に変更します。
chmod 644 plugin-cfg.xml
AIX FTP 機能は、ファイル属性を保存しません。
したがって、AIX オペレーティング・システムから plugin-cfg.xml
を手動でコピーする必要がある場合は、ファイルをコピーするのに FTP 機能ではなく、AIX RCP
機能を使用して行いたい可能性があります。
リモート Web サーバーのインストール・ロケーションは、
この Web サーバー用にノードを作成したときに指定したロケーションです。
結果
構成が完了しました。構成をアクティブにするには、Web サーバーを停止して再始動します。
Web サーバーの再始動に際して問題が発生した場合は、plugin-cfg.xml ファイルの
エラーが含まれている個所に関する情報を http_plugin.log ファイルで検査します。
このログ・ファイルには、エラーの発生した行番号が、
Web サーバーが始動しなかった原因を診断するのに役立つその他の詳細と一緒に記録されています。
次に管理コンソールを使用して、plugin-cfg.xml ファイルを更新します。
アプリケーションのインストールまたはアンインストールが頻繁に行われない場合
(これは実稼働環境では通常の状態です)、または上記にリストされているアクションの
いずれかが発生するごとに、プラグイン構成ファイルが生成および配布され、
そのパフォーマンスの影響が許容範囲内である場合は、このサービスを
使用可能に設定することを検討してください。
多数のアプリケーションをインストールするといった、
一連の変更を同時に行う場合には、最後の変更を行うまで、
構成サービスを使用不可にしておく必要があります。Web サーバー・
プラグイン構成サービスは、デフォルトで使用可能になっています。
このサービスを使用不可に設定するには、管理コンソールで、「サーバー」>「アプリケーション・サーバー」>「server_name」>
「Administration Services」>「Web server plug-in
configuration service」とクリックして、「Enable automated Web
server configuration processing」オプションを選択解除します。
ヒント:
ご使用のインストール・システムでファイアウォールを使用する場合には
、Web サーバー・プラグインが、オープンされているポートを使用す
るように構成してください。
(オープン・ポートの取得方法については、セキュリティー管理者に確認してください。)