Migración de alojado a autoalojado: las cargas anteriores todavía hacen referencia a la infraestructura de Discourse

Soporte
1

Comprobado: Images lost when migrating to self-hosting, posts:rebake no hace nada bueno.

Problema
Seguimos las instrucciones oficiales y creamos una instancia de Lightsail, desde allí hicimos una descarga de la base de datos desde la interfaz de usuario de Discourse y la aplicamos para obtener un 80% de avance. La idea era migrar a la instancia autoalojada manteniendo viva la versión anterior.

Una vez que tengamos una copia en vivo del antiguo foro. Comenzamos a migrar las imágenes. Para hacerlo, primero cancelamos nuestra suscripción para obtener y migrar nuestras imágenes.

A medida que se subieran nuevas imágenes a la instancia autoalojada, solo necesitaríamos subir desde la instancia alojada antes de la fecha de transición. Esto significa que nunca usamos el volcado de la base de datos que vino con nuestras imágenes y cancelación; ya que ya habíamos hecho la migración, ya había expirado.

Observo tres comportamientos relacionados con este punto en el tiempo.

  1. Los recursos referenciados en la copia de seguridad (volcado de SQL, específicamente) apuntan a la infraestructura de Discourse.
  2. Los recursos referenciados *creados desde entonces en la copia de seguridad, por ejemplo, imágenes de nuevas publicaciones, están correctamente referenciados y se encuentran en nuestra infraestructura.

En consecuencia, si vuelvo a subir un recurso que resulta en el mismo hash, se vinculará a la infraestructura de Discourse. Por ejemplo: intentar arreglar el favicon subiéndolo de nuevo no funciona. Sin embargo, puedo subir cualquier otra imagen aleatoria, y funcionará.

Estado actual
Según entiendo, upload://<X> pasa por la decodificación b62 (¿y sha1?) para mapearla a la carpeta public/uploads. Tenemos todas esas imágenes:

El volcado que nos proporcionó el equipo de Discourse contiene un zip con default/original/1X y actualmente se puede ver en /var/www/discourse/public/uploads/default/original/1X. Esta última carpeta ahora contiene 329 elementos, el volcado proporcionado contenía 249 elementos; eso me parece bien.

Eso significa que los datos deberían ser descubribles, incluso si no puedo encontrar la carga directamente en la carpeta. Estoy tratando de entender esta relación, para poder arreglar el mapeo de alguna manera. Inicialmente, solo parecía una simple sustitución de cadenas, y eso funcionó para algunas imágenes. Sin embargo, algunas ahora han sido reemplazadas por un transparent.png, donde antes solo había una imagen inaccesible.

4

Si la nueva cocción falló, deberías intentar un remap para buscar/reemplazar todas las referencias a la infraestructura de Discourse y reemplazarlas con enlaces relativos.

5

¡Gracias Richard!

Para aclarar, mediante: Replace a string in all posts

Usando

rake posts:remap["buscar","reemplazar","cadena",true]

Haz

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

El reemplazador alternativo a relativo sería "https://forum.everviz.com/uploads/default/"

¿Es el enlace relativo lo que tienes en mente?

e: corrección de url relativa con /

En una línea:

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

¡se ve bien! querrás añadir una barra delante

/uploads/default/

7

¿Comprobaste incluir todas las subidas al hacer la copia de seguridad de tu sitio alojado? Si estabas alojado con CDCK, solía haber una configuración oculta que necesitaban habilitar antes de que pudieras hacer una copia de seguridad con todas las subidas incluidas. No estoy seguro de si eso ha cambiado ahora, pero definitivamente querrás coordinarte con tu proveedor de alojamiento antes de realizar la migración para asegurarte de que estás haciendo una copia de seguridad completa (y no solo un volcado de SQL).

8

Mi proveedor de alojamiento era Discourse, estábamos en un plan mensual. La interfaz de usuario alojada dice que me ponga en contacto con team@discourse.com para obtener los archivos cargados. Su respuesta fue que necesito cancelar la suscripción para obtener los archivos.

