web-dev-qa-db-ja.com

TomcatへのNginxリバースプロキシ

DigitalOceanにUbuntu15.10 x64サーバーをセットアップして、いくつかのJavaアプリケーションをテストしました。Nginx1.9.3とTomcat8をインストールし、リバースプロキシとしてNginxを使用して、ポート8080ですべてのリクエストをTomcatに転送しています。

ここで物事が危険にさらされます。 Tomcatインストールで/ webapp1と/ webapp2の2つのアプリケーションを実行しています。 subdomain.domain.comを/ webapp1に、subdomain2.domain.comを/ webapp2にポイントしたいと思います。 Apacheでは、これはmod_proxyを使用した非常に単純な問題ですが、Nginxではもう少し不思議です。

これまでのところ、これが私のサイトで試したことです-enables/domainファイル。

第1ラウンド

server{
   server_name subdomain1.domain.com;
   # ******************SSL configuration ************************
   listen 443 ssl default_server;
   ssl_certificate /etc/nginx/conf/ssl/domain.crt;
   ssl_certificate_key /etc/nginx/conf/ssl/domain.key;
   #*********************************************************************

   #**********Proxy**********************
   location / {

   proxy_redirect off;
   proxy_set_header X-Forwarded-Host $Host;
   proxy_set_header X-Forwarded-Server $Host;
   proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
   proxy_pass http://subdomain1.domain.com:8080/webapp1/;
}

アクセスしたときにリクエストは機能しました https://subdomain1.domain.com しかし、/ webapp1 /などのコンテキストパスを参照するアプリケーション内のリンクは、-などの2つのコンテキストパスを含むURLになりました。 https://subdomain1.domain.com/webapp1/webapp1/ 。これにより、あらゆる種類の参照の破損などが発生しました。

第2ラウンド同様の問題について説明しているスレッドを見つけました。修正は、書き換えを使用してURLから余分なコンテキストパスを削除することでした。

server{
       server_name subdomain1.domain.com;
       # ******************SSL configuration ************************
       listen 443 ssl default_server;
       ssl_certificate /etc/nginx/conf/ssl/domain.crt;
       ssl_certificate_key /etc/nginx/conf/ssl/domain.key;
       #*********************************************************************

       #**********Proxy**********************
       location / {

       proxy_redirect off;
       proxy_set_header X-Forwarded-Host $Host;
       proxy_set_header X-Forwarded-Server $Host;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       proxy_pass http://subdomain1.domain.com:8080/webapp1/;
       rewrite ^/webapp1/(.*)$ /$1 last;
    }

これにより、URLのダブルコンテキストパスの問題が解決され、今のところ機能しますが、書き直しが不要な、より洗練されたソリューションがあるかどうか疑問に思っています。サーバーリソースの観点からは、書き換えにコストがかかるとは思えませんが、気に入らない点があります。

よろしくお願いします。

nginxtomcatreverse-proxyproxypass
1
clayton rogers

更新

それ以来、場所の構成について読みました。これは、URLのダブルコンテキストパスを解決し、書き換えを使用する必要がない別の構成です。基本的に、nginxは両方のロケーション構成を使用するため、URIに https://subomdain1.domain.com/webapp1/webapp1/ のようなダブルコンテキストパスがある場合、2番目のロケーションブロックでそれを取得します。そしてそれをTomcatサーバーに転送しますが、最初のコンテキストパスはありません。これまたは書き換えソリューションがよりエレガントかどうかはわかりません。

     server{
           server_name subdomain1.domain.com;
           # ******************SSL configuration ************************
           listen 443 ssl default_server;
           ssl_certificate /etc/nginx/conf/ssl/domain.crt;
           ssl_certificate_key /etc/nginx/conf/ssl/domain.key;
           #*********************************************************************

           #**********Proxy**********************
           location / {

           proxy_redirect off;
           proxy_set_header X-Forwarded-Host $Host;
           proxy_set_header X-Forwarded-Server $Host;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_pass http://subdomain1.domain.com:8080/webapp1/;
           #rewrite ^/webapp1/(.*)$ /$1 last;
        }
           location /webapp1/ {

           proxy_redirect off;
           proxy_set_header X-Forwarded-Host $Host;
           proxy_set_header X-Forwarded-Server $Host;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_pass http://subdomain1.domain.com:8080/webapp1/;
        }
    }
1
clayton rogers