Como configurar uma rede Docker dedicada para backends de proxy reverso

Eva Wong

IceWhale author

Eva Wong é a Redatora Técnica e e entusiasta residente na ZimaSpace. Uma geek de longa data com paixão por homelabs e software de código aberto, ela é especialista em traduzir conceitos técnicos complexos em guias acessíveis e práticos . Eva acredita que o auto-hospedagem deve ser divertida, não intimidante. Através dos seus tutoriais, ela capacita a comunidade adesmistificar configurações de hardware , desde a construção do seu primeiro NAS até dominar os contêineres Docker., from building their first NAS to mastering Docker containers.

How to Set Up a Dedicated Docker Network for Reverse-Proxy Backends - Zima Store Online

Ligue o proxy reverso e cada backend HTTP à mesma rede definida pelo utilizador; mantenha as bases de dados em redes privadas da aplicação.

Publicar todas as portas dos backends no anfitrião NAS é desnecessário quando o proxy consegue resolver os nomes dos serviços Compose numa bridge definida pelo utilizador. Um padrão com duas redes dá ao proxy um caminho controlado para os backends Web, enquanto as bases de dados permanecem acessíveis apenas às respetivas aplicações. Defina a propriedade das redes, evite aliases ambíguos, decida quais os serviços que necessitam de acesso de saída e confirme que as portas do anfitrião permanecem fechadas.

Defina a matriz de acessibilidade pretendida

Liste todas as ligações: cliente para proxy, proxy para backend, backend para base de dados, backend para APIs externas e administrador para endpoints de manutenção. Registe o protocolo, a porta, o nome DNS e se o caminho atravessa o anfitrião.

Normalmente, apenas o proxy reverso deve publicar as portas 80 e 443. Os backends expõem a porta da aplicação à rede Docker sem um mapeamento ports para o anfitrião. As bases de dados devem aderir apenas à rede privada da aplicação, salvo se for necessário um caminho explícito de administração.

Escolha nomes de serviço ou aliases de rede estáveis e únicos. O DNS do Docker resolve serviços em redes definidas pelo utilizador partilhadas, mas aliases genéricos como web podem entrar em conflito quando vários projetos Compose estão ligados à mesma rede do proxy.

Crie uma rede partilhada do proxy e uma rede privada da aplicação

Crie a rede do proxy uma vez, marque-a como externa em cada projeto da aplicação e ligue o proxy e o backend pretendido. Isto mantém a identidade da rede estável quando um projeto Compose individual é recriado.

Defina uma rede privada predefinida ou com nome separado para cada aplicação e ligue o respetivo backend e a base de dados. O backend torna-se a ponte controlada entre o tráfego do proxy e o estado privado; o proxy não deve aderir à rede da base de dados.

A documentação das definições de redes Compose documenta as redes externas e a ligação de serviços no Compose. Trate uma rede externa como tendo o ciclo de vida gerido fora da stack da aplicação: a implementação deve verificar se ela existe, em vez de presumir que o Compose a irá criar ou eliminar.

networks:
  proxy:
    external: true
  app-private:
    internal: true
services:
  web:
    networks: [proxy, app-private]
  db:
    networks: [app-private]

Remova portas desnecessárias do anfitrião e reveja o tráfego de saída

Depois de a rota do proxy funcionar, remova as publicações de portas do anfitrião dos backends. A declaração expose pode documentar a porta do contentor, mas não é uma firewall; a pertença à rede determina que contentores podem ligar-se.

Considere internal: true apenas para redes cujos membros não necessitem realmente de uma rota externa. Os backends que contactam fornecedores de identidade, webhooks, serviços de pacotes ou APIs remotas podem falhar numa rede apenas interna. Utilize uma segunda rede com capacidade de saída quando a arquitetura da aplicação o exigir.

Proteja o socket Docker utilizado para a descoberta automática do proxy. Uma montagem bind só de leitura reduz escritas acidentais, mas não torna o socket inofensivo; um proxy de socket restrito ou uma configuração estática oferece uma superfície de controlo mais limitada.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

Verifique o DNS dos serviços, a exposição das portas e o isolamento

A partir do contentor do proxy, resolva o nome do serviço backend e faça um pedido ao respetivo endpoint de estado na porta do contentor. A partir de um contentor não relacionado, confirme que o nome ou a ligação não estão disponíveis, exceto se esse contentor estiver intencionalmente na rede do proxy.

Analise o anfitrião NAS a partir de outro dispositivo da LAN e confirme que apenas as portas do proxy estão abertas. Em seguida, teste TLS, os cabeçalhos encaminhados, as atualizações WebSocket, os carregamentos grandes e os redirecionamentos da aplicação através do nome de anfitrião público. O mapa de serviços do servidor doméstico deve registar a rede do proxy como parte do mapa de serviços do servidor doméstico.

Faça a reversão restaurando o mapeamento de portas anterior apenas para diagnóstico, não como uma dependência oculta permanente. Pare se o proxy necessitar de acesso direto à base de dados, se os aliases encaminharem para o projeto errado ou se a remoção de uma porta do anfitrião interromper uma integração não documentada.

FAQ

Uma rede Docker externa é automaticamente mais segura?

Não. Externa descreve a propriedade do ciclo de vida, não a segurança. Em geral, cada contentor ligado pode comunicar de acordo com o comportamento do controlador de rede e da firewall do anfitrião.

Os serviços backend devem continuar a declarar expose?

É opcional para a conectividade numa rede definida pelo utilizador, mas pode documentar a porta pretendida do contentor. Não publica a porta no anfitrião.

A rede do proxy pode ser marcada como interna?

Apenas se o proxy e a arquitetura de encaminhamento continuarem a ter os caminhos de entrada e saída necessários. Uma rede interna bloqueia a conectividade externa normal dos contentores ligados e pode interromper fluxos de certificados ou de identidade.

Por que motivo utilizar nomes de serviço em vez de endereços IP dos contentores?

Os endereços dos contentores podem mudar após uma recriação. A descoberta de serviços do Docker fornece um nome estável dentro da rede partilhada, tornando a configuração do proxy mais duradoura.

restaure a linha de base guardada, aplique uma vez a configuração aprovada, repita a carga de trabalho semelhante à de produção original, verifique o sinal de sucesso prometido e, em seguida, execute a reversão documentada. Não encerre a alteração até que os registos, a temporização, as permissões, a capacidade e os resultados recuperados correspondam aos critérios de aceitação.