Skip to main content

Internal | Network | Docker

  • Internal | Network | Docker

Conceito de rede internal​

No Docker, ao definir:

networks:
  internal:
    internal: true

você cria uma rede com isolamento de tráfego externo.

Comportamento técnico:

  • Não há roteamento externo (NAT desabilitado)
  • Containers não são acessíveis diretamente pelo host
  • Comunicação restrita apenas entre containers da mesma rede
  • Não há exposição automática de portas, mesmo com ports configurado (dependendo do ambiente)

Objetivo do internal​

A rede internal existe para:

  • Isolar serviços sensíveis
  • Impedir acesso externo acidental
  • Separar camadas da arquitetura (edge vs core)
  • Reduzir superfície de ataque

Diferença prática​

Rede padrão (bridge)​

networks:
  default:
    driver: bridge
  • Permite acesso externo via ports
  • NAT habilitado
  • Uso geral

Rede internal​

networks:
  internal:
    internal: true
  • Sem acesso externo direto
  • Sem NAT de entrada
  • Uso restrito a comunicação interna

Comportamento com ports​

Esse é o ponto mais importante.

Cenário 1 — Apenas internal​

service:
  networks:
    - internal
  ports:
    - "8080:80"

Possível comportamento:

  • Container sobe normalmente
  • Porta aparece no docker ps
  • Mas acesso via localhost falha

Motivo:

  • A rede não permite tráfego externo de entrada de forma consistente em todos os ambientes

Cenário 2 — Internal + Bridge​

service:
  networks:
    - internal
    - public
  ports:
    - "8080:80"

Resultado:

  • Porta acessível externamente
  • Comunicação interna preservada
  • Arquitetura correta

Fluxo de comunicação​

Apenas internal​

Container A ↔ Container B
  • Comunicação interna OK
  • Sem acesso externo

Híbrido (correto)​

Host → Container (via public)
               ↓
         internal network
               ↓
        outros containers

Limitações importantes​

1. Dependência do ambiente​

Em ambientes como:

  • Docker Desktop (Windows / Mac)

O comportamento pode ser mais restritivo:

  • Port binding pode falhar
  • Acesso via localhost pode não funcionar
  • Debug mais difícil

2. Não substitui firewall​

internal: true não substitui:

  • firewall do sistema
  • regras de cloud (ex: security groups)
  • proxy reverso

3. Não impede saída (egress)​

Dependendo da configuração:

  • containers ainda podem acessar internet
  • o bloqueio é principalmente de entrada

Boas práticas​

  • Use internal para serviços que não devem ser expostos
  • Combine com uma rede pública para serviços de entrada
  • Evite usar internal sozinho em serviços com ports
  • Valide sempre com testes reais de conexão

Exemplos de uso​

Correto​

networks:
  public:
  internal:
    internal: true

services:
  gateway:
    networks:
      - public
      - internal

  database:
    networks:
      - internal

Incorreto​

service:
  networks:
    - internal
  ports:
    - "8080:80"
  • Porta pode não responder
  • Comportamento inconsistente

Diagnóstico rápido​

Verificar portas​

docker ps

Testar acesso​

curl http://localhost:8080

Se falhar​

Verificar:

  • serviço conectado apenas à rede internal
  • ausência de rede pública
  • ambiente Docker (Desktop vs Linux)

Quando usar internal​

  • bancos de dados
  • sistemas de fila
  • serviços internos
  • componentes de infraestrutura

Quando evitar​

  • APIs públicas
  • gateways
  • serviços acessados via browser
  • aplicações com ports expostos