Pero sí, como se mencionó, recibí uploads/original/1X

9

Es un buen consejo, pero es posible que ya lo haya hecho:

root@...:/var/www/discourse$ rake posts:remap["//cdck-file-uploads-europe1.s3.dualstack.eu-west-1.amazonaws.com/standard21/uploads/everviz/","/uploads/default/"]
¿Está seguro de que desea reemplazar todas las ocurrencias de la cadena '//cdck-file-uploads-europe1.s3.dualstack.eu-west-1.amazonaws.com/standard21/uploads/everviz/' con '/uploads/default/'? (S/n)
S
Remapping
¡0 publicaciones reasignadas!

Los enlaces solían ser https://europe1.discourse-cdn.com/standard21/uploads/everviz/ en el foro alojado. Esto es, por supuesto, lo mismo, solo que a través de la CDN. Intentemos reasignar.

1 publicación reasignada.

Encuentro esta imagen curiosa:

image
image2272×1242 357 KB

Por supuesto, esto fue antes de ejecutar todos estos comandos hoy y antes de publicar aquí. Se envió al equipo de Discourse antes de que ejecutara algunas tareas de rake y demás.

10

¿Hiciste eso? Tienen que activar una configuración oculta que descargará las imágenes de S3 y las incluirá en tu copia de seguridad. Una copia de seguridad normal no incluye las imágenes, sino solo enlaces a ellas en sus buckets S3. Cancelar una suscripción activa eso automáticamente, creo, pero he tenido clientes a los que se les activó la configuración simplemente pidiéndolo. Deberías cancelar tu suscripción o preguntar de nuevo.

Si no quieres hacerlo de esa manera, entonces necesitarás escribir un script que descargue las imágenes de S3 y actualice la base de datos de Discourse en consecuencia.

11

Cancelé y recibí los archivos. Aunque parece que la copia de seguridad original de la base de datos de Discourse hace referencia a la ruta en S3. Esencialmente, tengo todo lo que necesito en /var/www/discourse/uploads/original/1X.

Utilicé un volcado de SQL descargado manualmente para poblar la instancia, no el que se proporcionó con los archivos. Me preocupaba que este último pudiera proporcionar rutas corregidas a las imágenes, lo cual he verificado que no es el caso.

Para demostrar:


