Migração de hospedado para auto-hospedado: uploads anteriores ainda referenciam infra do discourse

Suporte
1

Verificado: Images lost when migrating to self-hosting, posts:rebake não faz nada de bom.

Problema
Seguimos as instruções oficiais e criamos uma instância Lightsail, a partir daí fizemos um download do banco de dados da interface do Discourse e o aplicamos para obter 80% do caminho. A ideia era migrar para a instância auto-hospedada mantendo a variante anterior ativa.

Uma vez que tenhamos uma cópia ativa do antigo fórum. Começamos a migrar as imagens. Para fazer isso, primeiro cancelamos nossa assinatura para obter e migrar nossas imagens.

Como novas imagens seriam carregadas na instância auto-hospedada, precisaríamos apenas carregar da instância hospedada antes da data de transição. Isso significa que nunca usamos o dump do banco de dados que veio com nossas imagens e cancelamento; como já tínhamos feito a migração, ele já estava expirado.

Observo três comportamentos relacionados a este ponto no tempo.

  1. Recursos referenciados no backup (dump SQL, especificamente) apontam para a infraestrutura do Discourse
  2. Recursos referenciados* desde a criação no backup, por exemplo, imagens de novas postagens, são referenciados corretamente e encontrados em nossa infraestrutura

Consequentemente, se eu recarregar um recurso que resulta no mesmo hash, ele será vinculado à infraestrutura do Discourse. Por exemplo: tentar corrigir o favicon carregando o mesmo não funciona. No entanto, posso carregar qualquer outra imagem aleatória, e ela funcionará.

Estado atual
Pelo que entendi, o upload://<X> passa por decodificação b62 (e sha1?) para mapeá-lo para a pasta public/uploads. Temos todas essas imagens:

O dump que nos foi fornecido pela equipe do Discourse contém um zip com default/original/1X e ele pode ser visto atualmente em /var/www/discourse/public/uploads/default/original/1X. Esta última pasta agora contém 329 itens, o dump fornecido continha 249 itens—isso me parece bom.

Isso significa que os dados devem ser descobertos, mesmo que eu não consiga encontrar o upload diretamente na pasta. Estou tentando entender essa relação, para que eu possa corrigir o mapeamento de alguma forma. Inicialmente, parecia apenas uma substituição simples de string, e isso funcionou para algumas imagens. Algumas agora foram substituídas por um transparent.png, onde antes era apenas uma imagem inacessível.

4

Se o rebake falhou, você deve tentar um remap para pesquisar/substituir todas as referências à infraestrutura do Discourse e substituí-las por links relativos.

5

Obrigado, Richard!

Para esclarecer, por: Replace a string in all posts

Usando

rake posts:remap["encontrar","substituir","string",true]

Faça

rake posts:remap[
  "https://cdck-file-uploads-europe1.s3.dualstack.eu-west-1.amazonaws.com/standard21/uploads/everviz/",
  "/uploads/default/"
]

O substituto alternativo para relativo seria "https://forum.everviz.com/uploads/default/"

O link relativo é o que você está pensando?

e: correção de URL relativa com /

Linha única:

rake posts:remap["https://cdck-file-uploads-europe1.s3.dualstack.eu-west-1.amazonaws.com/standard21/uploads/everviz/", "/uploads/default/"]
6

parece bom para mim! você vai querer adicionar uma barra na frente

/uploads/default/

7

Você verificou incluir todos os uploads ao fazer o backup do seu site hospedado? Se você estava hospedado com a CDCK, havia uma configuração oculta que eles precisavam habilitar antes que você pudesse fazer um backup com todos os uploads incluídos. Não tenho certeza se isso mudou agora, mas você definitivamente vai querer coordenar com seu provedor de hospedagem antes de fazer a migração para garantir que você está fazendo um backup completo (e não apenas um dump de SQL).

8

Meu provedor de hospedagem era o Discourse, estávamos em um plano mensal. A interface hospedada diz para contatar team@discourse.com para obter os arquivos carregados. A resposta deles foi que preciso cancelar a assinatura para obter os arquivos.

Mas sim, como mencionado, recebi uploads/original/1X

9

É uma boa dica, mas talvez eu já a tenha feito:

root@...:/var/www/discourse$ rake posts:remap["//cdck-file-uploads-europe1.s3.dualstack.eu-west-1.amazonaws.com/standard21/uploads/everviz/","/uploads/default/"]
Tem certeza de que deseja substituir todas as ocorrências da string '//cdck-file-uploads-europe1.s3.dualstack.eu-west-1.amazonaws.com/standard21/uploads/everviz/' por '/uploads/default/'? (S/n)
S
Remapeando
0 posts remapeados!

