APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Uma porta descrita por EXPOSE não fica automaticamente publicada no anfitrião. No modo bridge habitual, a publicação liga uma porta e endereço do anfitrião a uma porta do contentor. O endereço em que a aplicação escuta dentro do contentor é outra decisão. Uma aplicação limitada ao seu próprio loopback pode não aceitar tráfego recebido na interface do contentor. Quando há falha, identifica a origem do cliente, o namespace da rede, a porta de destino e o listener efetivo. Não confundas localhost dentro do contentor com localhost do anfitrião. As conclusões desta aula pressupõem contentores Linux com rede bridge, sem modos host ou routed especiais.
Aplicação guiada
Numa aplicação fictícia, API e base de dados partilham uma bridge definida pelo utilizador. A API usa o nome do serviço e a porta interna; publicar a base de dados no anfitrião não é necessário para essa comunicação. Para uma ferramenta acessível apenas no anfitrião, especifica o endereço de loopback em vez de aceitar a publicação ampla por omissão. Verifica a versão e regras da rede: a documentação assinala uma limitação de acesso no mesmo segmento L2 em versões anteriores a 28.0.0. Num diagnóstico, DNS resolvido não prova listener disponível; uma ligação TCP bem-sucedida também não prova autenticação ou resultado funcional. Testa a próxima camada com uma observação específica.
API e db na mesma bridge: db:5432 identifica o destino interno; localhost identifica a própria API.
Armadilhas comuns
EXPOSE como publicação; localhost sem contexto; publicar a base para corrigir DNS.
Tópicos relacionados: Processos e imagens · Build e distribuição · Dados e mounts
Identifica cada limite de rede antes de alterar exposição.
Referência: User-defined bridge networking · Docker Engine Linux containers, BuildKit and Compose; official documentation consulted 2026-09-30; version-dependent behavior explicitly scoped