Skip to main content

tasks.<service> | Swarm | Docker

  • tasks.<service> | Swarm | Docker

Definição​

No Docker Swarm, o hostname especial:

tasks.<nome-servico>

é utilizado para resolver todas as instâncias (réplicas) de um serviço.

Diferente do nome padrão do serviço, ele não utiliza VIP (Virtual IP), mas sim retorna diretamente os IPs dos containers.

Contexto de Uso​

O tasks.<service> só existe em ambientes que utilizam Docker Swarm.

Exemplo de criação de serviço com múltiplas réplicas:

docker service create --name api --replicas 3 nginx

Neste cenário:

  • Existe 1 serviço (api)
  • Existem 3 containers (tasks)

Tipos de Resolução DNS no Swarm​

Resolução padrão do serviço​

curl http://api
  • Resolve para um VIP (Virtual IP)
  • O Docker realiza load balancing automaticamente
  • Não expõe diretamente os containers

Resolução via tasks.<service>​

curl http://tasks.api
  • Retorna todos os IPs das réplicas
  • Não há load balancing
  • A aplicação cliente decide como utilizar os IPs

Comparação de Comportamento​

TipoResultadoUso
apiIP virtual (VIP)Load balancing automático
tasks.apiLista de IPs das tasksAcesso direto às instâncias

Exemplo Prático​

Serviço com 3 réplicas:

api.1 → 10.0.0.2
api.2 → 10.0.0.3
api.3 → 10.0.0.4

Usando o nome do serviço​

api → 10.0.0.10 (VIP)

Usando tasks.<service>​

tasks.api → [10.0.0.2, 10.0.0.3, 10.0.0.4]

Funcionamento Interno​

  • O Docker Swarm mantém um DNS interno
  • Quando tasks.<service> é consultado:
    • Ele lista todas as tasks ativas do serviço
    • Retorna múltiplos registros A (IPs)
  • O cliente que faz a requisição decide qual IP utilizar

Casos de Uso​

Comunicação direta entre instâncias​

  • Cluster de banco de dados (ex: PostgreSQL replication)
  • Sistemas distribuídos (ex: Kafka, Elasticsearch)

Service discovery customizado​

  • Aplicações que precisam conhecer todos os nós
  • Balanceamento customizado no cliente

Limitações​

  • Não existe em docker-compose padrão
  • Só funciona em redes do Swarm (overlay network)
  • Não realiza load balancing automático

Relação com docker-compose​

No docker-compose tradicional:

services:
  api:
    image: nginx
  • Apenas api funciona como hostname
  • Não existe tasks.api
  • Não há conceito de múltiplas tasks via DNS

Observações Técnicas​

  • tasks.<service> funciona apenas dentro da mesma network
  • Requer que o serviço esteja ativo
  • DNS é atualizado dinamicamente conforme escala do serviço