![](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">

Lo anterior es un caso especial donde la referencia anterior a cdck… es solo transparent.png. Sin embargo, puedes abrir el enlace y ver que existe.

12

Así que esperaría tener problemas.

En lo que supongo que es una publicación raw que incluiste, con la base de datos incluida con los archivos, esperaría que el ![](upload://3Qa5S9sUTcc42dT4EFAbz5K0iJP.gif) se refiera a tu almacenamiento local, pero si alguien pegó explícitamente un enlace a una imagen en su bucket, se necesitaría hacer algo para solucionarlo. Si la imagen existiera y tuvieras la configuración de descarga a local activada, la imagen del bucket se descargaría (dado que cumpliera los criterios de configuración).

No estoy muy seguro de cómo se pudo haber generado la última </img> en tu ejemplo.

13

La descarga a nivel local está habilitada.

Para el archivo enlazado, el volcado de despedida ‘oficial’ no incluye rutas relativas.

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

Esta referencia exacta al archivo también apunta a cdck… en algunos lugares.

Me parece un poco una locura, pero podría hacer una copia de seguridad ahora. Y luego descartar las referencias a la infraestructura de Discourse para la ruta local en el propio volcado, y volver a subirlo.

El último archivo podría hacer referencia a transparent.png porque he vuelto a cocinar la publicación, y el archivo de origen ya no era localizable en la infraestructura de Discourse. No creo que estemos ante una pérdida total de datos.

14

Si tu sitio está en línea, entonces simplemente entrarías y arreglarías cosas en Rails, en la medida de lo posible.

Pero esa <img es una publicación procesada, ¿verdad? ¿No la publicación sin procesar?

15

La imagen es de la copia de seguridad de la base de datos. Supongo que cocinada. La publicación sin procesar hace referencia a b62 como upload://

La publicación cocinada actual es:

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

Hasta ahora no he tenido mucho éxito con rake para encontrar y arreglar subidas faltantes, reasignar y volver a hornear publicaciones.

¡Gracias Jay por toda tu ayuda!

16

El archivo al que se hace referencia en la publicación procesada funciona. No hay ningún problema con eso.

Si está buscando en las publicaciones procesadas en el volcado de la base de datos, entonces está buscando en el lugar equivocado.

Ahora tiene un sitio en vivo, así que necesita trabajar a partir de ahí.

¿Qué ve en la publicación sin procesar? Después de un rebake de esa publicación, ¿qué muestra la publicación procesada que no es lo que espera?

Sin saber exactamente lo que hizo, y lo que hay en las publicaciones (sin procesar y procesadas), no hay mucha manera de ayudar. Dado que comenzó con una base de datos que se espera que no tenga los datos correctos, este tema no será útil para otros.

17

Hice lo que todos me dijeron que no hiciera: meterme con la base de datos y su volcado. Actualmente, casi todo funciona, excepto en algunos 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">

Calculemos el b62 y tomemos su hexadecimal

npqpp5O0wbL89nR9OXtP7Btu4hc = 0x a411c90267cafca7a1cbcd7c8f4f9b8db17e51ba

Ahora intente find desde /var/www/discourse/public/uploads:

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

¡Sí!

932×164 18.5 KB

Pero, ¿por qué es transparent.png en la publicación? He ejecutado rake uploads:recover_from_tombstone y rake posts:rebake

¿Cómo llegué aquí?

La columna de subidas en la base de datos, para la tabla url, todavía mostraba cdck como parte de la URL de origen de las imágenes. Entré en la base de datos desde dentro del contenedor:

postgres psql discourse

Luego

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/%';

Esto mostró resultados prometedores, donde la mayoría de las imágenes originales y miniaturas reaparecerían.

Un paso más: modificar los archivos de volcado
La suposición es que Discourse es sin estado* y lo único que nos importa es lo que está dentro de la base de datos. No estaba ansioso por jugar con tareas de rake o ruby para esto, ya que no estoy muy familiarizado con ninguno de ellos ni con los internos de Discourse. Solo quiero resultados, rápido.

*Aparte de la carpeta public que contiene nuestras imágenes. Sin embargo, podemos confirmar que tenemos todo lo que necesitamos.

Así que descargamos una copia de la base de datos desde la UI, luego la abrimos en VSCode y sustituimos progresivamente las referencias a cdck (bucket) y europe1 (bucket de CDN).

Por progresivamente me refiero a que en algunos casos verías ‘//…’ y en otros casos verías ‘https://’. Por lo tanto, primero debes hacer coincidir y reemplazar ‘//…’, de lo contrario, tendrás https: al final del archivo.

Luego, vuelve a cargar el volcado modificado. Parte de lo que hizo que todo esto fuera complicado es el paso base62, que hace que sea un poco más difícil pasar de una representación en bruto a la URL de imagen real.

18

Tarea completada

Después de verificar el tamaño de la tabla de subidas, noté que faltaban algunos cientos de entradas. No sé en qué paso desaparecieron. Me fusioné con la copia de seguridad de la base de datos del pasado con una unión SQL básica de una tabla temporal.

Como mencioné anteriormente, la URL que se solicita para una imagen es la que se almacena en la tabla de subidas, columna url. Desde la consola de Rails, reasigné estas referencias de CDN a nuestro dominio local con SQL sobre la tabla de subidas.

Por qué no usar la tarea rake

Probablemente haya algunas que estén bien y alguna composición de ellas funcionaría. Sin embargo, cuando puedes observar el comportamiento actual, sabes lo que quieres y sabes cómo llegar allí; entonces encuentro que la limitación es arbitraria.

Quiero agradecer al equipo de Discourse y a los voluntarios aquí, que me han proporcionado las piezas de información que necesitaba para descubrir la solución, que terminó consistiendo en algunos pasos.

1 me gusta
19

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