Web ゲートウェイでの Web サーバ構成の拡張
InterSystems Web ゲートウェイのファイルをインストールしたら、Web ゲートウェイを拡張として Web サーバ構成に追加する必要があります。追加したら、Web サーバは Web ゲートウェイを呼び出して、InterSystems IRIS® Web アプリケーションへの要求を処理できます。
このページでは、Web ゲートウェイ拡張を各サポート対象 Web サーバの Web サーバ構成に追加するための推奨方法について説明します。インターシステムズが実装している、Web ゲートウェイを介してルーティングする要求を指定する方法についても、Web サーバごとに概説します。(アプリケーション要求をルーティングする方法を検討する際は、"Web ゲートウェイを介して要求をルーティングする URL パスの選択" を参照してください。)
多くの場合、インストーラは Apache (UNIX®/Linux/macOS の場合) または IIS (Windows の場合) に対して、このページの構成手順を自動的に実行できます。その後、作成された構成を、お使いのシステムのニーズに合わせて容易にカスタマイズできます。
Web サーバを構成したら、Web ゲートウェイ管理ページを使用して、InterSystems IRIS インスタンスに接続し、それらにアプリケーション・パスを関連付けます。
考慮すべきファイル
Web ゲートウェイ・ファイル
Web ゲートウェイ・ファイルは、次のいずれかの場所にインストールされます。
-
UNIX®/Linux/macOS 上の /opt/webgateway/bin。InterSystems IRIS インストールへの変更に影響されないために、InterSystems IRIS のインストール・ディレクトリではなく、この共通の場所で Web ゲートウェイ・ファイルを使用することをお勧めします。
-
Windows 上の C:\Inetpub\ (インターネット・インフォメーション・サービス (IIS) が構成されている場合)。InterSystems IRIS インストールへの変更に影響されないために、InterSystems IRIS のインストール・ディレクトリではなく、この共通の場所で Web ゲートウェイ・ファイルを使用することをお勧めします。
-
以下の場合は、<installDir>/csp/bin または <installDir>/bin :
-
<installDir> に InterSystems IRIS インスタンスがインストールされている
-
Web サーバが構成されていない。
-
-
以下の場合は、<installDir> または <installDir>/bin :
-
<installDir> にスタンドアロン Web ゲートウェイがインストールされている
-
Web サーバが構成されていない。
-
一般に、インターシステムズでは Web ゲートウェイをバイナリ・ファイルのペアとして実装します。1 つのファイルはランタイム機能を実装し、もう 1 つのファイルは Web ゲートウェイ管理ページを実装します。管理バイナリはファイル名の末尾に Sys を追加することで、ランタイム・バイナリと区別されます。
Web サーバ・ファイル
Web サーバのインストール場所は、Web サーバやオペレーティング・システムによって異なります。Web サーバがインストールされている場所を見つけるには、Web サーバのドキュメントを参照してください。
Web ゲートウェイのドキュメントでは、わかりやすくするために、Web サーバのインストール場所 (通常、既定の場所) が例で指定されていることがあります。この場所は、お使いのシステム上の場所と一致しないことがあります。その場合は、システム上のファイルの場所に置き換えてください。
静的ファイル
必要なすべてのファイル・タイプについて、Web ゲートウェイがアプリケーションの相対 URL パスに送信される要求を処理できるように Web サーバが構成されている場合、InterSystems IRIS インスタンスは Web アプリケーション応答の一部として静的ファイルを処理できます。
InterSystems IRIS CSP Web アプリケーションが処理する静的ファイルは、Web アプリケーションに対応する <installDir>/csp/ ディレクトリに配置されます。<installDir> は、InterSystems IRIS インスタンスのインストール・ディレクトリです。
以下に例を示します。
-
<installDir>/csp/broker には、複数の組み込みのシステム・アプリケーションで共有されるファイルが含まれます。
-
<installDir>/csp/sys には、管理ポータルで使用するファイルが含まれます。
既定では、InterSystems IRIS CSP Web アプリケーションは、関連するディレクトリから静的ファイル自体を処理するように構成されています。
ただし、Web アプリケーションは、Web サーバが代わりにこれらの静的ファイルを処理できるようにすることもできます。例えば、1 つの Web サーバで複数のリモート InterSystems IRIS インスタンスを処理しているシステムがある場合、この Web サーバ マシンにとってローカルな共通の場所からこれらのファイルを提供する方が適切な可能性があります。ただし、これにより問題が生じる可能性があることに注意してください。例えば、共通の Web サーバが異なるバージョンの InterSystems IRIS を提供する場合、同じファイルの 2 つの異なるバージョン間で競合が発生する可能性があります。
InterSystems IRIS Web アプリケーションの静的ファイルを処理およびキャッシュするように Web サーバを構成するには、アプリケーションのパス (アプリケーションの静的ファイルの要求の送信先) と、Web サーバが適切なアクセス権を持っており、静的ファイルが保存されているローカル・ファイル・システムの場所との間にマッピングを作成する必要があります。
Web サーバごとのこのオプションのマッピング作成方法については、Web ゲートウェイのドキュメントの各所で説明しています。Web サーバが自ら管理するローカル・ファイル・システムの場所の静的ファイルを処理するように Web サーバを構成する方法の詳細は、お使いの Web サーバのドキュメントを参照してください。
UNIX®/Linux/macOS 向けの Apache
Apache HTTP Web サーバは Apache Software Foundation によって提供されており、http://www.apache.orgOpens in a new tab から無料でダウンロードできます。多くのシステムは、Apache を事前にインストールおよび構成して、すぐに使用できる状態で出荷されます。サポート対象 UNIX® または Linux システムに Apache をインストールする方法については、次の Developer Community の記事を参照してください : https://community.intersystems.com/post/how-install-apache-iris-supported-operating-systemsOpens in a new tab。
macOS では、InterSystems IRIS インストーラは事前インストールされているバージョンの Apache を自動的に構成することはできません。ただし、Homebrew (https://formulae.brew.sh/formula/httpd#defaultOpens in a new tab) を使用してインストールされた Apache のバージョンを自動的に構成することはできます。
このページでは、インターシステムズが Apache のネイティブ API を使用して実装する動的モジュール csp_module_sa を使用して、Apache で Web ゲートウェイを導入する方法を説明します。
csp_module_sa モジュールは、2 つの動的共有オブジェクト (.so) ファイルを使用して Web ゲートウェイを実装します。
-
CSPa24.so — ランタイム・バイナリ。
-
CSPa24Sys.so — Web ゲートウェイ管理バイナリ。
これが Apache の推奨導入オプションで、ほとんどのユース・ケースで有効です。
セキュリティが制限されたバージョン の Apache (SELinux を搭載した RHEL など) を使用するシステムで Web ゲートウェイを構成する場合は、"ロック・ダウン Apache インストールへの Web ゲートウェイの追加" で補足手順を参照してください。"Apache の代替オプション" では、Network Service Daemon (NSD) を使用するオプションを含め、Apache で Web ゲートウェイを導入するその他のオプションについて説明しています。
"Apache に関する考慮事項" では、Web ゲートウェイに接続されている Apache Web サーバの管理に関するガイダンスを提供しています。詳細なガイダンスは、Apache のドキュメント (https://httpd.apache.org/docs/Opens in a new tab) を参照してください。
Apache が共有オブジェクト・モジュールを管理できることの確認
Apache 独自の API を使用して Apache 構成に Web ゲートウェイを追加する前に、Apache のビルドに共有オブジェクトを管理するための組み込みのモジュール (mod_so) が含まれていることを確認します。
Red Hat Linux でこのチェックを実行するには、コマンド行から以下のコマンドを発行します (オペレーティング・システムに対応するコマンドを選択します)。
httpd -l
apache2 -l
このコマンドは、現在の Apache インストールに含まれているモジュールのリストを示します。mod_so がこのリストに含まれていない場合は、Apache のドキュメント (https://httpd.apache.org/docs/2.4/Opens in a new tab) で提供されている手順に従って、このモジュールを含む Apache の新しいビルドをコンパイルします。
Web サーバ構成への Web ゲートウェイ・モジュールの追加
-
Web ゲートウェイ・モジュール・ファイルのファイル・システムの場所を記録しておきます。これらの手順では、最も一般的な場所である /opt/webgateway/bin を使用します。
-
Apache Web サーバ構成ファイル (httpd.conf) をテキスト・エディタで開きます。このファイルは、Apache のインストール・ディレクトリの /conf サブディレクトリ内にあります。最も一般的なインストール場所は次のとおりです。
/etc/httpd/conf
/usr/apache2/conf
-
Web ゲートウェイ・モジュールを追加するファイルの最後に指示文を追加します。これらの指示文では、以下を行います。
-
LoadModule 指示文を使用して、モジュールの名前と Web ゲートウェイのランタイム機能用の .so ファイルの場所を指定し、モジュールをロードします。以下に例を示します。
LoadModule csp_module_sa "/opt/webgateway/bin/CSPa24.so"
-
CSPModulePath 指示文を発行し、Web ゲートウェイのランタイム機能用の .so ファイルを含むディレクトリのフル・パスを指定します。以下に例を示します。
CSPModulePath "/opt/webgateway/bin/"
-
CSPConfigPath 指示文を発行し、Web ゲートウェイの管理機能用の .so ファイルを含むディレクトリのフル・パスを指定します。以下に例を示します。
CSPConfigPath "/opt/webgateway/bin/"
-
Web ゲートウェイ・バイナリを含むディレクトリのアクセス設定を構成します。そのためには、以下のようにそのディレクトリに <Directory> 指示文ブロックを追加します (この例では、最も一般的なインストール場所を想定しています)。
<Directory "/opt/webgateway/bin"> AllowOverride None Options MultiViews FollowSymLinks ExecCGI Require all granted <FilesMatch "\.(log|ini|pid|exe)$"> Require all denied </FilesMatch> </Directory>
-
-
オプション : Web サーバで Web アプリケーションの静的ファイルを処理する場合は、該当する /csp パスを Web サーバからアクセスできるファイル・システムの場所にマップする指示文を追加します。Apache Alias 指示文は、そのための方法の 1 つを提供します。
例えば、アプリケーション /dashboard はリモートの InterSystems IRIS インスタンスによって提供されるが、アプリケーションの静的ファイルは Web サーバ・マシンのディレクトリ /usr/iris/csp/dashboard から提供したい場合は、以下の指示文を追加できます。
Alias /dashboard/ "/usr/iris/csp/dashboard"
-
Web ゲートウェイを呼び出して、InterSystems IRIS アプリケーションへの要求を処理する指示文を発行します。このために、以下の指示文が用意されています。
-
CSPFileTypes。指定した一連のファイル・タイプの要求に対して Web ゲートウェイを呼び出します。(REST API エンドポイントは通常、ファイルではなくパスであるため、REST アプリケーションの要求を呼び出すには、この指示文では不十分です。)
-
CSP On と CSP Off。Web ゲートウェイをすべての要求のハンドラとして有効または無効にします。
<Location> ブロック内でこれらの指示文を発行することで、Web サーバを細かく構成し、InterSystems IRIS Web アプリケーションに対応する相対 URL パスに対してのみ Web ゲートウェイを呼び出すことができます。
以下の場所ブロックは、iris3 という InterSystems IRIS インスタンスの管理ポータル宛ての要求に対してのみ Web ゲートウェイを呼び出します。
<Location "/iris3/csp/sys/"> CSP On </Location>
Note:InterSystems IRIS インスタンスにアクセスせずに、Web ゲートウェイの管理ページにアクセスするには、/csp パスに対して Web ゲートウェイを有効にします。
-
-
httpd.conf ファイルを保存します。
-
Apache を再起動して、構成の変更を有効にします。
インストーラは、Apache Web サーバを自動構成する際にこの手順を使用します。例については、"自動構成例" を参照してください。
次のステップ : Web ゲートウェイのサーバ・アクセス・プロファイルとアプリケーション・アクセス・プロファイルの定義
Apache httpd と InterSystems IRIS サーバ・インスタンス間の Web ゲートウェイ接続の構成を完了するには、以下の手順を完了する必要があります。
-
httpd の Web ゲートウェイの構成内で、インスタンスのサーバ・アクセス・プロファイルを定義します。
-
httpd の Web ゲートウェイの構成内で、目的のアプリケーション・パスの 1 つ以上のアプリケーション・アクセス・プロファイルを定義します。
Windows 用 Apache
Apache HTTP Web サーバ (httpd) は、Apache Software Foundation によって開発および保守されています。Apache Software Foundation は Windows 互換の Apache httpd バイナリを配布していません。自身で httpd をコンパイルするか (https://httpd.apache.org/docs/current/platform/win_compiling.htmlOpens in a new tab を参照)、信頼できるサードパーティ・ソースから httpd バイナリ・パッケージを取得できます (https://httpd.apache.org/docs/current/platform/windows.htmlOpens in a new tab を参照)。詳細なガイダンスは、Apache のドキュメント (https://httpd.apache.org/docs/Opens in a new tab) を参照してください。
このセクションでは、インターシステムズが Apache のネイティブ API を使用して実装する動的モジュール csp_module_sa を使用して、Windows システム上の Apache httpd 内に Web ゲートウェイを導入する方法を説明します。これが Apache の推奨導入オプションで、ほとんどのユース・ケースで有効です。
"Apache の代替オプション" では、Network Service Daemon (NSD) を使用するオプションを含め、Apache で Web ゲートウェイを導入するその他のオプションについて説明しています。
csp_module_sa モジュールの .dll ファイルの取得
Windows では、csp_module_sa モジュールは、2 つのダイナミック・リンク・ライブラリ (.dll) ファイルを使用して Web ゲートウェイを実装します。
-
CSPa24.dll — ランタイム・バイナリ。
-
CSPa24Sys.dll — Web ゲートウェイ管理バイナリ。
Windows システムでは、InterSystems IRIS のインストールにこれらのファイルは含まれません。これらのファイルを取得するには、Web Gateway modules for Apache HTTPD servers インストール・コンポーネントを含むスタンドアロン Web ゲートウェイをダウンロードしてインストールします。
Apache が共有オブジェクト・モジュールを管理できることの確認
Apache 独自の API を使用して Apache 構成に Web ゲートウェイを追加する前に、Apache のビルドに共有オブジェクトを管理するための組み込みのモジュール (mod_so) が含まれていることを確認します。
Windows でこれを確認するには、コマンド行から Apache インストールの \bin\ サブディレクトリに移動し、以下のコマンドを実行します。
httpd.exe -l
このコマンドは、現在の Apache インストールに含まれているモジュールのリストを示します。mod_so がこのリストに含まれていない場合は、Apache のドキュメント (https://httpd.apache.org/docs/2.4/Opens in a new tab) で提供されている手順に従って、このモジュールを含む Apache の新しいビルドをコンパイルします。
Web サーバ構成への Web ゲートウェイ・モジュールの追加
-
Web ゲートウェイ・モジュール・ファイルのファイル・システムの場所を記録しておきます。これらの手順では、例の場所 C:\InterSystems\WebGateway\ を使用しています。この場所を、必ずファイル・システム内の Web ゲートウェイ・モジュール・ファイルの場所に置き換えてください。
-
Apache httpd Web サーバ構成ファイル (httpd.conf) をテキスト・エディタで開きます。このファイルは、Apache のインストール・ディレクトリの /conf サブディレクトリ内にあります。Windows では、httpd の既定のインストール・ディレクトリは通常 C:\Apache24\ です。
-
Web ゲートウェイ・モジュールを追加するファイルの最後に指示文を追加します。これらの指示文では、以下を行います。
-
LoadModule 指示文を使用して、モジュールの名前 (csp_module_sa) と Web ゲートウェイのランタイム機能用の .dll ファイルの場所を指定し、モジュールをロードします。以下に例を示します。
LoadModule csp_module_sa "C:/InterSystems/WebGateway/CSPa24.dll"
-
CSPModulePath 指示文を発行し、Web ゲートウェイのランタイム機能用の .dll ファイルを含むディレクトリのフル・パスを指定します。以下に例を示します。
CSPModulePath "C:/InterSystems/WebGateway/"
-
CSPConfigPath 指示文を発行し、Web ゲートウェイの管理機能用の .dll ファイルを含むディレクトリのフル・パスを指定します。以下に例を示します。
CSPConfigPath "C:/InterSystems/WebGateway/"
-
Web ゲートウェイ・バイナリを含むディレクトリのアクセス設定を構成します。そのためには、以下のようにそのディレクトリに <Directory> 指示文ブロックを追加します (この例では、最も一般的なインストール場所を想定しています)。
<Directory "C:/InterSystems/WebGateway"> AllowOverride None Options MultiViews FollowSymLinks ExecCGI Require all granted <FilesMatch "\.(log|ini|pid|exe)$"> Require all denied </FilesMatch> </Directory>
-
-
オプション : Web サーバで Web アプリケーションの静的ファイルを処理する場合は、該当する /csp パスを Web サーバからアクセスできるファイル・システムの場所にマップする指示文を追加します。Apache Alias 指示文は、そのための方法の 1 つを提供します。
例えば、アプリケーション /dashboard はリモートの InterSystems IRIS インスタンスによって提供されるが、アプリケーションの静的ファイルは Web サーバ・マシンのディレクトリ C:\iris\csp\dashboard から提供したい場合は、以下の指示文を追加できます。
Alias /dashboard/ "C:/iris/csp/dashboard"
-
Web ゲートウェイを呼び出して、InterSystems IRIS アプリケーションへの要求を処理する指示文を発行します。このために、以下の Apache 構成指示文が用意されています。
-
CSPFileTypes。指定した一連のファイル・タイプの要求に対して Web ゲートウェイを呼び出します。
Note:REST API エンドポイントは通常、ファイルではなくパスであるため、REST アプリケーションの要求をルーティングするには、CSPFileTypes 指示文では不十分です。
-
CSP On と CSP Off。Web ゲートウェイをすべての要求のハンドラとして有効または無効にします。
<Location> ブロック内でこれらの指示文を発行することで、Web サーバを細かく構成し、InterSystems IRIS Web アプリケーションに対応する相対 URL パスに対してのみ Web ゲートウェイを呼び出すことができます。(組み込みの InterSystems IRIS Web アプリケーションに関連付けられているパスに関する詳細情報は、"必要なアプリケーション・パスの指定" を参照してください。)
以下の場所ブロックは、iris3 という InterSystems IRIS インスタンスの管理ポータル宛ての要求に対してのみ Web ゲートウェイを呼び出します。
<Location "/iris3/csp/sys/"> CSP On </Location>
Note:InterSystems IRIS インスタンスにアクセスせずに、Web ゲートウェイの管理ページにアクセスするには、/csp パスに対して Web ゲートウェイを有効にします。インスタンスの /<instancePrefix> または /<instancePrefix>/csp パスへ要求をルーティングします。
-
-
httpd.conf ファイルを保存します。
-
Apache が実行されている場合、Apache を再起動して、構成の変更を有効にします。
Apache の起動
Apache がまだ実行されていない場合、コマンド行から Apache インストールの \bin\ サブディレクトリに移動し、以下のコマンドを実行して起動します。
httpd.exe
次のステップ : Web ゲートウェイのサーバ・アクセス・プロファイルとアプリケーション・アクセス・プロファイルの定義
Apache httpd と InterSystems IRIS サーバ・インスタンス間の Web ゲートウェイ接続の構成を完了するには、以下の手順を完了する必要があります。
-
httpd の Web ゲートウェイの構成内で、インスタンスのサーバ・アクセス・プロファイルを定義します。
-
httpd の Web ゲートウェイの構成内で、目的のアプリケーション・パスの 1 つ以上のアプリケーション・アクセス・プロファイルを定義します。
Windows 向けの Microsoft インターネット・インフォメーション・サービス (IIS)
Windows の多くの配布では、Microsoft IIS (https://www.iis.net/Opens in a new tab) が事前にインストールされています。ただし、通常は既定で無効になっています。"IIS の有効化" を参照してください。
このページでは、IIS 独自の API を使用して、Web ゲートウェイをネイティブ・モジュールとして導入する方法について説明します。
Web ゲートウェイ・ネイティブ・モジュールは、2 つのダイナミック・リンク・ライブラリ (.dll) ファイルを使用して Web ゲートウェイを実装します。
-
CSPms.dll — ランタイム・バイナリ
-
CSPmsSys.dll — Web ゲートウェイ管理バイナリ
これが推奨される導入オプションで、ほとんどのユース・ケースで有効です。
"IIS 7 以降の代替オプション (Windows)" では、ISAPI を使用するオプションや Network Service Daemon (NSD) を使用するオプションを含め、IIS で Web ゲートウェイを導入するその他のオプションについて説明しています。
IIS の有効化
IIS を有効にするには、次の手順に従います。
-
[Windows の機能の有効化または無効化] を探すか、[コントロール パネル] を開き、[プログラム]→[プログラムと機能]→[Windows の機能の有効化または無効化] を選択して、[Windows の機能] マネージャを開きます。
-
[インターネット インフォメーション サービス] を選択します。
-
ドキュメント・リンクのリダイレクトを有効にするには、IIS 内で [HTTP リダイレクト] も有効にする必要があります。有効にするには、[インターネット インフォメーション サービス]→[World Wide Web サービス]→[HTTP 共通機能]→[HTTP リダイレクト] が選択されていることを確認します。
-
サポートされている IDE でデバッグ・セッションを有効にするには、IIS 内で [WebSocket プロトコル] も有効にする必要があります。有効にするには、[インターネット インフォメーション サービス]→[World Wide Web サービス]→[アプリケーション開発機能]→[WebSocket プロトコル] が選択されていることを確認します。
-
[OK] をクリックします。
インストーラで、IIS 経由で Web アプリケーションを提供するように新しいまたはアップグレードされた InterSystems IRIS インスタンスを自動構成する場合は、インストールの前に IIS を有効にする必要があります。ただし、IIS の [HTTP リダイレクト] および [WebSocket プロトコル] 機能はいつでも有効にすることができます。
Web ゲートウェイ・コンポーネントに対する許可の設定
既定では、IIS は Web アプリケーションのユーザに対して、Web ドキュメント・ルート・ディレクトリ (通常は C:\Inetpub\wwwroot) 外にあるものへのアクセスを許可しません。以下のユーザ・グループが Web ドキュメント・ルート外のディレクトリにある Web アプリケーション・リソースにアクセスするには、そのディレクトリに対する読み取り、書き込み、実行権限を持っている必要があります。
-
[machine_name]\IIS_IUSRS。IIS ワーカ・プロセスおよび IIS で制御されるアプリケーション (Web ゲートウェイなど) が実行されるユーザ・グループ。
-
[machine_name]\Users
Web ゲートウェイ・ディレクトリ (通常は C:\Inetpub\CSPGateway) および Web アプリケーションが処理する静的ファイルを含むディレクトリに対するこれらの権限を、手動で設定する必要があります。そのためには、以下の操作を実行します。
-
Windows エクスプローラーで、ディレクトリの親ディレクトリに移動します。例えば、C:\Inetpub\CSPGateway ディレクトリを構成する場合は、C:\Inetpub に移動します。
-
ディレクトリ名を右クリックし、[プロパティ] を選択します。
-
[セキュリティ] タブを選択します。
-
[編集] を選択します。
-
[追加] を選択します。
-
[選択するオブジェクト名を入力してください] テキスト・ボックスに以下のように入力します。
[machine_name]\IIS_IUSRS
-
[名前の確認]、[OK] の順に選択します。
-
[グループまたはユーザー名] ウィンドウで [[machine_name]\IIS_IUSRS] を選択してから、以下の操作を実行します。
-
[許可] ウィンドウで [読み取りと実行] および [書き込み] 許可を割り当てます。
-
[適用]、[OK] の順に選択します。
-
[[machine_name]\Users] ユーザ・グループについて、上記の処理を繰り返します。
Web ゲートウェイ構成ファイル (CSP.ini) または Web ゲートウェイ・ログ・ファイル (CSP.log) がファイル・システム内の他の場所に配置されている場合は、IIS_IUSRS グループがこれらのファイルに対する完全な読み取りおよび書き込み権限を持っていることも確認する必要があります。
ネイティブ・モジュールの登録
Web ゲートウェイ・ネイティブ・モジュールを使用する前に、それらを IIS に登録する必要があります。そのためには、以下の操作を実行します。
-
[インターネット インフォメーション サービス (IIS) マネージャ] を開きます。
-
[接続] パネルから localhost 接続を選択します。
-
接続のホーム・ページの [機能ビュー] で、[モジュール] 機能構成項目を開きます (ダブルクリック)。
-
[操作] パネルから [ネイティブ モジュールの構成...] 操作を選択します。
-
[登録] を選択し、[ネイティブ モジュールの登録] ダイアログに以下を入力します。
名前 : CSPms (または類似した名前)
パス : C:\Inetpub\CSPGateway\CSPms.dll
-
[OK] をクリックします。
-
[接続] パネルで localhost 接続のコンテンツを展開して、[サイト]→[Default Web Site] を選択します。
-
Web ゲートウェイ・モジュールが有効になっていることを確認します。
-
[Default Web Site ホーム] ページの [機能ビュー] で、[モジュール] 機能構成項目を開きます (ダブルクリック)。
-
[操作] パネルから [ネイティブ モジュールの構成...] 操作を選択します。
-
[ネイティブ モジュールの構成] ダイアログで、リストに [CSPms] がある場合はそれを選択し、[OK] を選択します。
-
Web アプリケーション・パスの構成
提供する InterSystems IRIS Web アプリケーションごとに、その相対パス (/csp または /irisinstance2) を IIS アプリケーションとして構成します。
IIS アプリケーションを構成すると、Web サーバが物理パスにアクセスするための適切な権限を持っている場合、Web サーバが静的ファイルを処理するために必要なパス・マッピングが作成されます。
構成する各アプリケーション・パスに対して、以下の手順を実行します。
-
[インターネット インフォメーション サービス (IIS) マネージャ] を開きます。
-
[接続] パネルで localhost 接続のコンテンツを展開して、[サイト]→[Default Web Site] を選択します。
-
[操作] パネルから [アプリケーションの表示] を選択します。
-
[操作] パネルから [アプリケーションの追加...] を選択します。
-
[アプリケーションの追加] ダイアログに以下の情報を入力します。
-
エイリアス : アプリケーションの相対ベース URL パス。例えば、インスタンス IRISinstance2 でホストされるアプリケーションの場合は /irisinstance2、アプリケーション /csp/sys とその兄弟アプリケーションの場合は csp です。
-
物理パス : アプリケーションに関連付けられている静的ファイルを含むディレクトリ。IIS で、現在構成中のアプリケーション・パスの下位パスを持つアプリケーションの、異なるディレクトリからの静的ファイルを処理する場合は、子ディレクトリの IIS 仮想ディレクトリを定義します。
-
-
[OK] をクリックします。
-
IIS の構成が完了したら、IIS を再起動して構成の変更を有効にします。
InterSystems IRIS インスタンスにアクセスせずに、Web ゲートウェイの管理ページにアクセスするには、/csp パスに対して Web ゲートウェイを有効にします。
代替オプションに基づく Web ゲートウェイ・ソリューションを使用している場合は、/csp アプリケーションの下に /bin というアプリケーションをセットアップします。Web ゲートウェイ・バイナリを保持している物理ディレクトリにこれをマップします。ほとんどの場合、これはアプリケーション・パス /csp/bin と物理パス C:\Inetpub\CSPGateway 間のマッピングです。
仮想ディレクトリの定義
IIS の仮想ディレクトリを使用すると、アプリケーションに指定されたファイル・システムの場所の外にあるファイル・システムからの静的コンテンツを処理できます。例えば、domain.com/images でイメージをホストする静的 Web サイトの管理者は、Web サイトのほとんどのコンテンツを C:\Inetpub\wwwroot に格納できますが、仮想ディレクトリ images をその物理パスにマッピングすることで、イメージを C:\siteimg に格納できます。
1 つの親パス・ディレクトリ (/csp など) 内に、InterSystems IRIS アプリケーションごとに異なる静的ファイルのストレージ場所を保持する場合は、IIS の仮想ディレクトリを使用できます。
IIS の仮想ディレクトリを構成するには、次の手順に従います。
-
[インターネット インフォメーション サービス (IIS) マネージャ] 内の [接続] パネルで、下位の仮想ディレクトリを構成する IIS アプリケーションを見つけて選択します。
-
[操作] パネルから [仮想ディレクトリの表示] を選択します。
-
[操作] パネルから [仮想ディレクトリの追加] を選択します。
-
[仮想ディレクトリの追加] ダイアログに以下の情報を入力します。
-
エイリアス : アプリケーションの URL パスの下位部分 (例 : パス /csp/sys の sys)。
-
物理パス : このパスの静的ファイルの代替の場所。
-
-
[OK] をクリックします。
-
IIS の構成が完了したら、IIS を再起動して構成の変更を有効にします。
アプリケーション要求のハンドラ・マッピングの設定
構成した IIS アプリケーションごとに、ハンドラ・マッピングを作成して、アプリケーション・パスに送信される一部 (またはすべて) の要求のハンドラとして Web ゲートウェイを呼び出すように IIS に指示します。
アプリケーション・パスに送信されるすべての要求のハンドラとして Web ゲートウェイを呼び出すには、以下の手順に従って要求パス * (ワイルドカード) のハンドラ・マッピングを作成します。
特定のファイル・タイプに対してのみ Web ゲートウェイを呼び出すには、ファイル・タイプごとに、以下の手順に従って *.xxx (xxx はファイル拡張子) を要求パスとして指定します。インターシステムズ固有のファイル・タイプを処理するには、*.csp、*.cls、*.zen、および *.cxw の要求パスのハンドラ・マッピングを作成します。アプリケーションで処理する静的ファイル・タイプのハンドラ・マッピングも作成する必要があります。(REST API エンドポイントは通常、ファイルではなくパスであるため、REST アプリケーションの要求を呼び出すには、このファイル・タイプ固有のアプローチでは不十分です。)
以下の手順を実行して、IIS アプリケーションのハンドラ・マッピングを作成します。
-
[インターネット インフォメーション サービス (IIS) マネージャ] を開きます。
-
[接続] パネルで localhost 接続のコンテンツを展開し、[サイト]→[既定の Web サイト] 内のリストから [アプリケーション] の名前を選択します。
-
接続のホーム・ページの [機能ビュー] で、[ハンドラー マッピング] 機能構成項目を開きます (ダブルクリック)。
-
[操作] パネルで、[モジュール マップの追加..] を選択します。
Note:Web ゲートウェイをアプリケーション・パスのすべての要求のハンドラとして設定するために、[ワイルドカードスクリプトマップの追加...] 操作を使用しないでください。これを試みると、エラーが発生します。代わりに、ワイルドカード (*) 文字のモジュール・マッピングを追加します。
-
[モジュール マップの追加] ダイアログで以下を指定します。
-
要求パス — Web ゲートウェイが処理する一連の要求を指定する式を指定します。(有効な式の例は、このセクションの冒頭を参照してください。)
-
モジュール — ドロップダウン・メニューから、Web ゲートウェイ・モジュールに指定した名前を選択します (CSPms)。
-
名前 — このマッピングにわかりやすい名前を指定します (WebGateway_* など)。
-
-
[要求の制限] を選択し、[要求のマップ先が次の場合のみハンドラーを呼び出す] の横にあるボックスにチェックが付けられていない (選択されていない) ことを確認します。この操作により、[ハンドラー マッピング] テーブルに示すように、[パスの種類] の値が [指定なし] に設定されます。
-
[OK] を選択して [モジュール マップの追加] ダイアログに戻り、もう一度、[OK] を選択します。
-
上記のプロセスを繰り返して、IIS アプリケーションに必要なすべてのハンドラ・マッピングを追加します。
-
IIS の構成が完了したら、IIS を再起動して構成の変更を有効にします。
/bin を含む URLの有効化
既定では、IIS はディレクトリ /bin を含む要求パスからはリソースを提供しません。Web ゲートウェイ管理ページを提供するには、このフィルタを無効にする必要があります。
インストーラが Web ゲートウェイを自動構成した場合、この手順は自動的に実行されています。Web ゲートウェイを手動でインストールする場合は、この構成を手動で実行する必要があります。
具体的には、以下の手順によって、IIS で Web ゲートウェイ管理ページを提供できるようにします。
-
テキスト・エディタで、applicationHost.config ファイルを開きます。このファイルは通常、C:\Windows\System32\Inetsrv\Config ディレクトリにあります。お使いのシステムで、このファイルの場所を見つけるには、以下を実行します。
-
[接続] パネルで、localhost 接続またはその接続内の任意のサイト項目のホーム・ページから、[構成エディター] を選択 (ダブルクリック) します。
-
[操作] パネルから [構成の検索...] を選択します。
-
[階層表示] で、[ApplicationHost.config] (またはその子項目) を選択します。この操作によって、[構成検索] ダイアログに ApplicationHost.config ファイルの場所が表示されます。
-
-
<configuration> ブロックの最後に (ただし、ブロック内) に、以下の <Location> タグを追加します。
<location path="localhost/csp/bin/Systems/Module.cxw"> <system.webServer> <security> <requestFiltering> <hiddenSegments> <remove segment="bin" /> </hiddenSegments> </requestFiltering> </security> </system.webServer> </location>
-
ファイルを保存します。
-
IIS の構成が完了したら、IIS を再起動して構成の変更を有効にします。
リモート Web サーバ接続のランチャーの構成
InterSystems IRIS ランチャーが InterSystems IRIS インスタンスの組み込みの Web の有効な URL を構成できるようにするには、InterSystems IRIS サーバ・マネージャでインスタンスの接続の詳細を指定する必要があります。これらの接続の詳細は、Web サーバ構成と一致する必要があります。"システム管理ガイド" の "リモート・サーバ接続の定義" を参照してください。
SOAP フォルトの詳細を返すための IIS の構成
エラーが発生している InterSystems IRIS Web サービスは、関連する SOAP フォルトの詳細を含めずに HTTP 500 エラーを返すことがあります。既定では、IIS は広範なエラー情報をローカル・クライアントに対してのみ返します。 しかし、構成ファイル web.config 内の <httpErrors> 要素でこの動作を変更できます。変更するには、以下のセクションを追加して、詳細なエラー情報をすべてのクライアントに配信するように IIS に指示します。
<configuration>
<system.webServer>
<httpErrors errorMode="Detailed" />
</system.webServer>
</configuration>
ホスト環境に関する機密情報がクライアントに公開されることがあるため、この方法を使用する場合は注意が必要です。 errorMode="Detailed" の使用に関するセキュリティ上の問題を回避する代わりの方法は、existingResponse="PassThrough" 指示文を使用することです。
<configuration>
<system.webServer>
<httpErrors existingResponse="PassThrough" />
</system.webServer>
</configuration>
構成の変更後に、IIS を再起動します。
これらの変更は、IIS web.config ファイルに対して手動で行うことができます。または、より適切で、エラーの発生が少ない方法を選択するには、IIS マネージャに組み込まれている構成エディタ を使用します。
-
IIS マネージャの左側の [接続] パネルから、Web サービスに対応するパスを選択します。 例 :[既定の Web サイト] の後に csp を選択。
-
中央のパネル下部の [管理] という見出しの下で、[構成エディタ] をダブルクリックします。
-
[セクション] のラベルが付いた上部の [構成エディタ] ドロップダウンで、system.webServer を展開し、[httpErrors] をクリックします。
-
[existingResponse] の横にある値をクリックし、ドロップダウンを使用してオプションを表示します。 [PassThrough] を選択します。
-
右側の [アクション] ペインで、[適用] をクリックします。
-
IIS の構成が完了したら、IIS を再起動して構成の変更を有効にします。
IIS でのエラー処理の詳細は、以下を参照してください。
https://docs.microsoft.com/ja-jp/iis/configuration/system.webServer/httpErrors/Opens in a new tab
IIS の再起動
このセクションでは、各種コントロール・パネル経由で IIS を再起動したときに何が起こるかについて説明します。
アクティブな IIS インストールに対する構成変更の大半はリアルタイムで行うことができます。しかし、[インターネット インフォメーション サービス (IIS) マネージャ] コントロール・パネルには停止、開始、および再起動オプションが用意されています。これらのオプションは Web サーバ構成の更新には便利です。しかし、Web ゲートウェイ・インストールは再初期化されません。
Web ゲートウェイ・インストールに変更を加えた場合は、以下のいずれかの方法で IIS を再起動します。
-
Windows サービス・マネージャを開いて、World Wide Web Publishing サービスを再起動します。
-
コマンド行から以下のコマンドを実行して、IIS を停止します。
sc stop W3SVC
Web サーバが停止したら、以下のコマンドを実行してこの Web サーバを再起動します。
sc start W3SVC
次のステップ : Web ゲートウェイのサーバ・アクセス・プロファイルとアプリケーション・アクセス・プロファイルの定義
IIS と InterSystems IRIS サーバ・インスタンス間の Web ゲートウェイ接続の構成を完了するには、以下の手順を完了する必要があります。
-
IIS Web サーバの Web ゲートウェイの構成内で、インスタンスのサーバ・アクセス・プロファイルを定義します。
-
IIS Web サーバの Web ゲートウェイの構成内で、目的のアプリケーション・パスの 1 つ以上のアプリケーション・アクセス・プロファイルを定義します。
トラブルシューティング
このセクションでは、IIS で使用するためにサードパーティ・モジュール (ネイティブ・モジュールおよび ISAPI モジュールの両方) を構成しているときによく発生する問題について説明します。
最もよく発生する問題は、再構成後、IIS への要求が失敗し、以下のエラーが表示されるというものです。
Service Unavailable
HTTP Error 503. The service is unavailable.
これは通常、既定のアプリケーション・プールが終了していることを示します。
-
[インターネット インフォメーション サービス (IIS) マネージャ] ウィンドウを開きます。
-
左側のパネルで、最上位レベルを展開します。[アプリケーション プール] セクションが表示されます。
[MACHINE_NAME] ([machine_name]\[user_name])
アプリケーション・プール
-
既定のアプリケーション・プール (DefaultAppPool)、またはサーバで使用が構成されているアプリケーション・プールのステータスが [開始] になっていることを確認します。
-
必要に応じて、右側のパネルのオプションを使用して、アプリケーション・プールを再開します。
-
それでも問題が解決されない場合は、メインの Windows イベント・ログ ([アプリケーション] セクション内) を見て、ヒントを探してください。特に、次のエラー・メッセージを確認してください。
Failed to find the RegisterModule entrypoint in the module DLL C:\Inetpub\CSPGateway\CSPms.dll.The data is the error.
例えば、これは、使用しているバージョンの Web ゲートウェイ DLL が、このネイティブ・モジュール・インタフェースを実装していないことを示します。インターシステムズから最新の DLL を入手するか、または従来の ISAPI インタフェースで動作するように Web ゲートウェイを構成します。
すべてのソフトウェアと同様、一時的な問題が再起動により解決されることはよくあります。IIS を完全に再起動するには、メインの Windows サービス・コントロール・パネルから World Wide Web Publishing サービスを再起動します。
ファイル拡張子をマップするのにワイルドカードスクリプトマップの追加ユーティリティを使用しないでください。使用すると、「このハンドラーに対して指定されたモジュールが、モジュールの一覧にありません。スクリプト マップ ハンドラー マッピングを追加する場合は、モジュールの一覧に IsapiModule または CgiModule が存在している必要があります。」というエラーが発生する可能性があります。 代わりに、モジュールマップの追加を使用し、ワイルドカードを指定してファイル拡張子をマップしてください。
/bin を含む URL が機能しない場合には、/bin を含む URLの有効化の手動手順を参照してください。
UNIX®/Linux/macOS 向けの Nginx
概要
ここでは、UNIX®、Linux、または macOS 上の InterSystems Web ゲートウェイで使用するための、Nginx Web サーバの構築および構成方法について説明します。
Nginx はオープン・ソース製品で、ソース・コードは http://nginx.org/Opens in a new tab から無料でダウンロードできます。
Linux 用の一部のビルド済みキットを入手できますが、通常、これは最新の Nginx ビルドよりもいくつか前のバージョンをビルドしたものです。ただし、拡張子を Nginx コアにコンパイルする必要があるため、CSP のサポートを含めるには、Web サーバをソース・コードからローカルにビルドすることが必要です。
このページの手順の後、Web ゲートウェイ管理ページを使用して、さらに Web ゲートウェイを構成できます。
想定
ここでは、以下のように想定しています。
-
CSP/Web ゲートウェイの Web サーバ・コンポーネントは /opt/webgateway/bin/ にインストールされている
-
InterSystems IRIS はローカルにインストールされている場合は、/opt/iris/ に配置されている
-
Web サーバは /opt/nginx/ の下にインストールされている
システムのレイアウトが異なる場合は、必要に応じて、構成指示文を修正してください。
インストール
以下の Web ゲートウェイのコンポーネントおよび CSP 静的ファイルをインストールします。
-
Web ゲートウェイ Network Service Daemon (NSD)
-
CSPnsd
このバイナリの既定の場所は /opt/webgateway/bin/ です。
-
-
ハイパーイベントのコンポーネント
CSPBroker.js
CSPxmlhttp.js
これらのファイルの既定の場所は /opt/iris/csp/broker です。
これらのファイルが静的コンポーネントとして Web サーバによって直接処理される場合は、/opt/nginx/html/csp/broker にコピーしてください。
-
管理ポータルで使用するその他の静的リソース
管理ポータルでは、(イメージ・ファイルなど) いくつかの静的な Web リソースが必要になります。 これらのファイルの既定の場所は /opt/iris/csp/sys です。
これらのファイルが静的コンポーネントとして Web サーバによって直接処理される場合は、/opt/nginx/html/csp/sys にコピーしてください。
CSP のための Nginx Web サーバの構築
Web ゲートウェイ機能のほとんどは、NSD (CSPnsd) によって提供されます。 CSP アクセスのために、小さなコンパイル済みモジュール ngx_http_csp_module.c を介して NSD と通信するように、Nginx を構築および構成することができます。便宜のため、すべての Web ゲートウェイ・インストールにはこのソース・ファイルが含まれています。
ここで説明する構築手順は、UNIX® システム下で Nginx を構築するための公式ドキュメントに基づいています。
http://nginx.org/en/docs/configure.htmlOpens in a new tab
Nginx のドキュメントには、以下のサードパーティのアドオンが必要であると記載されています。
-
PCRE
-
OpenSSL (SSL/TLS の場合)
-
Zlib
使用する OpenSSL ツールキットは、ご使用の InterSystems IRIS のバージョンに適合している必要があります。"自身の InterSystems IRIS のインスタンスでサポートされている TLS のバージョン" を参照してください。
ただし、最終インストールで、上記のコンポーネントによって提供される機能を必要としない場合は、これらのコンポーネントを使用しなくても十分に機能するサーバを作成することは可能です。
上記のオプションのモジュールすべてを含む、Nginx を構築するための一般的な構成スクリプトは、以下のとおりです。
./configure --prefix=/opt/nginx --with-http_ssl_module
これにより、既定の Nginx ビルドが /opt/nginx 下にインストールされます。
構築プロセスを以下のように変更して、オプションのモジュールを除外することもできます。
-
OpenSSL - SSL/TLS 機能を削除します。
指示文の削除:--with-http_ssl_module
-
Zlib - GZIP 機能を削除します。
指示文の追加:--without-http_gzip_module
-
PCRE - HTTP 書き換え機能を削除します。
指示文の追加:--without-http_rewrite_module
CSP のための Nginx の構築手順
-
ソース・ディストリビューションを任意の場所に解凍します。 以下に例を示します。
/opt/
解凍後、/opt/ を指定すると、ソース・コード・ディストリビューションは以下に配置されます。
/opt/nginx-n.n.n/
-
CSP 拡張子に以下のディレクトリを作成します。
/opt/nginx-n.n.n/csp/
-
モジュールのソース・コード (ngx_http_csp_module.c) を、上記で作成したディレクトリにコピーします。
-
同じディレクトリ内に、config という名前の構成ファイルを作成します。 このファイルには、以下の行が含まれる必要があります。
ngx_addon_name=ngx_http_csp_module HTTP_MODULES="$HTTP_MODULES ngx_http_csp_module" NGX_ADDON_SRCS="$NGX_ADDON_SRCS $ngx_addon_dir/ngx_http_csp_module.c" CORE_LIBS="$CORE_LIBS -ldl"
-
/opt/nginx-n.n.n/ で作業し、Nginx 構築環境を構成します。
./configure --prefix=/opt/nginx --with-http_ssl_module --add-module=/opt/nginx-n.n.n/csp
または、OpenSSL、ZLIB、および PCRE により提供されるオプションの機能を使用しない場合は、以下のようになります。
./configure --prefix=/opt/nginx --without-http_rewrite_module --without-http_gzip_module --add-module=/opt/nginx-n.n.n/csp
最後の行に、CSP モジュールをインクルードする指示が含まれることに注意してください。
-
Nginx のコンパイル:
make
-
Nginx のインストール:
make install
成功した場合、以下のディレクトリに完全なサーバ・インストールが表示されます。
/opt/nginx/
Nginx での NSD の使用
InterSystems IRIS アプリケーションが処理する必要のある要求を認識し、それらの要求を NSD に渡すように、Web サーバを構成する必要があります。
そのためには、/opt/nginx/conf にある Web サーバ構成ファイル (nginx.conf) を編集します。
ここでは、CSP 拡張モジュールが Web サーバの構成のために提供するサーバ構成指示文について説明します。location ブロックのコンテキスト内でこれらの指示文を発行すると、その指示文は指定されたパスのトラフィックに適用されます。
(必須。)NSD が待ち受けるアドレス (hostname と port) を指定します。
特定のパスの NSD アドレスを指定しない場合、NSD は既定で 127.0.0.1:7038 のアドレスで待ち受けます。
すべての要求に対し、Web ゲートウェイを介した CSP サーバへのルーティングを有効または無効にします。
特定のパスに適用する CSP 指示文を発行しない場合、そのパスに送信された要求は CSP off によりルーティングされず、Web サーバは Web ゲートウェイを介してそのパスに送信される要求をルーティングしません。
特定のファイル・タイプ (filetype1、filetype2 など) の要求を Web ゲートウェイを介して CSP サーバにルーティングできるようにします。
例えば、.csp または .cls ファイルを要求している場合 (そのような要求に限り)、Web ゲートウェイがその要求を /demo/app パスに送信するようにするには、以下の指示文ブロックを発行します。
location /demo/app { CSPFileTypes csp cls; }
指示文 CSPFileTypes * を発行することにより、すべてのファイル・タイプの要求のルーティングが有効になります。
この指示文は、ファイルを要求しない URL の要求はルーティングしません。そのため、この指示文は、エンドポイントでパスを指定することが多いほとんどの API には不適切です。
HTTP 応答のヘッダの最大サイズを指定します。応答ヘッダがこのサイズを超えると、Web クライアントはエラーを受け取ります。
既定では、CSP 拡張モジュールは指示文 CSPNSD_response_headers_maxsize 8k を適用します。
Web クライアントからの要求受信時の、NSD への接続タイムアウトを指定します。
既定では、CSP 拡張モジュールは指示文 CSPNSD_connect_timeout 300s を適用します。
単一の送信操作要求 (POST、PUT など) のタイムアウトを指定します。タイムアウトは連続する送信操作間でのみ適用されます。単一の送信が開始されてから完了までの間に適用されるものではありません。
既定では、CSP 拡張モジュールは指示文 CSP_send_timeout 300s を適用します。
単一の読み取り操作 (GET など) の応答が返る際のタイムアウトを指定します。タイムアウトは連続する読み取り操作間でのみ適用されます。単一の読み取りが開始されてから完了までの間に適用されるものではありません。
既定では、CSP 拡張モジュールは指示文 CSP_read_timeout 300s を適用します。
例 : 特定のパスでのすべてのトラフィックに対する CSP ルーティングを有効にする
適切な server 構成ブロック内に以下のセクションを配置し、/csp パスに送信されるすべてのトラフィックを Web ゲートウェイにルーティングします。
location /csp {
CSP On;
CSPNSD_pass localhost:7038;
}
例 : InterSystems IRIS のファイル・タイプに対する要求を Web ゲートウェイにルーティングする
適切な server 構成ブロック内に以下のセクションを配置し、/csp パスに送信される InterSystems IRIS のファイル・タイプ (.csp、.cls、.zen、および .cxw)、および管理ポータル・インタフェースの静的要素を処理するのに必要なファイル・タイプに対する要求の CSP ルーティングを有効にします。
location /csp {
CSPFileTypes csp cls zen cxw .jpg .gif .png .svg .css .js;
CSPNSD_pass localhost:7038;
}
IDE の使用に必要な追加の構成
InterSystems ObjectScript 拡張機能を含む VS CodeOpens in a new tab (または /api/atelier Web アプリケーションを使用する IDE) を ObjectScript IDE として使用するには、Nginx 構成に以下の追加の変更を行う必要があります。
-
/api/atelier Web アプリケーションは、アンダースコアを含む HTTP ヘッダを使用します。既定では、Nginx の underscores_in_headers 指示文が、これらのヘッダを通知なしで削除するよう Nginx に指示します。これらを含めるように Nginx サーバを構成する必要があります。http://nginx.org/en/docs/http/ngx_http_core_module.html#underscores_in_headersOpens in a new tab を参照してください。
-
デバッガなどの機能には、WebSocket 接続が必要です。既定では、Nginx は WebSocket をサポートするように構成されていません。WebSocket の有効化に関する情報は、Nginx のドキュメント (http://nginx.org/en/docs/http/websocket.htmlOpens in a new tab) を参照してください。
Nginx と NSD の起動および停止
Nginx を起動する方法は、以下のとおりです。
/opt/nginx/sbin/nginx
Nginx を停止する方法は、以下のとおりです。
/opt/nginx/sbin/nginx –s stop
NSD の操作方法については、"NSD の操作" を参照してください。
非推奨 : ユニバーサル・モジュールを使用する Nginx の構築
Nginx でのユニバーサル・モジュールの使用は、安定性に問題があるため推奨されていません。NSD を使用して Nginx に接続する Web ゲートウェイの導入では、WebSockets を含め、すべての機能を完全にサポートしています。
現在、Nginx でユニバーサル・モジュールを使用している場合は、Web ゲートウェイを最新バージョンにアップグレードし、NSD と連携するように Nginx サーバを再構築することをお勧めします。サーバ構成ファイルを編集する際は、サーバ構成から CSPModulePath 指示文を必ず削除してください。
以下の手順は、既存のインストールのリファレンスとしてのみ機能します。
動的にリンクされたユニバーサル・モジュール CSPx.so (実行時) と CSPxSys.so (Web ゲートウェイ・システム管理) と連携するように Nginx を構築できます。ユニバーサル・モジュールと連携するように Nginx を構築および構成する手順は、以下のように NSD ベースの導入とは異なります。
-
手順 3 で、モジュールのソース・コードとして、ngx_http_csp_module.c ではなく ngx_http_csp_module_sa.c、cspapi.h、および ngx_http_csp_common.h を指定のディレクトリにコピーします。
-
手順 4 で、CSP の構成ファイル (/opt/nginx-n.n.n/csp/config) は、以下のようになります。
ngx_addon_name=ngx_http_csp_module_sa HTTP_MODULES="$HTTP_MODULES ngx_http_csp_module_sa" NGX_ADDON_SRCS="$NGX_ADDON_SRCS $ngx_addon_dir/ngx_http_csp_module_sa.c"
-
CSPModulePath 指示文を http 構成ブロックから追加して、ユニバーサル・ゲートウェイ・モジュールへのパスを指定します。
CSPModulePath /opt/webgateway/bin;
-
以下の指示文はサポートされていません。
-
CSPNSD_pass
-
CSPNSD_response_headers_maxsize
-
CSPNSD_connect_timeout
-
CSPNSD_send_timeout
-
CSPNSD_read_timeout
-
-
以下の指示文はサポートされています。
-
CSP
-
CSPFileTypes
-
Windows 向け Nginx
概要
ここでは、Windows 上の InterSystems Web ゲートウェイで使用するための、Nginx Web サーバの構築および構成方法について説明します。
Nginx はオープン・ソース製品です。ソース・コードは http://nginx.org/Opens in a new tab から無料でダウンロードできます。
Windows 用の一部のビルド済みキットを入手できますが、通常、これは最新の Nginx ビルドよりもいくつか前のバージョンをビルドしたものです。ただし、拡張子を Nginx コアにコンパイルする必要があるため、CSP のサポートを含めるには、Web サーバをソース・コードからローカルにビルドすることが必要です。
このページの手順の後、Web ゲートウェイ管理ページを使用して、さらに Web ゲートウェイを構成できます。
想定
ここでは、以下のように想定しています。
-
CSP/Web ゲートウェイ・コンポーネントは install-dir\csp\ にインストールされている。
-
Web サーバは C:\nginx\ にインストールされている。
システムのレイアウトが異なる場合は、必要に応じて、構成指示文を修正してください。
インストール
以下の Web ゲートウェイのコンポーネントおよび CSP 静的ファイルをインストールします。
-
Web ゲートウェイ Network Service Daemon (NSD)
-
CSPnsd.exe (メイン・バイナリ)
-
CSPnsdSv.exe (Windows サービス)
これらのファイルの既定の場所は install-dir\bin です。
-
-
ハイパーイベントのコンポーネント
-
CSPBroker.js
-
CSPxmlhttp.js
これらのファイルの既定の場所は install-dir\csp\broker です。
これらのファイルが静的コンポーネントとして Web サーバによって直接処理される場合は、C:\nginx\html\csp\broker にコピーしてください。
-
-
管理ポータルで使用するその他の静的リソース
管理ポータルでは、(イメージ・ファイルなど) いくつかの静的な Web リソースが必要になります。 これらのファイルの既定の場所は install-dir\csp\sys です。
これらのファイルが Web サーバによって直接処理される場合は、C:\nginx\html\csp\sys にコピーしてください。
CSP のための Nginx Web サーバの構築
Web ゲートウェイ機能のほとんどは、NSD (CSPnsd[Sv].exe) によって提供されます。CSP アクセスのために、小さなコンパイル済みモジュール ngx_http_csp_module.c を介して NSD と通信するように、Nginx を構築および構成することができます。便宜のため、すべての Web ゲートウェイ・インストールにはこのソース・ファイルが含まれています。
Nginx 構築の前提条件 :
-
Microsoft Visual Studio (バージョン 10 以上) : http://www.microsoft.comOpens in a new tab
-
MSYS2 (MinGW より) : https://www.msys2.org/Opens in a new tab
-
Perl (ActivePerl を推奨) : https://www.activestate.com/products/perl/Opens in a new tab
-
Mercurial ソース・コントロール・クライアント : https://www.mercurial-scm.org/Opens in a new tab
ここで説明する構築手順は、Windows 下で Nginx を構築するための公式ドキュメントに基づいています。
http://nginx.org/en/docs/howto_build_on_win32.htmlOpens in a new tab
Nginx のドキュメントには、以下のサードパーティのアドオンが必要であると記載されています。
-
OpenSSL (SSL/TLS の場合) : https://www.openssl.org/Opens in a new tab
使用する OpenSSL ツールキットは、ご使用の InterSystems IRIS のバージョンに適合している必要があります。"自身の InterSystems IRIS のインスタンスでサポートされている TLS のバージョン" を参照してください。
ただし、最終インストールで、上記のコンポーネントによって提供される機能を必要としない場合は、これらのコンポーネントを使用しなくても十分に機能するサーバを作成することは可能です。
上記のオプションのモジュールすべてを含む、Nginx を構築するための既定の構成スクリプトは、以下のとおりです。
auto/configure \
--with-cc=cl \
--with-debug \
--prefix= \
--conf-path=conf/nginx.conf \
--pid-path=logs/nginx.pid \
--http-log-path=logs/access.log \
--error-log-path=logs/error.log \
--sbin-path=nginx.exe \
--http-client-body-temp-path=temp/client_body_temp \
--http-proxy-temp-path=temp/proxy_temp \
--http-fastcgi-temp-path=temp/fastcgi_temp \
--http-scgi-temp-path=temp/scgi_temp \
--http-uwsgi-temp-path=temp/uwsgi_temp \
--with-cc-opt=-DFD_SETSIZE=1024 \
--with-pcre=objs/lib/pcre-8.44 \
--with-zlib=objs/lib/zlib-1.2.12 \
--with-openssl=objs/lib/openssl-1.1.1k \
--with-openssl-opt=no-asm \
--with-http_ssl_module
構築プロセスを以下のように変更して、オプションのモジュールを除外することもできます。
-
OpenSSL - SSL/TLS 機能を削除します。
指示文の削除:--with-http_ssl_module
-
Zlib - GZIP 機能を削除します。
指示文の追加:--without-http_gzip_module
-
PCRE - HTTP 書き換え機能を削除します。
指示文の追加:--without-http_rewrite_module
CSP のための Nginx の構築手順
-
MSYS2 シェルで作業を開始し、Nginx のドキュメントで推奨される作業ディレクトリ構造を作成します。
/opt/
-
/opt で作業して、以下のコマンドを使用して Nginx ソース・コードをチェックアウトします。
hg clone http://hg.nginx.org/nginx
これにより、Nginx ソース・コードが /opt/nginx/ の下に配置されます。
-
CSP 拡張子に以下のディレクトリを作成します。
mkdir /opt/nginx/objs/lib/csp/
-
モジュールのソース・コード (ngx_http_csp_module.c) を、前の手順で作成したディレクトリにコピーします。
-
同じディレクトリ内に、config という名前の構成ファイルを作成します。 このファイルには、以下の行が含まれる必要があります。
ngx_addon_name=ngx_http_csp_module HTTP_MODULES="$HTTP_MODULES ngx_http_csp_module" NGX_ADDON_SRCS="$NGX_ADDON_SRCS $ngx_addon_dir/ngx_http_csp_module.c"
-
/opt/nginx/ で作業し、Nginx 構築環境を構成します。
auto/configure --with-cc=cl --builddir=objs --prefix= --conf-path=conf/nginx.conf --pid-path=logs/nginx.pid --http-log-path=logs/access.log --error-log-path=logs/error.log --sbin-path=nginx.exe --http-client-body-temp-path=temp/client_body_temp --http-proxy-temp-path=temp/proxy_temp --http-fastcgi-temp-path=temp/fastcgi_temp --with-cc-opt=-DFD_SETSIZE=1024 --without-http_rewrite_module --without-http_gzip_module --with-select_module --with-ipv6 --add-module=objs/lib/csp
最後の行に、CSP モジュールをインクルードする指示が含まれることに注意してください。
-
Nginx をコンパイルします。これは、現在の MSYS2 シェルまたは Visual Studio 開発者コマンド・プロンプトで実行できます。
MSYS2 シェルを使用するには、目的の Visual Studio 構築環境に対応する vcvarsall.bat スクリプトを見つけて、Nginx をコンパイルします。
cd /c/path/to/vcvarsall vcvarsall.bat cd - nmake -f objs/Makefile
vcvarsall.bat を探す場所がわからない場合は、Visual Studio 開発者コマンド・プロンプトを開くと、構築環境が設定されます。まず、MSYS2 パスを現在の MSYS2 シェル内の同等の Windows パスに変換します。
cygpath –m $(pwd)
次に、目的の構築環境のために Visual Studio コマンド・プロンプトを開き、その Windows パスに移動します。Nginx をコンパイルします。
nmake -f objs/Makefile
成功した場合、/opt/nginx/objs/ にサーバ (nginx.exe) が表示されます。
-
Nginx のインストール : これを実行する最も簡単な方法は、まず Windows 用の Nginx の事前構築済みバージョンをダウンロードおよびインストールして、ディレクトリ構造 (通常 C:\nginx\) を取得し、次にそのインストール内の nginx.exe ファイルを、ローカルで作成したものと置き換えることです。
動作可能な Nginx インストールの通常のディレクトリ構造は、以下のとおりです。
Directory of C:\nginx 03/07/2017 09:09 <DIR> . 03/07/2017 09:09 <DIR> .. 26/06/2017 10:14 <DIR> conf 26/06/2017 10:14 <DIR> contrib 10/05/2018 12:53 <DIR> csp 26/06/2017 10:14 <DIR> docs 26/06/2017 10:14 <DIR> html 10/05/2018 15:57 <DIR> logs 04/07/2017 15:52 715,264 nginx.exe 26/06/2017 10:17 <DIR> scgi_temp 26/06/2017 10:17 <DIR> temp 26/06/2017 10:17 <DIR> uwsgi_temp
このディレクトリの nginx.exe のコピーを、構築手順で作成したバージョンで置き換えます。
NSD を呼び出すように Nginx を構成
インターシステムズのファイル・システムの要求を認識し、これらの要求 (および InterSystems IRIS アプリケーションが処理するその他の静的ファイルの要求) を処理のため NSD に渡すよう、Web サーバを構成する必要があります。
そのためには、C:\nginx\conf にある Web サーバ構成ファイル (nginx.conf) を編集します。
ここでは、CSP 拡張モジュールが Web サーバの構成のために提供するサーバ構成指示文について説明します。location ブロックのコンテキスト内でこれらの指示文を発行すると、その指示文は指定されたパスのトラフィックに適用されます。
(必須。)NSD が待ち受けるアドレス (hostname と port) を指定します。
特定のパスの NSD アドレスを指定しない場合、NSD は既定で 127.0.0.1:7038 のアドレスで待ち受けます。
すべての要求に対し、Web ゲートウェイを介した CSP サーバへのルーティングを有効または無効にします。
特定のパスに適用する CSP 指示文を発行しない場合、そのパスに送信された要求は CSP off によりルーティングされず、Web サーバは Web ゲートウェイを介してそのパスに送信される要求をルーティングしません。
特定のファイル・タイプ (filetype1、filetype2 など) の要求を Web ゲートウェイを介して CSP サーバにルーティングできるようにします。
例えば、.csp または .cls ファイルを要求している場合 (そのような要求に限り)、Web ゲートウェイがその要求を /demo/app パスに送信するようにするには、以下の指示文ブロックを発行します。
location /demo/app { CSPFileTypes csp cls; }
指示文 CSPFileTypes * を発行することにより、すべてのファイル・タイプの要求のルーティングが有効になります。ただし、REST API は、ファイルを指定しない (したがって、ファイル・タイプを指定しない) エンドポイントでの要求の受信をサポートする必要があります。このようなアプリケーションの場合、ファイル・タイプに基づいて要求に対して Web ゲートウェイを呼び出すことができないため、Web ゲートウェイをパスのすべての要求のハンドラとして使用できるようにする必要があります (CSP on; を使用)。
HTTP 応答のヘッダの最大サイズを指定します。応答ヘッダがこのサイズを超えると、Web クライアントはエラーを受け取ります。
既定では、CSP 拡張モジュールは指示文 CSPNSD_response_headers_maxsize 8k を適用します。
Web クライアントからの要求受信時の、NSD への接続タイムアウトを指定します。
既定では、CSP 拡張モジュールは指示文 CSPNSD_connect_timeout 300s を適用します。
単一の送信操作要求 (POST、PUT など) のタイムアウトを指定します。タイムアウトは連続する送信操作間でのみ適用されます。単一の送信が開始されてから完了までの間に適用されるものではありません。
既定では、CSP 拡張モジュールは指示文 CSP_send_timeout 300s を適用します。
単一の読み取り操作 (GET など) の応答が返る際のタイムアウトを指定します。タイムアウトは連続する読み取り操作間でのみ適用されます。単一の読み取りが開始されてから完了までの間に適用されるものではありません。
既定では、CSP 拡張モジュールは指示文 CSP_read_timeout 300s を適用します。
例 : 特定のパスでのすべてのトラフィックに対する CSP ルーティングを有効にする
適切な server 構成ブロック内に以下のセクションを配置し、/csp パスに送信されるすべてのトラフィックを Web ゲートウェイにルーティングします。
location /csp {
CSP On;
CSPNSD_pass localhost:7038;
}
例 : InterSystems IRIS のファイル・タイプに対する要求を Web ゲートウェイにルーティングする
適切な server 構成ブロック内に以下のセクションを配置し、/csp パスに送信される InterSystems IRIS のファイル・タイプ (.csp、.cls、.zen、および .cxw)、および管理ポータル・インタフェースが使用する静的ファイルのファイル・タイプに対する要求の CSP ルーティングを有効にします。
location /csp {
CSPFileTypes csp cls zen cxw jpg gif png svg css js;
CSPNSD_pass localhost:7038;
}
Nginx と NSD の起動および停止
Nginx を起動する方法は、以下のとおりです。
C:\nginx\nginx
Nginx を停止する方法は、以下のとおりです。
C:\nginx\nginx –s stop
NSD の操作方法については、"NSD の操作" を参照してください。
VS Code ユーザの場合 : 必要な追加構成
InterSystems ObjectScript 拡張機能を含む VS Code を、Nginx Web サーバを使用する InterSystems IRIS インスタンスに接続する場合は、Nginx を以下のように構成する必要があります。
-
サポートされている ObjectScript IDE は、/api/atelier Web アプリケーションを使用して InterSystems IRIS に接続します。この Web アプリケーションは、アンダースコアがある HTTP ヘッダを含む要求を送信します。既定では、Nginx はこれらのヘッダを通知なしで削除します。Nginx がこれらを保持できるようにしてください。http://nginx.org/en/docs/http/ngx_http_core_module.html#underscores_in_headersOpens in a new tab を参照してください。
-
デバッガなどの機能には、WebSocket 接続が必要です。既定では、Nginx は WebSocket をサポートするように構成されていません。Nginx が WebSocket をサポートできるようにしてください。http://nginx.org/en/docs/http/websocket.htmlOpens in a new tab を参照してください。
非推奨 : ユニバーサル・モジュールを使用する Nginx の構築
Nginx でのユニバーサル・モジュールの使用は、安定性に問題があるため推奨されていません。NSD を使用して Nginx に接続する Web ゲートウェイの導入では、WebSockets を含め、すべての機能を完全にサポートしています。
現在、Nginx でユニバーサル・モジュールを使用している場合は、Web ゲートウェイを最新バージョンにアップグレードし、NSD と連携するように Nginx サーバを再構築することをお勧めします。サーバ構成ファイルを編集する際は、サーバ構成から CSPModulePath 指示文を必ず削除してください。
以下の手順は、既存のインストールのリファレンスとしてのみ機能します。
NSD の代わりに動的にリンクされたユニバーサル・モジュール CSPx.dll (実行時) と CSPxSys.dll (Web ゲートウェイ・システム管理) と連携するように Nginx を構築できます。ユニバーサル・モジュールと連携するように Nginx を構築および構成する手順は、以下のように NSD ベースの導入とは異なります。
-
手順 4 で、モジュールのソース・コードとして、ngx_http_csp_module.c ではなく ngx_http_csp_module_sa.c および ngx_http_csp_common.h を指定のディレクトリにコピーします。
-
手順 5 で、CSP の構成ファイル (/opt/nginx/objs/lib/csp/config) は、以下のようになります。
ngx_addon_name=ngx_http_csp_module_sa HTTP_MODULES="$HTTP_MODULES ngx_http_csp_module_sa" NGX_ADDON_SRCS="$NGX_ADDON_SRCS $ngx_addon_dir/ngx_http_csp_module_sa.c"
-
CSPModulePath 指示文を http 構成ブロックに追加して、ユニバーサル・ゲートウェイ・モジュールへのパスを指定します。
CSPModulePath install-dir/bin;
-
Windows の場合、スレッド・スタック・サイズを 2MB まで増やす必要があります。以下の指示文を Nginx 構成ファイルの先頭 (http セクションの前) に追加します。
thread_stack_size 2000000;
-
以下の指示文はサポートされていません。
-
CSPNSD_pass
-
CSPNSD_response_headers_maxsize
-
CSPNSD_connect_timeout
-
CSPNSD_send_timeout
-
CSPNSD_read_timeout
-
-
以下の指示文はサポートされています。
-
CSP
-
CSPFileTypes
-