failover proxy_pass Nginx para uma url em vez de um servidor

Question

Eu tenho um endpoint solicitando meu banco de dados através do Symfony:
api.domain.com:80/item/123

Quando esse endpoint é solicitado, o Ngninx passará o proxy para um servidor nodejs capaz de obter o item do memcache:
127.0.0.1:8000/item/123

Se o item não for encontrado no memcache, ele será obtido de outro ponto de extremidade do PHP:
api.domain.com:80/item/db/123

Funciona bem, mas não vejo como gerenciar uma falha de nodejs. Se o nodejs não responder mais, eu gostaria de ignorar o proxy_pass ou usar o segundo endpoind (/ item / db / 123).

Minha configuração do Nginx é:

upstream itemFromNodeJs {
    server 127.0.0.1:8000;
}
server {
    listen 80;
    server_name api.domain.com 127.0.0.1;

    location ~*\/item\/([0-9]+)$ {
        proxy_pass http://itemFromNodeJs;
    }

Eu tentei adicionar um servidor de backup ao upstream:

upstream itemFromNodeJs {
    server 127.0.0.1:8000;
    server 127.0.0.1:80;
}

Claro, não pode funcionar: loop infinito quando o nodejs está inativo.

A única solução que tenho em mente é criar um servidor específico para obter dados do banco de dados:

upstream itemFromNodeJs {
    server 127.0.0.1:8000;
    server 127.0.0.1:9000;
}

Mas eu tenho que duplicar todo o servidor: está longe de ser elegante.

Alguma outra ideia?

    

Answer 1

Bom conselho de Alexey!
Aqui está minha nova configuração:

upstream itemFromNodeJs {
    server 127.0.0.1:8000;
}
server {
    listen 80;
    server_name api.domain.com 127.0.0.1;

     location ~*\/item\/([0-9]+)$ {
        proxy_pass http://itemFromNodeJs;
        error_page 502 = /item/db/$1;
    }
    ...
}

Então, o que acontece agora?
Se o servidor nodejs estiver ativo, o proxy_pass funcionará e nós não iremos mais longe.
Se o servidor nodejs estiver inativo, a error_page interceptará o erro 502 e acessará o URL de fallback, incluindo o parâmetro url ($ 1). O = altera o código de status de 502 para o retornado pelo URL de fallback. Isso é exatamente o que eu queria.

Pode-se dizer que isso é uma "maneira barata e barata" de brincar com a semântica: uma página de erro é uma página de erro e não uma alternativa. Eu concordo, mas esta também é uma lógica respeitável: meu servidor proxy (nodejs) está inoperante, dando assim um erro ...

Se alguém tiver outra solução, ainda estou interessado!