Skip to main content

Se for necessário migrar todos os deploys de um servidor para outro, deve-se seguir o seguinte procedimento (considerando que o servidor antigo ainda está acessível via SSH -- se não estiver, o buraco é mais embaixo e o procedimento é outro).

PROCEDIMENTO

Preparar o novo servidor. Deve ser feito como se fosse um novo servidor normal (vide ACCINFRA-A-6).

Adicionar a chave SSH do servidor antigo (cat /root/.ssh/id_ed25519.pub) na lista de chaves autorizadas do servidor novo (nano /root/.ssh/authorized_keys -- colar a chave no final do arquivo).

Parar todos os containers no servidor antigo. Pode-se usar o comando /root/docker/scripts/docker-stopEverything.sh.

Pra cada deploy a ser migrado:

  1. copiar os dados para o servidor novo usando rsync (rsync /root/docker/deploy.accelerobr.com.br root@novoservidor.iongrade.com.br:/root/docker/ -r)
  2. acertar as entradas DNS para que o nome do deploy aponte para o novo servidor (/root/docker/scripts/dns_update_entry.sh <SUBDOMINIO_SEM_accelerobr.com.br> <SERVIDOR.iongrade.com.br>)
  3. acertar manualmente as rotas do BrokerDiscovery pra apontar diretamente para o IP do servidor novo a fim de agilizar a migração dos controladores (/root/docker/scripts/brokerdiscovery_upsert_route.sh <FACILITY> <MQTT_PORT> <MQTT_PORT_TLS> <IP_SERVIDOR_NOVO>)
  4. acessar https://letsdebug.net/ e checar se já aconteceu propagação DNS do domínio (cliente.accelerobr.com.br). Pra isso, basta digitar o domínio na caixinha, rodar o teste, clicar em Show verbose information e conferir se o IP reportado logo no início é o IP do servidor novo. Enquanto isso não estiver OK, não seguir para o próximo passo!
  5. iniciar o deploy (up.sh)
  6. conferir se está no ar. Talvez seja necessário alterar o seu arquivo hosts (/etc/hosts ou C:\Windows\System32\drivers\etc\hosts) pra forçar a resolução de IP momentaneamente.

Duas partes são demoradas: cópia dos arquivos (etapa 1) e propagação DNS (etapa 2). Essas etapas podem ser feitas ao mesmo tempo pra agilizar.

Você também pode atualizar o DNS de todos os deploys de uma só vez no início (depois de parar os containers) pra agilizar o processo.

Ao final de tudo, fique à vontade pra dar um shutdown no servidor antigo, mas NÃO O EXCLUA. Deixe ele lá parado por um tempo, porque pode ser necessário acessá-lo em algum momento.

RECOMENDAÇÕES

MENSAGEM DE REBOOT NO MQTT ANTIGO​

Logo após colocar no ar cada deploy no servidor novo, religue os containers mariadb e mqtt do servidor antigo (apenas eles) e envie uma mensagem retained em broadcast com instrução de reboot. Isso forçará qualquer controlador que se conecte nesse broker a refazer o processo de brokerdiscovery.

mosquitto_pub -h servidorantigo.iongrade.com.br -p PORTADEPLOY -t 'FACILITY/broadcast/to' -m '{"cmd":"rEbOoT"}' -r

CACHE DE DNS NO ROTEADOR DO CLIENTE​

Pode ser necessário instruir o cliente a reiniciar o roteador. Alguns modelos fazem cache de DNS com TTL infinito (nunca atualiza). Fique esperto com isso.

APOSENTADORIA DO SERVIDOR ANTIGO​

Espere pelo menos 72h para efetivamente excluir o servidor antigo. É o tempo pra você descobrir que faltou algo. Coloque um lembrete no Outlook/celular.

ESTIMATIVAS

A dor de cabeça desse processo é imensurável. Não faça esse processo.

Mas se tiver que fazer...

Você não vai levar menos que uma hora. Conte com no mínimo duas horas e desligue o celular durante o processo. Foco 100% nesse problema, porque a chance de algo dar errado é muito grande, e o custo do erro também é imensurável.

E tenha um amiguinho do lado.