nginx configuração de proxy reverso para manipular implementações graciosas de servidores upstream [duplicado]

Question

Minha configuração atual é nginx como um balanceador de carga, na frente de vários servidores upstream.

Eu quero ser capaz de implantar sem alterações na experiência do usuário. Isso significa que não há tempos de 502s nem aumento de páginas.

O meu entendimento é que quando o nginx -s reload é emitido, o nginx gera novos threads para lidar com novas conexões para a nova configuração, mas ainda finaliza as solicitações de tratamento que estavam em andamento no momento do recarregamento. Além disso, eu li em algum lugar que marcando um upstream como down no bloco upstream, e recarregando, terá que upstream da rotação, mas ainda terminará todas as conexões em vôo para ele.

Algum / tudo isso está correto?

O plano atual é ter um pequeno processo no host nginx, que basicamente modificará a configuração do nginx e emitirá esses recarregamentos quando solicitado a fazê-lo por meio de uma API REST interna.

Minha ferramenta de implantação conectará esse processo e adicionará / removerá meus upstreams da configuração nginx em sequência, após o desligamento normal e inicialização / aquecimento para cada upstream estar concluído.

Isso faz sentido? Como outras pessoas estão fazendo isso? Existem ferramentas já disponíveis para isso?

Eu não tive muita sorte procurando informações sobre isso ...

    

Answer 1

Sim, você está correto ao pensar que o nginx continua lidando com as solicitações atuais ao recarregar e começará a processar novas solicitações com a nova configuração.

link

Old worker processes, receiving a command to shut down, stop accepting new connections and continue to service current requests until all such requests are serviced. After that, the old worker processes exit.

Marcando um envio como down não difere significativamente de removê-lo da configuração. Não aceitará novas solicitações em ambos os casos.

Nós frequentemente recarregamos a configuração nginx (gerada usando cog link ) e isso não causa nenhum tempo de inatividade até onde o proxy está preocupado com as localizações upstream . Contanto que o upstream esteja pronto para processar solicitações, não há tempo de inatividade.