Konfiguracja Nginx do przekazywania witryny bezpośrednio do aplikacji internetowej tomcat z kontekstem

tl; wersja dr

Jak się konfigurujesznginx jako odwrotne proxy dlaexample.com do lokalnie działającegotomcat webapp athttp://127.0.0.1:8080/blah/ bez zerwaniapageContext?

Konfiguracja Tomcat

Istniejekocur 7 Aplikacja internetowa,blah, wdrożony za pomocą.war plik i siedzenie/var/lib/tomcat7/webapps/blah/.

tomcat działa lokalnie i jest dostępny pod adresemhttp://127.0.0.1:8080. Wiele aplikacji internetowych działa i można uzyskać do nich dostęp pod adresem:

http://127.0.0.1:8080/blah/http://127.0.0.1:8080/foo/http://127.0.0.1:8080/bar/

Port8080 jest blokowany zewnętrznie przez zaporę.

Konfiguracja Nginx

nginx działa na serwerze jako strażnik. Jedna strona jest włączona, aby uzyskać dostęp do wszystkich lokalnych aplikacji internetowych tomcat wymienionych powyżej. To działa dobrze dlaexample.com:

server {
listen  80; 
server_name example.com;
root /var/lib/tomcat/webapps/ROOT/;

  location / { 
    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://127.0.0.1:8080/;
  }
}
Pytanie: jak skonfigurować dodatkową witrynę do dostępublah bezpośrednio?

Pod/etc/nginx/sites-enabled/ dodatkowy plik lokacji jest ustawiony na trasęhttp://blah.com dohttp://127.0.0.1:8080/blah/ ale są problemy.

server {
  listen  80; 
  server_name blah.com *.blah.com;
  root /var/lib/tomcat/webapps/blah/;

  location / { 
    proxy_set_header X-Forwarded-Host   $host;
    proxy_set_header X-Real-IP          $remote_addr;  
    proxy_set_header X-Forwarded-Server $host;
    proxy_set_header X-Forwarded-For    $proxy_add_x_forwarded_for;
    proxy_pass                          http://127.0.0.1:8080/blah/;
  }
}

Ta konfiguracja dodaje dodatkoweblah do ścieżki kontekstu, tworząc404 strona, ponieważ ścieżka/blah/blah/ nie istnieje, co ma sens. Czy istnieje prosty sposóbnginx zdaćblah.com do roota aplikacji webapp?

W webappie używam${pageContext.request.contextPath}/path dla ścieżek względnych do zasobu webapp. Myślałem, że to właściwy sposób na obsługę wewnętrznych ścieżek tomcat, ale czy może to być częścią problemu? Wierzę, że dlatego dostaję dodatkoweblah na trasie, tworząc404 strona.

<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<!DOCTYPE html>
<html>
<head>
  <meta charset="UTF-8">
  <meta http-equiv="refresh" content="0; url=${pageContext.request.contextPath}/form">
  <script type="text/javascript">
    window.location.href = "${pageContext.request.contextPath}/form"
  </script>
  <title>Load BLAH</title>
</head>
<body>
  <p>If you are not redirected automatically, follow this <a href="${pageContext.request.contextPath}/form">link</a>.</p>
</body>
</html>

Ta strona jest trafiona, ale przekierowanie trafia do/blah/blah/form zamiast/blah/form gdzie serwlet faktycznie istnieje.

Próbowałem również innych metod, w tym wskazywaniablah.com do samego korzenia kocura. To działa w takim sensie, w jakim możeszblah przezblah.com/blah/ ale tak naprawdę nie tego chcemy.

Ponadto jest całkowicie dopuszczalne (i pożądane), aby nadal mieć dostępblah przezexample.com/blah/.

Oczywiście jest to dlanginx nowicjusz, ale pomóż mi (i przyszłym nowicjuszom) wyjaśnić to, ponieważ jasne rozwiązanie wymyka się mnie inginx doktorzy też korzystają z pomocy.

questionAnswers(4)

yourAnswerToTheQuestion