Skip to main content

Promoção de worker para manager no Docker Swarm | Swarm | Docker

  • Promoção de worker para manager no Docker Swarm | Swarm | Docker

No Docker Swarm, um node pode atuar como:

PapelFunção
workerExecuta containers/tasks
managerGerencia o cluster, participa do Raft, agenda tasks e pode virar leader

Promover um worker para manager significa permitir que aquela máquina participe do controle do cluster.

Quando promover um worker para manager​

Você deve promover um worker quando precisar aumentar a tolerância a falhas do Swarm.

Exemplo ruim:

1 manager
1 worker

Se o único manager morrer:

o worker não vira leader
não existe eleição
o Swarm perde gerenciamento

Exemplo melhor:

3 managers
N workers

Se um manager morrer:

os managers restantes elegem um novo leader
o cluster continua gerenciável

Verificar os nodes atuais​

No manager atual, rode:

docker node ls

Exemplo:

ID                            HOSTNAME     STATUS   AVAILABILITY   MANAGER STATUS
abc123                        manager-1    Ready    Active         Leader
def456                        worker-1     Ready    Active

Nesse exemplo:

NodePapel
manager-1Manager líder
worker-1Worker

Promover worker para manager​

No node que já é manager, execute:

docker node promote worker-1

Ou usando o ID do node:

docker node promote def456

Depois valide:

docker node ls

Saída esperada:

ID                            HOSTNAME     STATUS   AVAILABILITY   MANAGER STATUS
abc123                        manager-1    Ready    Active         Leader
def456                        worker-1     Ready    Active         Reachable

Agora o worker-1 virou manager.

Entendendo o status Reachable​

Depois da promoção, o novo manager normalmente aparece como:

Reachable

Isso significa:

o node é manager
está acessível
participa do quorum
pode virar leader se necessário

O leader atual continua sendo o mesmo, a menos que haja uma nova eleição.

Antes e depois da promoção​

Antes:

manager-1  -> Leader
worker-1   -> Worker

Depois:

manager-1  -> Leader
worker-1   -> Reachable

Agora você tem:

2 managers
0 workers

Ou seja: a máquina promovida deixou de ser apenas worker e passou a fazer parte do plano de controle.

Atenção com 2 managers​

Ter 2 managers não é uma boa configuração de alta disponibilidade.

Com 2 managers:

quorum necessário = 2

Se qualquer um morrer:

sobra 1 manager
não há quorum
não há eleição válida

Por isso, o ideal é ter número ímpar de managers.

ManagersQuorumPode perder
110
220
321
532
743

O padrão mais comum para produção pequena é:

3 managers

Adicionar mais um manager novo​

Se você já promoveu seu worker e ficou com 2 managers, adicione uma terceira máquina como manager.

No manager atual, gere o token:

docker swarm join-token manager

O Docker vai retornar um comando parecido com:

docker swarm join \
  --token SWMTKN-1-xxxxxxxxxxxxxxxxxxxxxxxx \
  10.0.0.10:2377

Na terceira máquina, execute exatamente o comando retornado:

docker swarm join \
  --token SWMTKN-1-xxxxxxxxxxxxxxxxxxxxxxxx \
  10.0.0.10:2377

Depois confira:

docker node ls

Resultado esperado:

HOSTNAME     STATUS   AVAILABILITY   MANAGER STATUS
manager-1    Ready    Active         Leader
manager-2    Ready    Active         Reachable
manager-3    Ready    Active         Reachable

Portas necessárias entre os nodes​

Para o manager conseguir se comunicar corretamente com os outros nodes, libere as portas internas do Swarm entre as máquinas.

PortaProtocoloUso
2377TCPGerenciamento do Swarm
7946TCP/UDPComunicação entre nodes
4789UDPRede overlay/VXLAN

Exemplo com UFW, liberando por IP interno:

sudo ufw allow from 10.0.0.11 to any port 2377 proto tcp
sudo ufw allow from 10.0.0.11 to any port 7946 proto tcp
sudo ufw allow from 10.0.0.11 to any port 7946 proto udp
sudo ufw allow from 10.0.0.11 to any port 4789 proto udp

Repita para cada node do cluster.

Verificar se o node virou manager​

Use:

docker node ls

Procure a coluna:

MANAGER STATUS

Possíveis valores:

ValorSignificado
LeaderManager líder atual
ReachableManager saudável e disponível
UnreachableManager inacessível
vazioWorker

Exemplo:

HOSTNAME     STATUS   AVAILABILITY   MANAGER STATUS
manager-1    Ready    Active         Leader
manager-2    Ready    Active         Reachable
worker-1     Ready    Active

Nesse caso:

NodePapel
manager-1Manager líder
manager-2Manager secundário
worker-1Worker

Demover manager para worker​

Caso você precise voltar um manager para worker:

docker node demote nome-do-node

Exemplo:

docker node demote manager-2

Depois confira:

docker node ls

O campo MANAGER STATUS deve ficar vazio para aquele node.

Diferença entre promote e join-token manager​

Existem duas formas de ter mais managers:

ComandoQuando usar
docker node promoteQuando a máquina já está no cluster como worker
docker swarm join-token managerQuando a máquina ainda não entrou no Swarm

Exemplo:

Máquina já está no Swarm​

docker node promote worker-1

Máquina ainda não está no Swarm​

No manager atual:

docker swarm join-token manager

Na nova máquina:

docker swarm join --token TOKEN IP_DO_MANAGER:2377

Checklist prático​

1. Ver nodes atuais​

docker node ls

2. Promover worker existente​

docker node promote worker-1

3. Validar status​

docker node ls

Esperado:

worker-1    Ready    Active    Reachable

4. Adicionar terceiro manager​

docker swarm join-token manager

Na terceira máquina:

docker swarm join --token TOKEN IP_DO_MANAGER:2377

5. Validar cluster final​

docker node ls

Esperado:

manager-1    Leader
manager-2    Reachable
manager-3    Reachable

Recomendação para produção​

Evite:

1 manager + 1 worker

Também evite:

2 managers

Prefira:

3 managers
N workers

Para seu caso, o desenho mínimo mais seguro seria:

manager-1  -> Leader
manager-2  -> Reachable
manager-3  -> Reachable
worker-1   -> Worker, opcional

Com 3 managers, se o leader morrer:

um dos Reachable vira Leader
o cluster mantém quorum
o Swarm continua gerenciável