Os links costumavam ser https://europe1.discourse-cdn.com/standard21/uploads/everviz/ no fórum hospedado. Isso é, claro, a mesma coisa, apenas acessado através do CDN. Vamos tentar remapear.

1 post remapped.

Acho esta imagem curiosa:

image
image2272×1242 357 KB

Claro, isso foi antes de executar todos esses comandos hoje e antes de postar aqui. Foi enviado para a equipe do Discourse antes de eu executar algumas tarefas rake e assim por diante.

10

Você fez isso? Eles precisam ativar uma configuração oculta que fará o download das imagens do S3 e as incluirá em seu backup. Um backup normal não inclui as imagens, mas apenas links para elas em seus buckets S3. Cancelar uma assinatura aciona isso automaticamente, eu acho, mas tive clientes que tiveram a configuração ativada simplesmente pedindo. Você deve cancelar sua assinatura ou pedir novamente.

Se você não quiser fazer isso dessa maneira, precisará escrever um script que fará o download das imagens do S3 e atualizará o banco de dados do Discourse de acordo.

11

Eu cancelei e recebi os arquivos. Embora pareça que o backup original do banco de dados do discourse referencia o caminho no S3. Essencialmente, tenho tudo o que preciso em /var/www/discourse/uploads/original/1X.

Usei um dump SQL baixado manualmente para popular a instância, não o fornecido com os arquivos. Fiquei preocupado que este último pudesse fornecer caminhos corrigidos para as imagens, o que agora verifiquei não ser o caso.

Para demonstrar:


