Skip to main content

Propriedades de Porta no Docker Swarm | Swarm | Docker

  • Propriedades de Porta no Docker Swarm | Swarm | Docker

Visão geral​

No Docker Swarm, a exposição de serviços é controlada principalmente por três propriedades:

  • target
  • published
  • mode

Essas propriedades definem como o tráfego entra no cluster e chega até o container.

Estrutura básica​

ports:
  - target: 8080
    published: 5000
    protocol: tcp
    mode: host

target​

Define a porta interna do container, ou seja, onde a aplicação está escutando.

target: 8080

Características​

  • Refere-se ao processo dentro do container
  • Não depende do host
  • Pode ser repetido em múltiplos containers sem conflito
  • Deve bater com a configuração da aplicação

Exemplo com .NET​

No .NET 8:

ASPNETCORE_URLS=http://+:8080

Então:

target: 8080

Erro comum​

target: 80

Quando a aplicação está em 8080:

  • Resultado: connection refused

published​

Define a porta exposta no host (node físico).

published: 5000

Características​

  • É a porta que o cliente acessa
  • Está vinculada à máquina física
  • Pode causar conflito se duplicada no mesmo node
  • Precisa estar liberada na rede

Exemplo prático​

http://10.0.0.1:5000
  • 10.0.0.1 → node
  • 5000 → published

Conflito de porta​

Node1:
- Serviço A → 5000
- Serviço B → 5000

Resultado:

  • erro de bind
  • container não sobe

mode​

Define como o tráfego chega até o container.

mode: host

Existem dois modos principais:

  • host
  • ingress

mode: host​

mode: host

Comportamento​

  • Porta aberta diretamente no node
  • Sem load balancing do Swarm
  • Sem routing mesh
  • A requisição vai direto para o container local

Fluxo​

Client → NodeIP:5000 → Container:8080

Implicações​

    • menor latência
    • ideal para WebSocket (SignalR)
    • controle total pelo API Gateway
    • não há balanceamento automático
    • depende de saber quais nodes estão ativos

Cenário real​

NodeContainer
node1sim
node2não

Acessos:

node1:5000 → funciona
node2:5000 → falha

mode: ingress​

mode: ingress

Comportamento​

  • Swarm cria um load balancer interno (routing mesh)
  • Qualquer node responde
  • Tráfego pode ser redirecionado para outro node

Fluxo​

Client → NodeIP:5000 → Swarm → Container em qualquer node

Implicações​

    • simplicidade
    • não precisa conhecer nodes
    • latência maior
    • double load balancing (se usar API Gateway)
    • pode impactar WebSocket

Comparação direta​

Propriedadehostingress
Load balancingexternointerno (Swarm)
Latênciamenormaior
WebSocketmelhorpior
Controlealtobaixo
Simplicidademédiaalta

Combinação das propriedades​

Exemplo completo​

ports:
  - target: 8080
    published: 5000
    mode: host

Interpretação:

  • Aplicação escuta em 8080
  • Host expõe 5000
  • Sem load balancing interno

Cenários comuns​

API com gateway externo​

mode: host
  • Gateway faz o balanceamento
  • Swarm apenas orquestra

Aplicação simples (sem gateway)​

mode: ingress
  • Swarm faz o balanceamento

Múltiplos serviços na mesma máquina​

api1 → published: 5000
api2 → published: 5001
  • Evita conflito de porta

Boas práticas​

  • Alinhar target com a porta real da aplicação
  • Padronizar published por serviço
  • Evitar ingress quando já existe API Gateway
  • Usar mode: host para workloads com WebSocket
  • Garantir que portas estejam liberadas na rede

Exemplo completo de serviço​

version: "3.9"

services:
  api:
    image: minha-api
    ports:
      - target: 8080
        published: 5000
        protocol: tcp
        mode: host
    deploy:
      mode: global
      placement:
        constraints:
          - node.labels.role == api

Fluxo final consolidado​

Client
  ↓
API Gateway
  ↓
NodeIP:5000 (published)
  ↓
Container:8080 (target)
  ↓
Aplicação (.NET)