Peço desculpas se isso já foi perguntado, procurei mas não vi o cenário exato que estou planejando (ou eu perdi, mas quero ter certeza de que acertei, já que nunca fiz isso antes).
Ainda estou na 18 (que é onde comecei; nunca atualizei o sistema operacional Linux antes, apenas as atualizações de segurança), então em breve irei para a 22. Tudo o que li aqui sugere que migrar para uma nova instalação é muito mais inteligente do que atualizar a existente, pois há potencialmente uma infinidade de problemas aleatórios que podem ou não ocorrer, mas não vale a pena o risco, pois se ocorrerem, é apenas um incômodo sem sentido.
Eu li este guia Move your Discourse Instance to a Different Server, mas ele se refere a mover de algum servidor para o DigitalOcean (ou vice-versa), o que torna o Snapshot não aplicável, enquanto eu planejo mover de um Droplet DigitalOcean existente para um novo (o que vi múltiplas referências de que funciona bem e é ideal em vez de uma atualização).
Então, minha pergunta para uma transferência DO>DO é: posso simplesmente desligar meu droplet, tirar um snapshot, iniciar um novo Droplet na versão atualizada do Ubuntu que eu quero, carregar o snapshot e pronto (ajustar o registro DNS para o domínio, etc.)? Basicamente, contornando a “reinstalação completa do Discourse” que o guia detalha. Pelo meu entendimento de snapshots, eles devem ser uma cópia idêntica 1:1 da instalação no Droplet, em vez do backup que é especificamente da sua configuração do Discourse, que requer uma instalação completa para ser realmente utilizado. Estou entendendo isso corretamente? Algum inconveniente além de maior tempo de inatividade?
tl;dr: posso apenas tirar um snapshot, fazer um novo droplet atualizado, carregar o snapshot e pronto?
Espero não estar totalmente errado, mas restaurar um snapshot de 18 em 22 fará com que você volte para 18, porque o snapshot é uma cópia 1:1 de todo o droplet.
Para mim, iniciar um droplet totalmente novo é sempre a última opção, porque preciso instalar tudo o que o Ubuntu (ou qualquer outro SO) precisa, incluindo o sistema de e-mail, etc.
Tenho certeza de que esta é apenas mais uma tarefa trivial para aqueles que sabem, mas depois de 10 anos, nunca aprendi como iniciar um novo droplet funcional facilmente.
Instalar o Discourse leva cerca de 30 minutos, se isso?\n\nBasta fazer um backup do seu site e do app.yml, criar um novo droplet na nova versão do SO, reatribuir o IP ao seu novo droplet (para que o domínio aponte para o lugar certo, novo), instalar o Discourse (você pode sair do assistente e atualizar o app.yml, depois reconstruir) e importar seu backup.\n\nTodo esse processo deve levar menos de uma hora.\n\nEsse processo nunca mexe no seu droplet existente, então, se tudo mais falhar, é fácil reverter?
Se eu estiver migrando de uma versão LTS do sistema operacional para a próxima versão, eu esperaria um processo bastante tranquilo. Então, eu faria um backup - claro - e o baixaria por segurança - claro - e então tentaria a atualização do sistema operacional. Se não funcionasse, eu poderia tentar um sistema operacional novo.
Mas, ao fazer isso, eu teria mais tempo de inatividade do fórum.
Estou um pouco relutante em migrar para uma nova instância principalmente porque precisaria atualizar o DNS e esperar que ele se propagasse. Embora eu veja que a postagem acima diz que eu poderia levar meu endereço IP comigo, o que é bom, e o que elimina essa relutância.
Na verdade, mudando totalmente minha resposta, se eu puder levar meu endereço IP para uma nova instância, isso seria preferível. Possivelmente nem todos os provedores permitem isso. Possivelmente para alguns provedores, perder-se-ia um IP sem custo e começaria a pagar pelo IP, porque ele foi movido, mesmo que não tenha mudado.
Uma mitigação super fácil para isso é apenas definir um TTL muito baixo (ou trocar os servidores de nome para um que suporte isso). Dessa forma, os registros expiram em menos tempo do que leva para reconstruir.
Você pode usar um IP estático (não me lembro como a DigitalOcean os chama agora). Em redes, você pode obter um novo IP e, em seguida, mapeá-lo para o droplet antigo. Em seguida, você altera o DNS e deixa que ele se propague. Quando estiver pronto para mover para o novo servidor, basta mudar o IP para apontar para o novo servidor. Isso acontece imediatamente e, se algo der errado, você pode simplesmente voltar.
Isso faz sentido, eu nem estava pensando que isso moveria o SO junto.
Iniciar um novo droplet seria minha última escolha também, pois nunca movi droplets antes (este é o primeiro que tenho) nem nunca atualizei o SO antes, mas todos os guias que vejo aqui parecem recomendar fazer dessa forma em vez de apenas atualizar o droplet em que estou, então pensei que poderia seguir a maioria se ambos os caminhos tiverem riscos e eu não fiz nenhum deles.
Meu raciocínio também é que, se a atualização der totalmente errado de alguma forma agora, você terá o tempo de inatividade da tentativa, terá o tempo de inatividade enquanto for forçado a tentar consertá-lo (ou desistir e criar um novo), em vez de o novo potencialmente não funcionar enquanto o original permanece em execução e intacto. Não sei por que daria errado, mas pesquisar no meta aqui tem MUITAS pessoas dizendo que deu errado, ou links dizendo que nunca recomendariam dessa forma (além dos guias oficiais aqui e a DigitalOcean sugerem isso).
Correto: se você criar um arquivo app.yml vazio (por exemplo, com touch app.yml no diretório containers) e colar nele (com cuidado!) o conteúdo do seu outro servidor, você não precisará executar ./discourse-setup de forma alguma.
Um problema que me afetou esta semana foi a configuração do meu e-mail: certifique-se de que seu serviço de e-mail não exija o IP exato de onde você está ligando. Se eles exigirem, certifique-se de atualizar essa configuração (no seu provedor de serviços).
É a coisa mais segura a fazer, no entanto. Se você quebrá-lo, seu site antigo continuará funcionando. Não há risco zero.
Existe um tópico sobre isso. Você pode copiar seu arquivo yml e as coisas do let’s encrypt e até ver que funciona alterando seu dns local para apontar para o novo servidor.
E se você tiver seus backups no S3, poderá dormir melhor sabendo que, se algo der muito errado, poderá iniciar um novo servidor e restaurar um backup em cerca de 30 minutos.
Minha única preocupação real não era tanto apenas movê-lo, mas sim passar por toda a configuração e, de alguma forma, estragar alguma configuração, seja o serviço de e-mail ou o letsencrypt ou o quê, e só perceber mais tarde, quando tudo desmoronar. O que obviamente não é um problema se ele puder simplesmente ler meu antigo app.yml, então tudo bem.
Não tenho certeza do que isso significa, mas acho que não… Eu tenho o Mailgun e verificando todos os registros lá/DNS no GoDaddy, nada parece estar vinculado a nenhum IP específico.
Tudo bem, parece fácil o suficiente, vou tentar esta semana. Talvez atualizar para um Droplet melhor ao mesmo tempo.
Não consigo encontrar o tópico que tenho certeza que existe. Em resumo, configure backups no s3 nas suas configurações de ambiente, rsync sobre /var/discourse ou talvez apenas os diretórios ssl e letsencrypt e containers, e então reconstrua.