Después de realizar algunas pruebas, descubrí que algunos de mis mensajes no muestran las imágenes, incluso antes de realizar ninguna operación de “remapeo”.
En su lugar, muestran un pequeño icono de la imagen, que revela la ruta de la imagen al pasar el cursor sobre él y solo muestra la imagen al hacer clic en ella.
Incluso ese icono desaparece (y en su lugar aparece un espacio en blanco o un marcador de posición de imagen) si selecciono “Reconstruir HTML” en el menú de los tres puntos, o incluso si realizo cualquier operación de “rebake” desde dentro del contenedor.
Si no has realizado un remapeo y tu bucket de S3 sigue funcionando, nada debería haber cambiado con respecto a antes. ¿Esas imágenes funcionaban antes de que comenzaras por este camino?
En teoría, solo perderás la conexión con esos archivos de imagen si desactivas tu bucket de S3 o realizas un remapeo incorrecto.
Gracias.
He descubierto que el icono de la imagen muestra la ruta /bucket/uploads/optimized/folder/… (y como no existe ninguna imagen en esa ruta, la imagen no se muestra, solo aparece el icono).
Pero cuando hago clic en ese icono de imagen, la imagen se muestra/sirve desde la carpeta ‘Orig’, es decir, /bucket/uploads/original/…
No entiendo cómo una sola imagen puede tener almacenadas dos rutas diferentes.
De todos modos, ahora el problema es cómo puedo encontrar las publicaciones que tienen imágenes mapeadas a la ruta incorrecta (bajo ‘optimized’), para poder corregir/remapear sus direcciones a la ruta correcta bajo ‘Original’.
Gracias @nathank, @Pravi, @itsbhanusharma. Como he confundido diferentes problemas/escenarios, actualmente me encuentro en esta situación:
Algunos de mis mensajes no muestran las imágenes que les he subido; en su lugar, o bien muestran un pequeño icono con una URL o dirección de bucket incorrecta cuando paso el ratón por encima, o bien algunos de ellos muestran la imagen correcta y la ruta del bucket correcta SOLO cuando hago clic en esos pequeños iconos. Y, sin embargo, las imágenes de otros mensajes no muestran nada en absoluto, solo un espacio en blanco.
Además, si ejecuto una operación de remapeo (remap wrongbucketurl correctbucketurl), descubrí en una muestra de un mensaje que, aunque por un momento el pequeño icono fue sustituido por la imagen correcta (me puse muy contento), al día siguiente esa imagen desapareció por completo, sin ni siquiera el icono. Solo apareció un espacio en blanco en su lugar. Por eso tuve que restaurar mi sitio web al estado del día anterior.
Cuando ejecuté este comando, el resultado fue el siguiente:
# rake posts:missing_uploads
Buscando subidas faltantes en: default
Faltan 19 subidas de mensajes.
Faltan 19 subidas.
Se ven afectados 6 de 7792 mensajes.
He probado varias variaciones de este proceso unas pocas docenas de veces y aún no funciona.
Nuestras imágenes no se están mostrando desde S3 porque la gerencia ha decidido que no quieren un bucket de S3 con acceso público, por lo que necesitamos volver a usar almacenamiento local.
Inicialmente, inspeccioné los enlaces rotos y logré determinar los valores que necesitaba usar en el remapeo (creía yo), y ahora funcionan muchas imágenes. Pero la mayoría, diría que más del 90%, no funcionan. A diferencia de cuando los enlaces de S3 están rotos y al menos puedes inspeccionarlos para empezar a entender qué está fallando, todo lo que obtengo es esto:
¿Alguien sabe qué podría estar causando que estas imágenes fallen? Llevo días atascado en esto. Me parece increíble que: a) no haya forma de migrar de vuelta y b) alguien (no yo) nos haya migrado cuando no existe una forma de volver.
Para aclarar, he seguido el proceso descrito anteriormente por @nathank. Lo he intentado muchas veces, generalmente con ligeras variaciones en las rutas del paso de remapeo, porque no me queda claro si esas instrucciones son universales o dependen de cómo se vea tu directorio (el nuestro tiene varias subcarpetas que se copiaron correctamente desde S3 usando el paso de sincronización con S3).
Agradecería mucho su ayuda, ya que estoy a punto de volverte loco.
Creo que lo que quieres hacer es activar la opción oculta include_s3_uploads_in_backups, realizar una copia de seguridad y luego restaurarla (lo haría primero en un nuevo servidor de prueba). Esto es lo que sucede cuando un cliente de CDCK cancela su suscripción, y esas copias de seguridad se restauran sin problemas en un nuevo sitio autoadministrado.
NoMethodError: undefined method include_s3_uploads_in_backups=' for SiteSettings:Module from (pry):1:in pry’
Luego me di cuenta de que quizás tenía que volver a activar las cargas en S3 porque las tenía desactivadas, pero aún así obtuve el mismo error.
Ah, usamos dos contenedores y estoy ejecutando esto en web_only. El comando Rails no se encuentra en el contenedor de datos, así que asumo que ese es el enfoque correcto.
Ejecuté ese comando, luego creé una nueva copia de seguridad. La restauré desde esa copia de seguridad, pero no hubo cambios: la mayoría de las imágenes siguen mostrando el icono roto mencionado anteriormente. También intenté reconstruir ambos contenedores, pero esto no marcó ninguna diferencia.
Al descargar e inspeccionar el archivo zip de la copia de seguridad, todos esos archivos definitivamente están allí y, tras la restauración, son visibles en el sistema de archivos. Sin embargo, Discourse simplemente se niega a reconocerlos y mostrarlos.
Para el registro, finalmente logré que esto funcionara. Empecé de cero (es decir, desde una instantánea de mi instancia) y estoy bastante seguro de que el proceso que funcionó al final fue:
usar la consola de rails para ejecutar SiteSetting.include_s3_uploads_in_backups=true
crear una nueva copia de seguridad
restaurar desde esta copia de seguridad
usar discourse remap para actualizar las referencias a mis diversas ubicaciones de archivos S3 a una ubicación local
volver a hornear las publicaciones y reconstruir ambos contenedores de Docker
Gracias @pfaffman por orientarme en la dirección correcta aquí.
EDITAR
Podría mencionar esto también. Después de mi publicación anterior, me di cuenta de que seis de nuestros temas todavía tienen imágenes rotas (aunque la gran mayoría ya están correctas).
Son nuestros seis mensajes más antiguos y todas las imágenes originales tenían una URL de S3 diferente a la de todas las demás. Claramente, esto no es una coincidencia. Así que verifiqué que todos esos archivos estén en el directorio uploads/default/original/1X, y todos están allí. Luego ejecuté un comando remap usando esa URL de S3 única, y eso pareció editar la cantidad correcta de publicaciones. Después volví a hornear y reconstruí los contenedores, pero estos temas siguen rotos. ¿Alguien tiene alguna idea de por qué un pequeño número fallaría de esta manera?
