このセクションの内容:

はじめに

リバース プロキシとは、バックエンドのサーバーとクライアントを仲介するものです。リバース プロキシはクライアントからのリクエストを受信し、プロキシ設定に従ってリクエストを変更し、変更されたリクエストをサーバーに送信します。結果として、リバース プロキシはサーバーのパフォーマンスを向上させ、インフラストラクチャのセキュリティを強化します。

リバース プロキシの構成方法はいくつかありますが、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  (別のプロトコルに中継する場合のみ必要)

  • X-Forwarded-For

転送リクエスト

リクエストを転送する方法の詳細については、リバース プロキシ サーバーのドキュメントを参照してください。以下の例は、リバース プロキシ サーバー設定の基本的なガイドです。   

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;
  proxy_set_header X-Forwarded-For    $proxy_add_x_forwarded_for;


  # 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)/?   /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_set_header X-Forwarded-For    $proxy_add_x_forwarded_for;

       # 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)$">
    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)">
    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>

(warning) <Location> および <LocationMatch> ディレクティブの順序が重要です。受信リクエストに一致するすべての <Location> および <LocationMatch> ディレクティブが実行時にマージされます。

トラブルシューティング

問題: 413 error from NGINX - "Entity too large"

解決方法: このエラーは、大きな XML レポートを Data Collector にパブリッシュするときに発生することがあります。設定ファイルに次のプロパティを追加することで、デフォルトの制限を増やすことができます：

client_max_body_size 512M;

既知の問題と制約

  • プロキシ サーバーのポートは JMS ポートではないため、プロキシ サーバーを経由して JMS イベント ブローカー URL にアクセスすることはできません。

 

  • No labels

Need assistance? Visit our support page