Proxy reverso Nginx tornando webapp raiz em caminho personalizado

Question

Estou tentando configurar vários contêineres docker com a mesma imagem em uma única máquina e hospedar todos os aplicativos no mesmo domínio separados por caminho. O objetivo é isolar cada cliente em seu próprio contêiner. ou seja, mydomain.com/aaa , mydomain.com/bbb ... etc.

Estou usando nginx como proxy reverso e segui vários exemplos on-line. Minha configuração nginx se parece com:

server {
    listen       ...;
    ...
    location / {
        proxy_pass http://127.0.0.1:8080;
    }

    location /aaa {
        proxy_pass http://127.0.0.1:8181;
    }

    location /bbb {
        proxy_pass http://127.0.0.1:8282;
    }
    ...
}

Percebi que o aplicativo espera estar hospedado na raiz / , que atualmente acaba em 404. Existe uma maneira inteligente de reescrevê-los em seu próprio caminho com base na origem da solicitação sem modificar o próprio aplicativo? ?

Estou ciente de que pode ser mais fácil usar o subdomínio, mas quero evitar adicionar e remover subdomínios à medida que os clientes vêm e vão.

    

Answer 1

A resposta simples é não.

Você precisa considerar pelo menos três aspectos de forçar um aplicativo a viver longe da raiz.

• Mapeamento de URLs com base na raiz para o novo local - , o que é fácil com proxy_pass ou rewrite
• Mapeamento de respostas de redirecionamento (301, 302, etc) - , o que é fácil com proxy_redirect
• Mapeamento de URLs de recursos e hiperlinks incorporados

O último ponto não é fácil. As aplicações que esperam viver na raiz geralmente acessam seus recursos em relação à raiz, o que significa que eles acessam o local errado no proxy reverso.

O Apache tem um módulo que pode reescrever URLs embutidas no documento HTML, mas isso parece ineficiente para mim.

A solução preferida é alterar o aplicativo para tornar seu recurso e URLs de hiperlink com um caminho relativo ou prefixado com o mesmo caminho personalizado.

    

Answer 2

Estou tentando fazer a mesma configuração, então me deparei com o mesmo problema. Parece-me que, na verdade, é preciso alterar os aplicativos de backend, como Richard Smith descreve. Usar portas "externas" diferentes para o nginx é uma solução alternativa, mas não é elegante.