私はしばらくの間オンラインで探していましたが、ベストプラクティスの観点からこれに対する決定的な答えを見つけることができず、賛否両論を抽出することは困難でした。
Nginxリバースプロキシ経由で提供したい複数のアプリ/場所があります
app1は純粋な静的ファイルです。つまり、js/html/cssなどです。app2とapp3はwsgiアプリケーションです。
私の現在のソリューションでは、サブドメインを使用してルーティングの観点から差別化しています
example.com -> app1
app2.example.com -> app2
app3.example.com -> app3
次に、サーバー名に基づいて、アプリケーションごとにnginx構成に異なるサーバーブロックがあります。
これはうまく機能しますが、ルートを介して分割を実現する代替手段を認識しています。
example.com/ -> app1
example.com/app2/ -> app2
example.com/app3/ -> app3
どちらが良い習慣ですか?サブドメインがないため、CORS /セッションCookieの管理が容易になるだけでなく、サブドメインに複数のDNSレコードが必要ありません。ルートアプローチのデメリットはありますか?これらのアプローチは両方ともWebの周りに実装されているように見えるので、決定的な要因は何ですか。
個人的には、完全にシームレスに見える私に関しては、example.com/app1
、example.com/app2
、またはもっと深いレベルで、example.com/portal/app[1-N]
よりもapp1.example.com
およびapp[2-N].example.com
の方が好きです。
しかし多くのアプリケーション開発者は、次のことを前提としてコードを記述しています。
そして、ルート/
のレベルより下のURLパスでリバースプロキシルールを使用する必要がある場合、問題が発生します。
/js/
/images/
/css/
などの同じベースURLを使用し、HTML内のそれらのベースディレクトリのリソースへの絶対リンクを持ついくつかの異なるアプリケーションがある可能性があります。
はるかに簡単なのは、完全なサブドメインを単一のアプリケーションにマッピングすることです。
app1はappserver1で実行されています
app2はappserver2で実行されています
nginx構成では、これらのアプリケーションをexample.com/app1 example.com/app2としてexample.comのURLスペースにマップするための2つのリバースプロキシブロックがあります。
server {
listen 80;
server_name example.com;
root /var/www/html ;
location /app1/ {
proxy_pass http://appserver1/;
}
location /app2/ {
proxy_pass http://appserver2/;
}
}
たとえば、同じ絶対参照を持つことができます
<script src="/js/jquery.js"></script>
appserver1 /index.htmlとappserver2/index.htmlの両方のHTMLコード。
http://example.com/app1/index.html
をリクエストすると、ブラウザはスクリプトをロードしてhttp://example.com/js/jquery.js
をリクエストしようとしますが、それが発生しますか?
URL /js/jquery.jsは、ローカルファイルシステム/var/www/html/js/jquery.jsのファイルにマップされる場合があります。または、404 not foundエラーがトリガーされますが、appserver1に逆プロキシされることはありません。 /js/jquery.js
リバースプロキシは、絶対URL「/js/jquery.js」をapp1のhttp://example.com/app1/js/jquery.js
に自動的に書き換えたり、app2のhttp://example.com/app2/js/jquery.js
に同様の書き換えを行ったりしません。
あなたは それを調整する ができますが、セットアップと維持は面倒です。
server {
listen 80;
server_name example.com;
access_log /var/log/nginx/example.com-access.log;
error_log /var/log/nginx/example.com-error.log;
#because logs are love
location ~ ^/app3 {
#--->app3
}
location ~ ^/app2 {
#---> app2
}
location / {
#----> app1
}
}
これは、一般的な1サーバーブロック-複数の場所の構成である必要があります。