ANÚNCIO

~/questoes/devops

Qual é a vantagem de usar múltiplos containers Docker backend com um NGINX centralizado?

Responda, confira o feedback e use o resultado para orientar sua revisão.
Aula de referência #10 – Como aplicar proxy reverso no NGINX | Thi Code
Para fixar

Arquitetura com NGINX Centralizado e Múltiplos Containers Backend

Conceito central

Uma arquitetura moderna combina um NGINX centralizado como proxy reverso com múltiplos containers Docker rodando serviços backend isolados. Essa abordagem permite que o NGINX atue como porta de entrada única, distribuindo requisições entre diferentes serviços de forma eficiente e organizada.

Por que essa resposta faz sentido

Usar múltiplos containers backend com NGINX centralizado facilita a manutenção porque cada serviço fica isolado em seu próprio container, permite escalabilidade horizontal ao adicionar novos containers conforme necessário, e organiza melhor a infraestrutura ao centralizar o roteamento e load balancing em um único ponto.

Armadilhas comuns

  • Confundir NGINX como proxy reverso com múltiplas instâncias do NGINX rodando em cada container backend. Na verdade, o NGINX roda de forma centralizada, separado dos backends.
  • Pensar que o NGINX centralizado elimina completamente a necessidade de configuração. Você ainda precisa definir as regras de roteamento, upstreams e políticas de load balancing no arquivo nginx.conf.
  • Acreditar que cada container backend precisa executar sua própria versão do NGINX. Não é assim; os containers backend rodam apenas suas aplicações, enquanto um único NGINX centralizado gerencia todo o tráfego.

Entenda as alternativas

A

Essa alternativa está errada porque normalmente você usa uma única instância do NGINX como proxy reverso centralizado. Não faz sentido ter múltiplas versões do NGINX rodando simultaneamente nos containers backend; o NGINX fica separado, atuando como intermediário.

B

Essa alternativa não faz sentido porque as requisições precisam sim passar pelo NGINX. É exatamente isso que o torna útil: o NGINX recebe todas as requisições dos clientes e as distribui inteligentemente entre os containers backend.

C

Essa alternativa é incorreta porque a configuração do NGINX ainda exige regras de roteamento bem pensadas. Você precisa definir upstreams, rotas específicas e lógicas de distribuição de carga. O NGINX centralizado ajuda, mas não elimina a necessidade de configuração.

D

Essa é a alternativa correta. O NGINX centralizado facilita manutenção (cada container pode ser atualizado independentemente), permite escalabilidade horizontal (adicione mais containers conforme a demanda) e oferece isolamento entre serviços (cada container roda sua aplicação de forma independente).

Dica prática: Na prática, configure seus containers backend com as aplicações (Node.js, Python, Java, etc.) sem NGINX dentro deles. Depois, crie um container NGINX separado com configurações de upstream apontando para os IPs e portas dos containers backend. Assim, quando uma requisição chega, o NGINX distribui entre os backends disponíveis automaticamente.

Revise pensando: Se você precisa adicionar um novo serviço backend à sua arquitetura, você altera o arquivo nginx.conf para adicionar um novo upstream e regra de roteamento, ou você adiciona um novo container backend diretamente? Por quê?