§フロントエンドHTTPサーバーのセットアップ
アプリケーションのHTTPポートを80に設定することで、スタンドアロンサーバーとして簡単にアプリケーションをデプロイできます。
$ /path/to/bin/<project-name> -Dhttp.port=80
注意: このポートでプロセスをバインドするには、おそらくroot権限が必要です。
ただし、同じサーバーで複数のアプリケーションをホストする場合、またはスケーラビリティやフォールトトレランスのためにアプリケーションの複数のインスタンスの負荷を分散する場合は、フロントエンドHTTPサーバーを使用できます。
フロントエンドHTTPサーバーを使用しても、Playサーバーを直接使用する場合よりもパフォーマンスが向上することはほとんどありません。ただし、HTTPサーバーはHTTPS、条件付きGETリクエスト、静的アセットの処理に非常に優れており、多くのサービスはフロントエンドHTTPサーバーがアーキテクチャの一部であることを前提としています。
§lighttpdでのセットアップ
この例では、lighttpdをフロントエンドWebサーバーとして設定する方法を示します。Apacheでも同じことができますが、仮想ホスティングまたは負荷分散のみが必要な場合は、lighttpdが非常に適しており、設定がはるかに簡単です。
/etc/lighttpd/lighttpd.conf
ファイルには、次のような設定を定義する必要があります。
server.modules = (
"mod_access",
"mod_proxy",
"mod_accesslog"
)
$HTTP["host"] =~ "www.myapp.com" {
proxy.balance = "round-robin" proxy.server = ( "/" =>
( ( "host" => "127.0.0.1", "port" => 9000 ) ) )
}
$HTTP["host"] =~ "www.loadbalancedapp.com" {
proxy.balance = "round-robin" proxy.server = ( "/" => (
( "host" => "127.0.0.1", "port" => 9001 ),
( "host" => "127.0.0.1", "port" => 9002 ) )
)
}
mod_proxy
の設定方法の詳細については、lighttpdのドキュメントを参照してください。
§nginxでのセットアップ
この例では、nginxをフロントエンドWebサーバーとして設定する方法を示します。Apacheでも同じことができますが、仮想ホスティングまたは負荷分散のみが必要な場合は、nginxが非常に適しており、設定がはるかに簡単です。
注意: nginxには、ロードバランサーとして設定する方法に関する広範なドキュメントがあります。詳細については、HTTPロードバランスガイドを参照してください。
/etc/nginx/nginx.conf
ファイルには、次のようなupstream
ブロックとserver
ブロックを定義する必要があります。
upstream playapp {
server 127.0.0.1:9000;
}
server {
listen 80;
server_name www.domain.com;
location / {
proxy_pass http://playapp;
}
}
詳細については、完全な設定例を参照してください。また、nginxを使用してSSLターミネーションを行う場合は、こちらのドキュメントを参照してください。
注意: Nginxのバージョン1.2以降を使用していることを確認してください。それ以外の場合は、チャンク化されたレスポンスが正しく機能しません。
§Apacheでのセットアップ
以下の例は、標準のPlay設定の前に実行されているApache httpdサーバーを使用した簡単なセットアップを示しています。
LoadModule proxy_module modules/mod_proxy.so
…
<VirtualHost *:80>
ProxyPreserveHost On
ServerName www.loadbalancedapp.com
ProxyPass /excluded !
ProxyPass / http://127.0.0.1:9000/
ProxyPassReverse / http://127.0.0.1:9000/
</VirtualHost>
§高度なプロキシ設定
HTTPフロントサーバーを使用する場合、リクエストアドレスはHTTPサーバーからのものとして認識されます。Playアプリとプロキシの両方が同じマシンで実行されている通常のセットアップでは、Playアプリは127.0.0.1
からのリクエストとして認識します。
プロキシサーバーは、リクエストに特定のヘッダーを追加して、プロキシされたアプリケーションにリクエストの送信元を知らせることができます。ほとんどのWebサーバーは、最初のパラメーターとしてリモートクライアントのIPアドレスを持つX-Forwarded-For
ヘッダーを追加します。プロキシサーバーがlocalhost
で実行されていて、127.0.0.1
から接続している場合、PlayはそのX-Forwarded-For
ヘッダーを信頼します。
ただし、ホストヘッダーは変更されず、プロキシによって発行されたままになります。Apache 2.xを使用する場合は、次のようなディレクティブを追加できます。
ProxyPreserveHost on
Host
ヘッダーは、クライアントによって発行された元のホストリクエストヘッダーになります。これら2つの手法を組み合わせることで、アプリは直接公開されているように見えます。
このPlayアプリでルート全体を占有したくない場合は、プロキシ設定に除外ディレクティブを追加します。
ProxyPass /excluded !
§アプリケーションの透過的なアップグレードを可能にするためのフロントプロキシとしてのApache
基本的な考え方は、Webアプリケーションの2つのPlayインスタンスを実行し、フロントエンドプロキシに負荷を分散させることです。一方が利用できない場合は、すべてのリクエストを利用可能な方に転送します。
同じPlayアプリケーションを2回起動してみましょう。1つはポート9999
、もう1つはポート9998
です。
start -Dhttp.port=9998
start -Dhttp.port=9999
次に、ロードバランサーを持つようにApache Webサーバーを設定しましょう。Apacheで、次の設定を追加します。
<VirtualHost mysuperwebapp.com:80>
ServerName mysuperwebapp.com
<Location /balancer-manager>
SetHandler balancer-manager
Order Deny,Allow
Deny from all
Allow from .mysuperwebapp.com
</Location>
<Proxy balancer://mycluster>
BalancerMember http://localhost:9999
BalancerMember http://localhost:9998 status=+H
</Proxy>
<Proxy *>
Order Allow,Deny
Allow From All
</Proxy>
ProxyPreserveHost On
ProxyPass /balancer-manager !
ProxyPass / balancer://mycluster/
ProxyPassReverse / balancer://mycluster/
</VirtualHost>
重要な部分はbalancer://mycluster
です。これはロードバランサーを宣言します。 +H
オプションは、2番目のPlayアプリケーションがスタンバイ状態にあることを意味します。ただし、負荷分散するように指示することもできます。
Apacheは、クラスターの状態を表示する方法も提供しています。クラスターの現在の状態を表示するには、ブラウザで/balancer-manager
を指定するだけです。
Playは完全にステートレスであるため、2つのクラスター間でセッションを管理する必要はありません。実際には、2つ以上のPlayインスタンスに簡単にスケールできます。
WebSocketを使用するには、Apache 2.4で導入されたmod_proxy_wstunnelを使用する必要があります。
ProxyPassReverseは、URIに/を追加してヘッダーを誤って書き換える可能性があるため、この回避策を使用することをお勧めします。
ProxyPassReverse / http://localhost:9999
ProxyPassReverse / http://localhost:9998
§信頼できるプロキシの設定
Playは、プロキシがリクエストの着信IPアドレスとプロトコルを示すために使用するさまざまな転送ヘッダーをサポートしています。Playはこの設定を使用して、RequestHeader
のremoteAddress
フィールドとsecure
フィールドの正しい値を計算します。
HTTPクライアント(ブラウザであっても他のクライアントであっても)が転送ヘッダーを偽造して、Playが報告するIPアドレスとプロトコルをスプーフィングすることは簡単です。そのため、Playはどのプロキシが信頼できるかを知る必要があります。Playは、信頼できるプロキシのリストを設定するための設定オプションを提供し、着信転送ヘッダーを検証して信頼できることを確認します。信頼できない最初のIPアドレスを報告されたユーザーのリモートアドレスとして扱います(すべてが信頼できる場合は最後のIPアドレス)。
信頼できるプロキシのリストを設定するには、play.http.forwarded.trustedProxies
を設定できます。これは、IPアドレスまたはCIDRサブネット範囲のリストを受け取ります。IPv4とIPv6の両方がサポートされています。例えば
play.http.forwarded.trustedProxies=["192.168.0.0/24", "::1", "127.0.0.1"]
これは、192.168.0
で始まるすべてのIPアドレス、およびIPv6とIPv4のループバックアドレスが信頼できることを示しています。デフォルトでは、Playはループバックアドレス、つまり::1
と127.0.0.1
のみを信頼します。
§すべてプロキシを信頼する
多くのクラウドプロバイダー、特にAWSは、ロードバランサープロキシが使用するIPアドレスについて保証を提供していません。したがって、これらのサービスで転送ヘッダーをサポートする唯一の方法は、すべてのIPアドレスを信頼することです。これは、信頼できるプロキシを次のように設定することで実現できます。
play.http.forwarded.trustedProxies=["0.0.0.0/0", "::/0"]
§転送ヘッダーバージョン
Playは2つの異なるバージョンの転送ヘッダーをサポートしています。
- X-Forwardedヘッダーを使用した従来の方法
- Forwardedヘッダーを使用したRFC 7239
これはplay.http.forwarded.version
を使用して設定され、有効な値はx-forwarded
またはrfc7239
です。デフォルトはx-forwarded
です。
x-forwarded
は、事実上の標準であるX-Forwarded-For
およびX-Forwarded-Proto
ヘッダーを使用して、リクエストの正しいリモートアドレスとプロトコルを決定します。これらのヘッダーは広く使用されていますが、深刻な制限があります。たとえば、複数のプロキシがあり、そのうちの1つだけがX-Forwarded-Proto
ヘッダーを追加する場合、どのプロキシが追加したかを確実に判断することはできません。したがって、クライアントからのリクエストがhttpsを使用して行われたかhttpを使用して行われたかを判断することはできません。 rfc7239
は新しいForwarded
ヘッダースタンダードを使用し、X-Forwarded-*
ヘッダーの多くの制限を解決します。
詳細については、RFC 7239仕様をお読みください。
次: HTTPSの設定
このドキュメントに誤りを見つけましたか?このページのソースコードはこちらにあります。ドキュメントガイドラインをお読みなった後、プルリクエストを送信してください。質問やアドバイスがあれば、コミュニティフォーラムにアクセスして、コミュニティとの会話を始めてください。