Para este artigo é necessário ter acesso SSH a ambas as VPS. O foco será em users com ssh keys e acesso a todo o diretório de origem e destino. Idealmente, cada user tem acesso ao respetivo diretório no servidor em causa mas nada mais. Ou seja, é de evitar ao máximo utilizar o root ou outro user com maior acesso.
A título de exemplo vamos clonar o site brunocarrada.pt da delta.vps para o rc3.
TODO: Criar ssh-keys e configs poderia ficar noutro artigo e este apenas fazer referência
1. Criar ssh config
O host delta.vps.root é apenas um alias que pode ser utilizado para autocomplete no cmder. É possível escrever “ssh delta.” e depois carregar tab para ter autocomplete. Desta forma, colocamos primeiro o nome do servidor, para ter autocomplete com os users que temos acesso. Embora se escrevessemos o commando sem config seria ao contrário: ssh root@136.244.111.227
A config é apenas um ficheiro chamado “config” na pasta .ssh do user windows que nos encontramos logados. No meu caso o user é KLG e o absolute path é: “C:\Users\KLG\.ssh\config”
2. Pedir acesso root ao delta.vps ao Ivo
Neste momento podemos testar na consola: ssh delta.vps.root ou ssh rc3.brunocarradapt mas vamos ser bloqueados ou ter que introduzir uma password. Para o login ser automático é preciso dar a chave pública ao Ivo para ficar nas authorized_keys do server. É o conteúdo do ficheiro id_rsa.pub
3. Criar o site no rc3 através da runcloud
Na runcloud criamos o site: brunocarrada.pt seguindo os padrões usuais. Isto é:
3.1 Tentar trackar na runcloud o tipo de aplicação, neste caso, wordpress, embora depois vamos apagar toda a informação mas ficamos com o tracking de que é um site wordpress e também fica já linkada a webapp à base de dados que é útil nos backups e onde é necessária a associação
3.2 app, user, database, database user como brunocarradapt
A password deverá ter 60 caractéres, sem símbolos. É importante guardar estes dados para depois.
3.3 Como não é um subdomínio criamos também a versão www mas sem forçar o servidor a redirecionar
3.4 O SSL começa sem autorenew porque vamos ter que propagar e ligar depois
3.5 O PHP mais avançado embora provavelmente temos que alterar posteriormente
3.6 O nome do blog, e-mail do admin e a informação do wordpress é irrelevante dado que depois vamos apagar a base de dados e todos os ficheiros
4. Adicionar ssh key no destino e testar
No rc3 em SSH, adicionei uma nova chave com a label: brunocarradapt_KLG_Ivo, para saber que é uma chave para o user brunocarradapt, no meu computador KLG e que é do Ivo. É para seguir esta nomenclatura embora já tenha criado algumas sem convenção que vou apagar depois.
Agora podemos testar fazer “ssh rc3.brunocarradapt” e se estiver tudo bem configurado devemos entrar diretamente sem password e na consola deve aparecer algo do género:
brunocarradapt@vmi1399153:~$
O que significa que estamos no server “vmi1399153” logados como brunocarradapt
5. Primeiro Rsync
Vamos então fazer o primeiro rsync para colocar a pasta de destino no rc3 exatamente igual à pasta de origem da delta.vps
O comando será:
ssh root@136.244.111.227 "rsync --checksum --archive --verbose --compress --progress --delete /var/www/brunocarrada.pt/home/brunocarrada.pt/public/ brunocarradapt@184.174.32.101:/home/brunocarradapt/webapps/brunocarradapt/" --dry-run Aqui é preciso ter muito cuidado dado que um erro no rsync com acesso root pode causar muitos problemas, incluindo, a destruição duma VPS inteira. Tipicamente nunca vamos querer usar o root mas neste caso estou a usar porque a delta.vps é para descontinuar e não justifica trabalho adicional nesta fase. No rc3 estamos mais tranquilos porque estamos a usar um user que não é o root, mas sim o user brunocarradapt que está limitado à sua pasta e desta forma os danos possiveis são limitados ao site em questão.
Muito importante o primeiro IP ser o de origem e o segundo IP o de destino. Os paths devem ser absolutos, ou seja, devem começar por uma slash, e terminar também numa slash.
O –dry-run é fundamental para correr uma vez e observar o que acontece na consola.
O comando deve ser copy pasted para um notepad primeiro para confirmar que está correto e tudo numa linha. Depois então podemos fazer paste na consola e ver o output.
Obtive o seguinte erro:
Host key verification failed.
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(235) [sender=3.1.3]Isto porque coloquei no servidor rc3 a minha chave mas o delta.vps também precisa de acesso ao rc3. Para isto vamos adicionar outra chave na runcloud, desta vez, é a chave com o nome “delta_vps_normal_user” e vamos dar-lhe o label: brunocarradapt_delta_vps_normal_user que indica que podemos aceder ao rc3 através do delta.vps que é necessário para fazer o rsync.
Temos ainda que logar na delta.vps com ssh delta.vps.root e fazer ssh brunocarradapt@184.174.32.101 e dizer “yes”. E verificar que estamos no server certo. Na verdade era preciso ver o fingerprint mas não vamos fazer isso agora.
Executei novamente o rsync e já funcionou. Apareceram uma série de ficheiros que iam ser passados de um lado para o outro. Aparantemente está ok, então fiz o mesmo comando mas desta vez sem o –dry-run
Correu tudo bem, e isto significa que acabámos de replicar tods os ficheiros da origem para o destino.
6. Confirmar que a origem e o destino são exatamente iguais
Para já ainda não é fundamental porque ainda vamos fazer um novo rsync, no entanto, para experiência vamos testar se as pastas origem e destino têm exatamente os mesmos ficheiros, e se os ficheiros têm exatamente o mesmo conteúdo. Para isto, corremos o seguinte comando:
ssh brunocarradapt@184.174.32.101 "(cd /home/brunocarradapt/webapps/brunocarradapt/ && find . -type f -print0 | sort -z | xargs -0 sha256sum | sha256sum)"O resultado foi: 9bfee7b0425a365e28f84483a039c14a3e3534e7758605574c027afbc3ae1620
ssh root@136.244.111.227 "(cd /var/www/brunocarrada.pt/home/brunocarrada.pt/public/ && find . -type f -print0 | sort -z | xargs -0 sha256sum | sha256sum)"
O resultado foi: 9bfee7b0425a365e28f84483a039c14a3e3534e7758605574c027afbc3ae1620
Se forem exatemente iguais, é porque os ficheiros e conteúdo é exatamente igual, caso contrário não são. A título de exemplo podem mudar um enter num ficheiro qualquer, e confirmar que a checksum deixa de ser igual.
Guardar estes comandos para mais tarde voltar a executar após o segundo rsync.
7. Propagar A record, matar php-fpm, dump mysql, rsync2, ligar SSL
Estes passos devem ser sincronizados com o Ivo. A partir do momento em que propagarmos o A record para o novo IP vamos ter downtime portanto é importante ter tudo preparado e executar estes passos todos de seguida e o mais rápido possível para evitar downtime.
Para este passo, é fundamental os NS já estarem na vultr. Se estiverem, a propagação é feita no máximo em 300 segundos. Após o Ivo ter iniciado a propagação para o rc3, já podemos passar para os restantes passos.
Poderíamos colocar o site em manutenção mas se não for um site muito sobrecarregado podemos simplesmente matar o phpfpm e remover o serviço. Para isso, vamos correr o seguinte comando, logado na delta.vps.root
systemctl list-units --type=service | grep -i brunocarrada
Estranhamente, obtive 2 serviços:
php7.3-fpm-brunocarrada.pt.service
php7.4-fpm-brunocarrada.pt.service
Vamos fazer parar os serviços com o comando:
sudo systemctl stop php7.3-fpm-brunocarrada.pt.service
Depois voltar a repetir o comando acima para verificar que realmente pararam. Depois fazer disable dos serviços com o comando:
sudo systemctl disable php7.3-fpm-brunocarrada.pt.service
Não esquecer de repetir para o 7.4. Tipicamente, vamos só ter um php. Na runcloud devemos então alterar para o php7.4 e se correr mal o 7.3.
Ainda no mesmo servidor fazer o dump da base de dados, correndo o comando:
mysqldump brunocarradapt > /var/www/brunocarrada.pt/home/brunocarrada.pt/public/brunocarradapt.sql
O nome da base de dados deve seguir a convenção, caso não siga, é consultar no wp-config.php ou no ficheiro que contenha a ligação para a base de dados.
Neste momento podemos correr novamente o comando do rsync anterior e desta vez deverá ser ainda mais rápido porque só se vão sincronizar os ficheiros que foram alterados desde o primeiro rsync até ter desligado o php, se nada tiver sido alterado só o sql é que vai passar para o destino. É de notar que este comando é corrido no nosso computador, não no servidor delta.vps.
Agora ligamos ao servidor rc3.brunocarradapt e podemos correr o comando para importar a base de dados. Antes disso é importante ligar ao phpmyadmin com o user e pass do brunocarrada no rc3 para apagar as tabelas todas, importar com o comando, e confirmar que realmente apareceram lá novas tabelas.
Neste caso, utilizei o subdominio: rc3pma.deltasolucoes.com para ligar ao phpmyadmin do rc3, caso não saibam, falar com o Ivo.
Desta forma, aproveitei para testar que a base de dados está a funcionar, apaguei as tabelas, e importei a base de dados no rc3 com o seguinte comando:
mysql brunocarradapt -p < /home/brunocarradapt/webapps/brunocarradapt/brunocarradapt.sql
Desta vez tenho que colocar a password. Depois fui ao phpmyadmin novamente e confirmei que aparecem lá as novas tabelas importadas.
Agora é preciso ir ao runcloud ligar fazer deploy do SSL e ligar o auto-renew. É importante fazer este passo por último para aguardar pelo menos 300 segundos para propagar ou este passo vai falhar.
O cerificado foi deployed, e liguei o auto-renew nos settings.
8. Alterar config, apagar sql e verificar se está tudo bem
Neste momento, já consigo ver o site com SSL ligado mas dá um erro de ligação à base de dados. Vou ao wp-config.php alterar para os novos dados do rc3.
Já estou a ver o site e parece estar tudo ok. Não esquecer de apagar o sql que está no diretório público!
Ligar ao wp-admin para ver se está tudo bem, numa janela privada ver se o site funciona bem, se aparecem erros na consola, e por aí fora. Como extra, podemos ver se está muito desatualizado. Tipicamente é bom não fazer updates porque pode estragar o site, mas é importante saber se está tão desatualizado que devemos proceder a uma atualização em breve.
Antes de mais, pedir ao Ivo para ligar os backups. Assim já fica uma cópia feita, para o caso de querermos tentar algo arriscado como fazer updates de plugins ou do core. Em sites mais antigos, é muito normal que hajam erros ao fazer upgrade.