Estou tentando migrar o Discourse de uma hospedagem pessoal para um servidor Amazon LightSail. Pesquisei no fórum e li todas as postagens sobre migração de servidores e configuração do Discourse:
Exportar um backup do Discourse existente (atualmente o backup está configurado para ser salvo no S3, mas entendo que será um backup manual de arquivos)
Importar o backup para o novo Discourse (manualmente, já que, pelo que entendo, ele não consegue recuperá-lo do S3)
Estou um pouco travado em como executar o Passo 1, dado algumas restrições: tenho um único nome de domínio e quero manter o mesmo nome de domínio para o novo servidor, sem qualquer tempo de inatividade (meu objetivo é concluir a configuração do novo servidor, restaurar o backup e, finalmente, alterar a entrada de DNS para apontar para o novo servidor, evitando assim qualquer downtime, já que ambos os servidores estarão rodando ao mesmo tempo).
Conforme entendo, ao configurar o novo servidor Discourse, posso copiar o app.yml do servidor existente para o novo e executar discourse-setup. O problema que vejo aqui é que, ao fazer isso, ele usará o mesmo nome de DNS do servidor existente (o que é o que quero), mas antevendo dois problemas que estou tentando resolver:
O certificado do Let’s Encrypt não gerará um certificado SSL para o novo servidor, já que o nome de domínio ainda aponta para o servidor antigo.
Sem o certificado SSL (a configuração do servidor antigo está definida para usar apenas SSL, o que será mantido no app.yml), o servidor não iniciará.
Já tentei conectar ao servidor Discourse usando uma redireção de nome de DNS, mas se a URL inserida não corresponder à configuração do app.yml, seja o NGINX ou o Discourse não funcionarão; você receberá um erro no navegador ao tentar conectar. Portanto, sem uma interface web, não consigo iniciar o processo de restauração.
Então, como completo a configuração do novo servidor Discourse usando o app.yml do servidor existente e, em seguida, restauro o backup seguido de uma troca de DNS? Ou existe uma maneira diferente e mais fácil de fazer isso?
Se você não for usar o mesmo bucket S3, há uma configuração oculta que força o backup a baixar os arquivos do S3. Você pode procurar o nome dela no arquivo de configurações e defini-la no console do Rails. Existe um tópico que discute isso, mas talvez seja mais fácil procurar no settings.yml.
Você não precisa executar o discourse-setup, basta copiar o app.yml e reconstruir.
Você pode usar o rsync para transferir os certificados do Let’s Encrypt. Na verdade, você pode copiar todo o diretório /var/discourse (talvez excluindo alguns logs e afins).
O objetivo ideal é fazer um ‘lift n shift’, mas isso não é possível com o Amazon Lightsail, já que não é possível importar uma imagem existente. Então, sim, seria usando exatamente o mesmo S3.
Parece que sua abordagem é a mais próxima de um lift n shift. Se entendi corretamente o que você está dizendo, eu posso apenas tar/gz a pasta inteira /var/discourse do servidor original e descompactá-la no novo servidor, seguido de um discourse start, e depois apenas reconfigurar o DNS para apontar para o servidor bee. É só isso? Preciso reconstruir o Discourse no novo servidor? E quanto ao Nginx, Docker e outras dependências fora da pasta?
Sim, mova os arquivos da maneira que fizer mais sentido para você. Sim, você precisará fazer uma nova compilação para construir e iniciar um novo container.
Obrigado. Aparentemente, o ‘lift n shift’ não foi tão limpo quanto eu pensava; há algumas verificações a serem feitas antes e depois para garantir uma operação suave de ‘lift n shift’ (o Postgres estava sendo atualizado da versão 12.0 para a 13.0, o que me ensinou algumas lições no processo de ‘lift n shift’). Aqui está um guia passo a passo para referência futura de quem está tentando migrar para um servidor Amazon LightSail (1GB de RAM):
Servidor Original
Crie um backup no S3
cd /var/discourse
./launcher rebuild # obtenha a versão mais recente para uma transição fácil
./launcher cleanup # limpe para remover dados antigos e reduzir o tamanho do pacote
./launcher stop app # não fazer isso causa falha ao tentar reconstruí-lo depois com o Postgres
tar -zcvf /var/discourse discourse.tar.gz
Novo Servidor Amazon LightSail
Instale a imagem Ubuntu 20.20 na Amazon (1GB de RAM)
Você quer dizer sem executar o discourse-setup ou sem construir o container necessário para rodar o Discourse? Se for o último, é possível empurrar a imagem antiga para um repositório que o novo servidor possa usar, mas isso não é algo que um iniciante consiga lidar facilmente.
Seu processo foi complicado pela atualização do PG13. Talvez tenha sido um pouco mais fácil construir uma nova imagem do zero no novo servidor e fazer backup/restaurar o backup do antigo, mas você ainda teria algumas etapas delicadas para conseguir que o novo servidor obtivesse os certificados do Let’s Encrypt.
Sim, essa é a única coisa que me impedia de executar um ./discourse-setup no novo servidor e depois restaurar a partir da imagem do S3 (e como fazer isso sem acesso ao console de administração da web, já que o DNS ainda estaria apontando para o servidor antigo e, pelo que sei, o Discourse não responde a um endereço IP no navegador). Como eu tinha um sistema em produção e precisava alterar o DNS em tempo real do antigo para o novo sistema, a falta de certificados do Let’s Encrypt era o único obstáculo para mim.
Se houver uma maneira de transferir os certificados do sistema antigo para o novo, concluir o ./discourse-setup sem erros relacionados ao Let’s Encrypt e restaurar a partir do backup do S3 sem usar o console da web, isso seria uma maneira mais simples de fazer isso.
Se você copiar os arquivos yml dentro de containers, não precisará do discourse-setup (ele pode ajustar os parâmetros de memória se forem diferentes no novo servidor, mas você pode fazer isso depois). Basta executar ./launcher rebuild app.
Ok, acho que entendi o que você está dizendo, mas para ter certeza, deixe-me reformular minha compreensão.
No servidor original, ele foi configurado para fazer backup do Discourse no S3 (que são as configurações e o conteúdo do site).
Ao copiar os arquivos yml dos containers, todas as configurações do servidor original serão transferidas para o novo servidor. Assim, no novo servidor, não será mais necessário executar o discourse-setup; em vez disso, executar ./launcher rebuild app usará a configuração do servidor original para baixar a imagem mais recente e configurar o Discourse.
Agora, há duas pendências:
Como transferir os certificados do Let’s Encrypt (já que o DNS ainda está apontando para o servidor original, eles não podem ser recriados, e eu imagino que isso precise ser feito antes de executar ./launcher rebuild app)?
Como restaurar o Discourse (configurações + conteúdo) a partir do backup do S3 após a reconstrução? Como o DNS ainda está apontando para o servidor original, existe uma maneira de acessar a interface web de administração do Discourse usando um endereço IP ou localhost, ou o backup do S3 pode ser restaurado via console?
Obrigado pelas etapas detalhadas, eu só precisei fazer algo semelhante, mudando para um novo host.
Como o site estava funcionando, não quis passar pelos backups, então segui as etapas aqui.
Quase funcionou, mas a reconstrução no novo host falhou.
Acontece que o mapeamento UID/GID não era totalmente o mesmo nos dois hosts, então ao iniciar o Postgres falharia devido à propriedade incorreta da pasta de dados.
Há um detalhe extra para o cenário neste post, que é que o contêiner não é construído, então ./launcher enter app não funciona nesta fase. Como a reconstrução demoraria bastante, pude usar docker ps para obter o nome do contêiner que estava fazendo a construção e, em seguida, entrar no contêiner:
.