![](upload://3Qa5S9sUTcc42dT4EFAbz5K0iJP.gif) = 1aec065017da50538fe5866ae91a6396185234e1.gif

https://forum.everviz.com/uploads/default/original/1X/1aec065017da50538fe5866ae91a6396185234e1.gif

http://cdck-file-uploads-europe1.s3.dualstack.eu-west-1.amazonaws.com/standard21/uploads/everviz/original/1X/1aec065017da50538fe5866ae91a6396185234e1.gif

<img src="https://forum.everviz.com/images/transparent.png" alt="" data-orig-src="upload://3Qa5S9sUTcc42dT4EFAbz5K0iJP.gif" role="presentation" width="1" height="1" style="aspect-ratio: 1 / 1;" loading="lazy">

O acima é um caso especial onde a referência anterior a cdck… é apenas transparent.png. Independentemente disso, você pode abrir o link e ver que ele existe.

12

Então eu esperaria ter problemas.

No que eu assumo ser um post raw que você incluiu, com o banco de dados incluído nos arquivos, eu esperaria que o ![](upload://3Qa5S9sUTcc42dT4EFAbz5K0iJP.gif) se referisse ao seu armazenamento local, mas se alguém explicitamente colasse um link para uma imagem em seu bucket, algo precisaria ser feito para consertar isso. Se a imagem existisse e você tivesse a configuração de download-para-local ativada, a imagem do bucket seria baixada (dado que ela atendesse aos critérios da configuração).

Não tenho certeza de como a última <img> em sua amostra poderia ter sido gerada.

13

O download para o local está habilitado.

Para o arquivo vinculado, o dump “oficial” de despedida não inclui caminhos relativos.


<img src="https://europe1.discourse-cdn.com/standard21/uploads/everviz/original/1X/1aec065017da50538fe5866ae91a6396185234e1.gif" alt="" data-base62-sha1="3Qa5S9sUTcc42dT4EFAbz5K0iJP" ...

Essa referência exata de arquivo também aponta para cdck… em alguns lugares

Parece um pouco insano para mim, mas eu poderia fazer um backup agora. E então descartar as referências à infraestrutura do Discourse para o caminho local no próprio dumpfile e reenviá-lo.

O último arquivo pode referenciar transparent.png porque eu recompilei a postagem, e o arquivo de origem não era mais detectável na infraestrutura do Discourse. Não acho que estamos diante de uma perda completa de dados.

14

Se o seu site estiver no ar, você simplesmente entraria e corrigiria as coisas no Rails, na medida do possível.

Mas essa <img é uma postagem processada, certo? Não a postagem bruta?

15

A imagem é do dump do banco de dados. Presumo que esteja cozida. A postagem bruta referencia o b62 como upload://

O cozido atual é:

<img src="https://forum.everviz.com/images/transparent.png" alt="" data-orig-src="upload://3Qa5S9sUTcc42dT4EFAbz5K0iJP.gif" ...

Até agora, não tive muito sucesso com o rake para encontrar e corrigir uploads ausentes, remapear e refazer postagens.

Obrigado Jay por toda a sua ajuda!

16

O arquivo referenciado na postagem processada funciona. Não há problema com isso.

Se você está procurando nas postagens processadas no dump do banco de dados, então você está procurando no lugar errado.

Você tem um site ativo agora, então precisa trabalhar a partir dele.

O que você vê na postagem bruta? Após um novo processamento dessa postagem, o que a postagem processada mostra que não é o que você espera?

Sem saber exatamente o que você fez e o que está nas postagens (bruta e processada), não há muita maneira de ajudar. Como você começou com um banco de dados que se espera que não tenha os dados corretos, este tópico não será útil para outras pessoas.

17

Fiz o que todos me disseram para não fazer: mexer no banco de dados e em seu dumpfile. Atualmente, quase tudo funciona, exceto em alguns casos de:

<img src="https://forum.everviz.com/images/transparent.png"
alt="image" data-orig-src="upload://npqpp5O0wbL89nR9OXtP7Btu4hc.png"
width="517" height="90" style="aspect-ratio: 517 / 90;" loading="lazy">

Vamos calcular o b62 e pegar seu hex

npqpp5O0wbL89nR9OXtP7Btu4hc = 0x a411c90267cafca7a1cbcd7c8f4f9b8db17e51ba

Agora tente find em /var/www/discourse/public/uploads:

find . -name '*a411c90267cafca7a1cbcd7c8f4f9b8db17e51ba*'
./default/original/1X/a411c90267cafca7a1cbcd7c8f4f9b8db17e51ba.png

Sim!

932×164 18.5 KB

Mas por que é transparent.png na postagem? Eu executei rake uploads:recover_from_tombstone e rake posts:rebake

Como cheguei aqui?

A coluna uploads no banco de dados, para a tabela url, ainda mostrava cdck como parte da URL de origem para as imagens. Entrei no banco de dados de dentro do container:

postgres psql discourse

Então

UPDATE uploads
SET url = REPLACE(
           url,
           '//cdck-file-uploads-europe1.s3.dualstack.eu-west-1.amazonaws.com/standard21/uploads/everviz/',
           '/uploads/default/'
         )
WHERE url LIKE '//cdck-file-uploads-europe1.s3.dualstack.eu-west-1.amazonaws.com/standard21/uploads/everviz/%';

Isso mostrou resultados promissores, onde a maioria das imagens originais e miniaturas reapareceria.

Um passo adiante: modificando dumpfiles

A suposição é que o Discourse é stateless* e a única coisa com que precisamos nos preocupar é o que está dentro do banco de dados. Eu não estava ansioso para mexer com tarefas rake ou ruby para isso, pois não estou muito familiarizado com nenhum deles ou com os internos do Discourse. Eu só quero resultados, rápido.

*Exceto pela pasta public, que contém nossas imagens. Podemos, no entanto, confirmar que temos tudo o que precisamos.

Então, baixamos uma cópia do banco de dados da UI, depois a abrimos no VSCode e substituímos progressivamente as referências cdck (bucket) e europe1 (bucket do CDN).

Por progressivamente, quero dizer que em alguns casos você veria ‘//…’ e em outros casos você veria ‘https://’. Portanto, você precisa corresponder e substituir ‘//…’ primeiro, caso contrário, você terá https: redundantes em todo o arquivo.

Em seguida, faça o upload do dumpfile modificado. Parte do que tornou tudo isso complicado foi a etapa de base62, que torna um pouco mais difícil ir de uma representação bruta para a URL real da imagem.

18

Tarefa concluída

Após verificar novamente o tamanho da tabela de uploads, notei que faltavam algumas centenas de entradas. Não sei em que etapa elas desapareceram. Mesclei o backup do banco de dados do passado com um join SQL básico de uma tabela temporária.

Como posso ter mencionado acima, a URL solicitada para uma imagem é aquela armazenada na tabela de uploads, coluna url. Do console do Rails, remapeei essas referências de CDN para nosso domínio local com SQL sobre a tabela de uploads.

Por que não usar a tarefa rake

Provavelmente existem algumas que estão OK e alguma composição delas funcionaria. No entanto, quando você pode observar o comportamento atual, sabe o que quer e sabe como chegar lá — então acho a limitação arbitrária.

Quero agradecer à equipe do Discourse e aos voluntários aqui, que me forneceram as informações necessárias para descobrir a solução, que acabou consistindo em algumas etapas.

1 curtida
19

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.