Мы боремся со следующей проблемой и пытаемся понять, как лучше с ней справиться. Общая цель такая:
--> example.com/app1 --> app1.com/
--> example.com/app1/images --> app1.com/images
--> example.com/app2 --> app2.com/
--> example.com/app2/images --> app2.com/images
--> example.com/app3 --> app3.com/
--> example.com/app3/images --> app3.com/images
Мы рассмотрели следующие решения, некоторые из них работают, а другие нет. Мы пытаемся выяснить, как лучше всего это сделать, потому что мы ни в коем случае не эксперты. Инструмент, который мы использовали до сих пор, - это Nginx для обратного прокси, но этот инструмент на самом деле не имеет значения, мы открыты для всего.
Nginx перезаписывает основной текст, добавляя «app1» для запросов app1 и т. Д. Как и в приведенном выше примере, есть запрос для app1, и возвращается index.html. В этом index.html, в свою очередь, есть тег, который выглядит как <img src="images/hello.png" />
файл. Очевидно, это не сработает, поэтому мы переписываем тело (т.е. index.html), чтобы сказать <img src="app1/images/hello.png" />
.
Мы должны хорошо разбираться в том, как мы создаем правила перезаписи тела, иначе мы могли бы переписать то, чего не планировали, а затем сломать какой-нибудь JS или HTML. Это решение также не работает для некоторой части JS-кода (мы используем Angular), который неявно не записывает расположение представлений и скорее собирается самим фреймворком.
Переместите каждое приложение из корня в свою папку. Это означает, что любой img или другой запрос будет обновлен до <img src="app1/images/hello.png" />
.
Мы должны изменить все существующие 3 веб-сайта, чтобы запрашивать ресурсы из их новых корней.
Любая помощь будет принята с благодарностью, заранее спасибо.
В идеале вы можете повторно развернуть свои приложения, чтобы каждое приложение было установлено в http://app<n>.com/app<n>
вместо корня документа.
Если нет, возможно, вы можете сделать ссылки относительными, а не ссылаться на /images/logo.png
ссылка на ../images/logo.png
или images/logo.png
или ../../images/logo.png
в зависимости от обслуживаемой страницы, которая будет правильно переводиться в ситуации обратного прокси.
Очевидно, что использование поддоменов для каждого приложения будет работать достаточно хорошо, обратный прокси все на app<n>.example.com/
к вашему внутреннему app<n>.com/
Обычно обратный прокси не перезаписывает содержимое тела ответа, которое он получает от сервера, на который был перенаправлен запрос, но apache позволит вам это сделать:
<Location /app1/>
ProxyPass http://app1.com/
ProxyPassReverse http://app1.com/
# rewrite the reponse body
AddOutputFilterByType SUBSTITUTE text/html
Substitute "s|/images/|/app1/images/|i"
</Location>
Ты можешь использовать nginx как обратный прокси для домена example.com.
Итак, в файле conf для сайта nginx, например, example.com, вы можете установить предложение перезаписи, чтобы выполнить то, что вы ищете.
Вы можете прочитать это руководство: http://www.cyberciti.biz/tips/using-nginx-as-reverse-proxy.html & https://www.digitalocean.com/community/articles/how-to-configure-nginx-as-a-front-end-proxy-for-apache
Надеюсь, что это работает для вас.
:)