Temos construído, testado e buscado intencionalmente lacunas em nosso fórum Discourse antes de levar toda a estrutura para produção. Acabei de migrar meu fórum de teste, que tinha uploads no S3 ativados, de um servidor para outro e, ao restaurar, todas as URLs de qualquer coisa anexada foram reescritas para a URL do fórum e não para o S3…
Felizmente, este é um fórum de teste, então não nos importamos muito com os dados. No entanto, gostaria de:
A. Ainda assim corrigir isso.
B. Encontrar uma maneira de mitigar/impedir que isso aconteça em produção.
Não foram apenas as postagens, mas todas as imagens, mídias, conteúdos e avatares (o que é bastante drástico) que foram afetados por isso…
Antes de restaurar, você pode configurar o S3 no site de destino no seu app.yml (não pelo painel de administração). Assim que confirmar que está configurado e que é possível acessar o bucket correto, pode prosseguir com a restauração e as mídias devem ser vinculadas corretamente.
Fizemos exatamente isso e foi assim que acabamos naquela situação.
Copiei o app.yml exatamente como estava para o destino e depois fiz o backup do original. O problema foi a restauração, pois ao restaurarmos, as URLs foram reescritas, mesmo sem nenhuma alteração e com os uploads no S3 ainda ativados.
No final, resolvemos isso com um rebake (acreditamos, pois o cache do Discourse é muito agressivo; entre as várias soluções que tentamos, não sabemos exatamente o que funcionou). No entanto, permanecem sem resposta as questões sobre como realizar migrações com o mínimo de problemas ou mesmo como restaurar a partir de um backup, se necessário, em produção.
Parece que você configurou o S3 via configurações do site, e não por meio de variáveis de ambiente, como Kris sugeriu. O processo de restauração precisa ter conhecimento do S3. Isso não é possível com as configurações do site.
Você também pode criar um backup sem uploads no console, se desejar: discourse backup --sql_only
Restaurar esse tipo de backup não reescreverá as URLs dos uploads. Portanto, desde que seu novo servidor tenha acesso ao mesmo bucket S3, isso funcionará.
A configuração do S3 está no app.yml. Não nas configurações do site.
Edição:
Percebo que não estou sendo muito explicativo e não tenho a intenção de esconder detalhes.
Usamos o S3 da OVH e ele está configurado no app.yml.
Fiz um backup do nosso fórum de testes sem os uploads, mas o S3 ainda estava ativado naquele momento.
Depois, restaurei no novo site com o mesmo app.yml, e foi aí que o problema começou. Para deixar claro, já está resolvido agora, mas não tenho certeza se foi por eu ter refeito o processo várias vezes ou se foi devido ao cache agressivo do Discourse. É por isso que preciso saber como fazer isso corretamente e acertar de primeira. Meu receio é que, se um dia precisarmos restaurar um backup na nossa instância de produção e enfrentarmos isso, eu precise saber exatamente como resolver isso o mais rápido possível, antes que os usuários percebam.
Como eu disse, se você quiser restaurar em um servidor que usa o mesmo bucket do S3, certifique-se de ter o S3 configurado no app.yml e crie um backup sem os uploads (discourse backup --sql_only). Os URLs dos uploads não serão reescritos quando o backup não contiver uploads.
Se você quiser restaurar em um servidor que usa um bucket do S3 diferente ou não tiver nenhuma configuração de S3, use um backup completo com uploads. Os URLs dos uploads serão reescritos durante a restauração.
Você tem 100% de certeza de que configurou o S3 da OVH via ambiente no app.yml em ambos os servidores e usou um backup sem uploads (extensão do arquivo .sql.gz)?
Quando o restaurei inicialmente com os uploads realizados, ele na verdade quebrou, então precisei formatar completamente e começar de novo desta vez, fazendo um backup sem os uploads. Foi aí que o problema começou. Os URLs ainda estavam escritos incorretamente.
Não tenho certeza de como isso aconteceu. O processo de restauração ignora todo o código relacionado aos uploads (incluindo a reescrita das URLs de upload) ao restaurar um arquivo .sql.gz.
Talvez estejamos falando de coisas diferentes? Estou me referindo à coluna url na tabela uploads, que normalmente é //seu-bucket-s3/original/... versus /uploads/original no ambiente local.
Uma ressalva ao restaurar um arquivo .sql.gz é que nenhuma URL é reescrita. Ele espera que o servidor seja acessível pelo mesmo hostname do servidor onde o backup foi criado. Você precisará remapear as URLs se alterar os hostnames.
Nenhum nome de host foi alterado. Apenas os registros A foram atualizados, feitos backup e concluído.
Os avatares dos usuários estavam faltando (e isso aconteceu porque eu não migrei a pasta de uploads). As imagens S3 para anexos/mídia foram reescritas para a URL do fórum. Não a URL do bucket.
Então, embora eu estivesse esperando que as URLs para uploads S3 acima fossem escritas como https://some-bucket-name-here.s3.bhs.io.cloud.ovh.net/optimized, na verdade era https://forum.somedomainhere.com/uploads/optimized, o que, é claro, não vai funcionar.
Posso literalmente criar outra VM novamente e fazer uma restauração direta se você quiser que eu verifique todas as etapas que realizei.
Restaurei fazendo a restauração a partir do arquivo sql.gz que estava armazenado no S3. Até agora, o único problema foi com algumas fotos de perfil de usuários e algumas postagens, mas acho que isso aconteceu porque elas não foram enviadas para o S3 no momento da criação.
Em um ambiente de produção, assumindo que tudo corra bem desde o lançamento e que tudo esteja no S3… se eu fizer uma restauração a partir de um backup, não terei o mesmo problema estranho mencionado na primeira postagem, correto?
