このセクションの内容:
はじめに
リバース プロキシは、バックエンドのサーバーとクライアントを仲介するものです。リバース プロキシはクライアントからのリクエストを受信し、プロキシ設定に従ってリクエストを変更し、変更されたリクエストをサーバーに送信します。結果として、リバース プロキシはサーバーのパフォーマンスを向上させ、インフラストラクチャのセキュリティを強化します。
リバース プロキシの構成方法はいくつかありますが、DTP がサポートしているのはポートツーポートおよびパスツーポート構成です。パスツーポート構成の「パス」は、「コンテキスト パス」とも呼ばれます。どちらの方法でも、アプリケーションがホストされているポートにユーザー リクエストをフォワードするようリバース プロキシ サーバーを設定します。さらに、必要なヘッダーを DTP に送信するようにリバース プロキシ サーバーを構成するか、あるいは DTP Tomcat サーバーの設定を変更する必要があります。
ポートツーポート構成
ポートツーポート構成では、リバース プロキシは 1 つのポートでクライアントのトラフィックを受信し、DTP アプリケーション ポートのいずれかにトラフィックをリダイレクトします。このタイプの構成では、プロキシ サーバー上で利用可能なポート数に実装が制限されます。次のフォーマットは、DTP アプリケーションにポートツーポート構成が適用される方法を示しています。
DTP Report Center:
<PROTOCOL>://<PROXY>:8080 -> <PROTOCOL>://<DTP_HOST>:8080
Data Collector:
<PROTOCOL>://<PROXY>:8082 -> <PROTOCOL>:// <DTP_HOST>:8082
Enterprise Pack:
<PROTOCOL>://<PROXY>:8314 -> <PROTOCOL>://<DTP_HOST>:8314
要件
リバース プロキシは、DTP に転送されるリクエストに X-Forwarded-
ヘッダーを追加し、アプリケーションが適切に URL を生成できるようにする必要があります。 X-Forwarded-
ヘッダーは、ログイン、ナビゲーション、ALM システムなどの外部アプリケーションに送信されるリンクの HTTP リダイレクトに影響を与えます。次の X-Forwarded-
ヘッダーが必要です。
X-Forwarded-Host
X-Forwarded-Proto
(別のプロトコルに中継する場合のみ必要)
転送リクエスト
リクエストを転送する方法の詳細については、リバース プロキシ サーバーのドキュメントを参照してください。以下の例は、リバース プロキシ サーバー設定の基本的なガイドです。
NGINX の転送設定
次の設定では、すべての基底のサービス/Web アプリケーションがローカルマシンの HTTP 上で動作している必要があります (Data Collector は、デフォルトでは HTTPS を使用します)。設定はプロトコルのリダイレクト (HTTPS から HTTP など) をサポートしていますが、リバース プロキシで HTTPS を有効にするには追加の設定が必要です (サンプルのコメントを参照)。
http { # Simplifies setting the "Connection" header. # Required by Enterprise Pack application. map $http_upgrade $connection_upgrade { default upgrade; '' close; } # Add necessary headers for WebSocket proxying. # Required by Enterprise Pack application. proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; # Add necessary "X-Forwarded-" proxy headers. proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Host $http_host; # ssl_certificate /path/to/cert; # ssl_certificate_key /path/to/key; server { listen 9080; # listen 9443 ssl; location / { # Proxy incoming requests to DTP. proxy_pass http://localhost:8080/; } } server { listen 9082; # listen 9082 ssl; location / { # Proxy incoming requests to Data Collector. proxy_pass http://localhost:8082/; } } server { listen 9314; # listen 9314 ssl; location / { # Proxy incoming requests to Enterprise Pack. proxy_pass http://localhost:8314/; } } }
LF を改行として設定を保存する必要があります。 CRLF を改行として使用すると、設定ブロックにネストされたコメントによってパースの問題が発生する可能性があります。
リバース プロキシ環境で DTP Enterprise Pack を使用する方法については、「ネットワークの設定」を参照してください。
リバース プロキシ環境で Data Collector を使用する方法については、「Data Collector の設定」を参照してください。
WebSockets でのリバース プロキシのサポート
WebSockets の通信のために NGINX リバース プロキシ サーバーを構成する方法については次を参照してください: http://nginx.org/en/docs/http/websocket.html
パスツーポート構成 (コンテキスト パス)
パスツーポート構成では、クライアントのトラフィックは特定のコンテキスト パスでプロキシに送信され、DTP アプリケーション ポートのいずれかにリダイレクトされます。パスツーポート構成はプロキシ サーバーで利用可能なポートの数に制限されません。リクエストのコンテキスト パスに基づいて、多数の異なるバックエンド サーバーにリクエストをリダイレクトできます。そのため、この構成では標準の HTTP ポート (HTTP では 80、HTTPS では 433) がよく使用されます。
次のフォーマットは、DTP アプリケーションにコンテキストパス構成が適用される方法を示しています。
DTP Report Center
<PROTOCOL>://<PROXY>:8080/grs -> <PROTOCOL>://<DTP_HOST>/grs
Data collector
<PROTOCOL>://<PROXY>:8082 -> <PROTOCOL>://<DTP_HOST>:8082
Enterprise Pack
<PROTOCOL>://<PROXY>:8314 -> <PROTOCOL>://<DTP_HOST>:8314
必須の要件ではありませんが、一般的にすべての DTP and Enterprise Pack サーバーは共通のコンテキスト パスの下に構成され、サブコンテキスト パスで個々のサービス/Web アプリケーションが動作します。
<PROTOCOL>://<PROXY>/dtp/<WEBAPP> -> <PROTOCOL>://dtp:<PORT>/<WEBAPP>
要件
次のヘッダーを DTP に送信するようにリバース プロキシを設定します。
X-Forwarded-Host
X-Forwarded-Prefix
X-Forwarded-Proto
(別のプロトコルに中継する場合のみ必要)
ヘッダーの値は、Enterprise Pack ネットワーク構成設定のコンテキスト パス フィールド ( ネットワークの設定 を参照)、および/または Data Collector のコンテキスト の Data Collector 構成ファイルの <dc-reverse-proxy-path>
要素の値 ( Data Collector の設定 を参照) と一致する必要があります。Host
ヘッダーは、元のリクエストのホスト、つまりリバース プロキシ ホストでなければなりません。
転送リクエスト
リクエストの転送方法の詳細については、リバース プロキシ サーバーのドキュメントを参照してください。以下の例は、リバース プロキシ サーバー設定の基本的なガイドです。
NGINX でのコンテキスト パス設定の転送設定
次の設定では、基底のサービス/Web アプリケーションがローカルマシンの HTTP 上で動作している必要があります (Data Collector は、デフォルトでは HTTPS を使用します)。設定はプロトコルのリダイレクト (HTTPS から HTTP など) をサポートしていますが、リバース プロキシで HTTPS を有効にするには追加の設定が必要です (サンプルのコメントを参照)。
http { # Simplifies setting the "Connection" header. # Required by Enterprise Pack application. map $http_upgrade $connection_upgrade { default upgrade; '' close; } # Simplifies setting the "X-Forwarded-Prefix" header. map $request_uri $x_forwarded_prefix { ~^/dtp/(dc|ep|grs|licenseserver|pstsec|pst|tcm)/? /dtp/$1; ~^/dtp/?.* /dtp; } server { listen 80; # listen 443 ssl; # ssl_certificate /path/to/cert; # ssl_certificate_key /path/to/key; location /dtp/ { # Redirect to app with a trailing slash if not present. if ($request_uri = $x_forwarded_prefix) { return 301 $request_uri/; } # Add necessary headers for WebSocket proxying. # Required by Enterprise Pack application. proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; # Add necessary "X-Forwarded-" proxy headers. proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Host $http_host; proxy_set_header X-Forwarded-Prefix $x_forwarded_prefix; # Proxy incoming requests to the DTP server by default. proxy_pass http://localhost:8080/; location /dtp/dc/ { # Proxy incoming requests to Data Collector. proxy_pass http://localhost:8082/; } location /dtp/ep/ { # Proxy incoming requests to Enterprise Pack. proxy_pass http://localhost:8314/; } } } }
LF を改行として設定を保存する必要があります。CRLF を改行として使用すると、設定ブロックにネストされたコメントによってパースの問題が発生する可能性があります。
リバース プロキシ環境で DTP Enterprise Pack を使用する方法については、「ネットワークの設定」を参照してください。
リバース プロキシ環境で Data Collector を使用する方法については、「Data Collector の設定」を参照してください。
WebSockets でのリバース プロキシのサポート
WebSockets の通信のために NGINX リバース プロキシ サーバーを構成する方法については次を参照してください: http://nginx.org/en/docs/http/websocket.html
Apache HTTPD でのコンテキスト パス設定の転送設定
次の設定では、環境変数として DTP_HOSTNAME
を指定し、基底のサービスは HTTP で実行されている必要があります (Data Collector は、デフォルトでは HTTPS を使用します)。設定はプロトコルのリダイレクト (HTTPS から HTTP など) をサポートしていますが、リバース プロキシで HTTPS を有効にするには追加の設定が必要です (サンプルのコメントを参照)。
Listen 80 # Listen 443 https # SSLEngine on # SSLVerifyClient none # SSLProxyCheckPeerCN off # SSLCertificateFile /path/to/cert # SSLCertificateKeyFile /path/to/key # Automatically add the following headers to proxied requests. # - X-Forwarded-For # - X-Forwarded-Host # - X-Forwarded-Server ProxyAddHeaders on # Enable the "RewriteRule" directive used for WebSocket proxying. RewriteEngine on # Redirect to app with a trailing slash if not present. <LocationMatch "^/dtp/(grs|licenseserver|pstsec|pst|tcm)$"> RewriteRule .* "%{REQUEST_URI}/" [L] </LocationMatch> <Location /dtp> RequestHeader set X-Forwarded-Prefix /dtp RequestHeader set X-Forwarded-Proto expr=%{REQUEST_SCHEME} ProxyPass "http://${DTP_HOSTNAME}:8080" ProxyPassReverse "http://${DTP_HOSTNAME}:8080" </Location> <LocationMatch "^/dtp/(?<app>dc|ep|grs|licenseserver|pstsec|pst|tcm)"> RequestHeader set X-Forwarded-Prefix "/dtp/%{MATCH_APP}e" </LocationMatch> <Location /dtp/dc> ProxyPass "http://${DTP_HOSTNAME}:8082" ProxyPassReverse "http://${DTP_HOSTNAME}:8082" </Location> <Location /dtp/ep> ProxyPass "http://${DTP_HOSTNAME}:8314" ProxyPassReverse "http://${DTP_HOSTNAME}:8314" # mod_proxy_wstunnel is required for WebSocket proxying. # Rewrite for Enterprise Pack WebSockets. RewriteCond %{HTTP:Upgrade} websocket [NC] RewriteCond %{HTTP:Connection} upgrade [NC] RewriteCond %{REQUEST_URI} ^/dtp/ep/(socket\.io/.*) [NC] RewriteRule .* "ws://${DTP_HOSTNAME}:8314/%1" [P,L] # Rewrite for Node-RED WebSockets. RewriteCond %{HTTP:Upgrade} websocket [NC] RewriteCond %{HTTP:Connection} upgrade [NC] RewriteRule .* "ws://${DTP_HOSTNAME}:8314%{REQUEST_URI}" [P,L] </Location>
<Location>
および <LocationMatch>
ディレクティブの順序が重要です。受信リクエストに一致するすべての <Location> および <LocationMatch> ディレクティブが実行時にマージされます。
既知の問題と制約
- プロキシ サーバーのポートは JMS ポートではないため、プロキシ サーバーを経由して JMS イベント ブローカー URL にアクセスすることはできません。