Я какое-то время искал в Интернете, но не смог найти окончательного ответа на этот вопрос с точки зрения передовой практики, поэтому было сложно извлечь плюсы и минусы.
У меня есть несколько приложений / местоположений, которые я хочу обслуживать через обратный прокси-сервер 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
Какая практика лучше? Отсутствие поддоменов упрощает управление файлами cookie CORS / Session, а также не требует наличия нескольких записей DNS для поддоменов. Есть ли недостатки у маршрутного подхода? Кажется, что оба этих подхода реализованы в Интернете, так что что является решающим фактором.
Лично я предпочитаю example.com/app1 , example.com/app2 или, может быть, даже на более глубоком уровне, example.com/portal/app[1-N] к app1.example.com и app[2-N].example.com как мне кажется, это кажется совершенно бесшовным.
Но многие разработчики приложений пишут код, исходя из того, что:
И это вызовет проблемы, когда вам придется использовать правила обратного прокси для URL-пути, который находится ниже уровня корня. /.
Вероятно, у вас есть несколько разных приложений, которые используют один и тот же базовый URL-адрес, например /js/ /images/ /css/ и т.д. с абсолютными ссылками на ресурсы этих базовых каталогов в их HTML.
Гораздо проще просто сопоставить полный поддомен с одним приложением.
app1 работает на appserver1
app2 работает на appserver2
а в конфигурации nginx у вас есть два блока обратного прокси для сопоставления этих приложений с пространством URL-адресов example.com как example.com/app1 example.com/app2
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>
в HTML-коде appserver1 / index.html и appserver2 / index.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" на http://example.com/app1/js/jquery.js для app1, и он не будет выполнять аналогичную перезапись в http://example.com/app2/js/jquery.js для app2.
Ты можешь поправить на это но это больно настраивать и поддерживать.
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 серверный блок с несколькими местоположениями.