Rehacer publicaciones antiguas no cargará la nueva URL de CDN de S3 después de renombrar el bucket de S3

Después de instalar Discourse (2.7.0.beta1) e importar publicaciones antiguas de Google Groups, agregué la configuración del bucket/clave de S3 (pero sin URL de CDN) y ejecuté

rake uploads:migrate_to_s3

lo cual parecía funcionar perfectamente. Todas las imágenes se subieron a S3 y Discourse intentaba acceder a ellas mediante una URL de S3 generada automáticamente, algo así como

https://ortus-discourse.s3.dualstack.us-west-2.amazonaws.com/original/1X/75747ca17a3ca01f298f836691e1990916bafccb.png

Luego renombré el bucket (a ortus-discourse-uploads) y configuré una distribución de Cloudfront frente a él con un CNAME configurado en Cloudflare llamado

https://communitycdn.ortussolutions.com/

El CNAME, Cloudfront y S3 funcionan perfectamente. URLs como esta sirven correctamente una de las imágenes del bucket:

https://communitycdn.ortussolutions.com/original/1X/75747ca17a3ca01f298f836691e1990916bafccb.png

Sin embargo, el problema es que Discourse está completamente atascado en el antiguo dominio ortus-discourse.s3.dualstack.us-west-2.amazonaws.com (que no funciona debido al cambio de nombre del bucket) y, sin importar cuántas veces reconstruya el contenedor o vuelva a hornear las publicaciones antiguas, no puedo lograr que Discourse use la nueva URL de CDN. He buscado en Google durante un día y he vuelto a hornear probablemente una docena de veces (dentro del contenedor app) con diversas configuraciones. Cada hilo del foro da el mismo consejo: reconstruir y volver a hornear, pero no funciona.

No solo están rotas las imágenes en las publicaciones; incluso la etiqueta <link rel="icon" type="image/png" href=""> y el logotipo del sitio están atascados en el antiguo dominio y no usan la URL de CDN de S3.

Aquí están mis configuraciones actuales de S3.

  DISCOURSE_S3_ACCESS_KEY_ID: '********'
  DISCOURSE_S3_SECRET_ACCESS_KEY: '******'
  DISCOURSE_BACKUP_LOCATION: 's3'
  DISCOURSE_ENABLE_S3_UPLOADS: true
  DISCOURSE_S3_BUCKET: 'ortus-discourse-uploads'
  DISCOURSE_S3_UPLOAD_BUCKET: 'ortus-discourse-uploads'
  DISCOURSE_S3_BACKUP_BUCKET: 'ortus-discourse-backups'
  DISCOURSE_S3_REGION: 'us-west-2'
  DISCOURSE_S3_CDN_URL: https://communitycdn.ortussolutions.com

  DISCOURSE_CDN_URL: https://community.ortussolutions.com

Incluso intenté volver a mapear la URL antigua a la nueva en las publicaciones de la siguiente manera:

rake posts:remap["ortus-discourse.s3.dualstack.us-west-2.amazonaws.com","communitycdn.ortussolutions.com"]

pero el comando indicó que 0 publicaciones fueron afectadas.

En ninguna parte de mis variables de entorno ni en la configuración de la base de datos tengo nada que haga referencia al antiguo nombre del bucket ortus-discourse, por lo que no puedo entender de dónde sigue obteniendo Discourse esa información. Soy nuevo en Discourse y no soy desarrollador de Ruby, así que no he profundizado más allá de lo que puedo ver en mi archivo app.yml, la interfaz de administración y la salida de los comandos rake que he encontrado en los foros.

¿Cuál es el valor de esas subidas en la tabla Uploads?

./launcher enter app
rails c
Upload.all.sample(10).pluck(:url)

@Falco Gracias por la respuesta. Aquí está la salida de ese comando.

root@discourse-app:/var/www/discourse# rails c
Upload.all.sample(10).pluck(:url)
[1] pry(main)> Upload.all.sample(10).pluck(:url)
=> ["//ortus-discourse.s3.dualstack.us-west-2.amazonaws.com/original/1X/52b3aff4e63a7e38bef42d469bafd1ed7c1cc1a2.png",
 "//ortus-discourse-uploads.s3.dualstack.us-west-2.amazonaws.com/original/1X/9f90374a280a4681332bcd2191b8de43462f8776.png",
 "//ortus-discourse.s3.dualstack.us-west-2.amazonaws.com/original/1X/29691fba566fc998a966aa93859753e3cf0b8528.cfc",
 "//ortus-discourse-uploads.s3.dualstack.us-west-2.amazonaws.com/original/1X/6ae912ced40d60adc1356c1d7acf144b0fa0985a.jpeg",
 "//ortus-discourse-uploads.s3.dualstack.us-west-2.amazonaws.com/original/1X/4dfe5b48fc8cb5d79880d70355c34d7ed02be812.png",
 "//ortus-discourse-uploads.s3.dualstack.us-west-2.amazonaws.com/original/1X/897c4b4e755c1c8e93224a27187dc631a02e4388.png",
 "//ortus-discourse-uploads.s3.dualstack.us-west-2.amazonaws.com/original/1X/59886f322e6834b567d473138108fab6e0f33764.png",
 "//ortus-discourse-uploads.s3.dualstack.us-west-2.amazonaws.com/original/1X/e3e3429d63155cf0d850e161846d187bc6f273ea.jpeg",
 "//ortus-discourse.s3.dualstack.us-west-2.amazonaws.com/original/1X/1b701869b4b235daa8d6a9a7728766f3b4e69814.txt",
 "//ortus-discourse-uploads.s3.dualstack.us-west-2.amazonaws.com/original/1X/c83aaee941462d47ef91f0c6448257d07487b231.png"]
[2] pry(main)>

Así que hay bastantes archivos con el antiguo bucket, efectivamente.

El remapeo que necesitas debería ser:

./launcher enter app
rails c
DbHelper.remap("ortus-discourse.s3.dualstack.us-west-2.amazonaws.com", "ortus-discourse-uploads.s3.dualstack.us-west-2.amazonaws.com")

Por favor, realiza una copia de seguridad antes, ya que no hay forma de deshacer esta operación.

@Falco Gracias de nuevo. Ejecuté dos remapeos:

DbHelper.remap("ortus-discourse.s3.dualstack.us-west-2.amazonaws.com", "communitycdn.ortussolutions.com")
DbHelper.remap("ortus-discourse-uploads.s3.dualstack.us-west-2.amazonaws.com", "communitycdn.ortussolutions.com")

Reconstruí la imagen y eso solucionó problemas como el logotipo del encabezado del sitio. Estoy reconstruyendo todos los publicaciones nuevamente para ver si se arreglan las imágenes de los mensajes, pero esto tomará un tiempo.


Mientras esperamos la reconstrucción, ¿qué salió mal aquí? ¿Es un error en Discourse que hizo que mis subidas se quedaran atascadas en la URL antigua y no pudieran cambiar a la nueva?

Leí publicaciones como esta que hablaban sobre cambiar una URL de CDN, pero solo mencionaban reemplazar cadenas en los mensajes (lo cual no funcionó) y no mencionaban en absoluto el remapeo de DBUtil. How do I change the legacy CDN URLs of images in posts?

Incluso intenté volver a ejecutar el script rake de importación a S3, pero recibí un error (lo siento, no tomé nota de ello en ese momento).

Incluso encontré un script rake migrate_from_s3 que casi ejecuto para ver si podía empezar desde cero, pero luego encontré una publicación en el foro aquí que indicaba que arruinaría mi base de datos si lo ejecutaba, así que lo dejé quieto.

No sé qué debería haber hecho diferente o qué publicación en el foro me habría respondido esto. (¡Realmente intenté resolver esto por mi cuenta antes de publicar aquí!)

Lamentablemente, el rebake no parece haber solucionado las imágenes incrustadas en los mensajes. Lo interesante es que si selecciono un mensaje antiguo y lo edito, veo la imagen representada de la siguiente manera:

![COMMANDBOXERROR.png|1169x984](upload://yTDVQSa4wbIeLGEZvE7muXe8sAJ.png)

pero al visualizar el mensaje, solo hay un gran espacio vacío en el mismo que apunta a

https://community.ortussolutions.com/images/transparent.png

Este es un cambio relativamente reciente. La mayor parte de ayer, estas imágenes simplemente apuntaban a la antigua URL incorrecta de S3, pero en algún momento anoche o hoy apareció el PNG transparente.

Hmmmm, eso no es lo que te dije que hicieras en mi respuesta :face_with_raised_eyebrow:

En la tabla de uploads esperamos la ubicación de S3, y solo se reemplaza por la CDN durante el proceso de cocción del markdown.

Tú pusiste la CDN en la tabla de Uploads, y eso no es lo que el software hace normalmente.

Lo siento por eso. Asumí que no habías leído lo suficientemente bien la publicación original para ver que mencionaba la distribución de Cloudflare y que necesitaba ajustarla para usar mi URL real. No me di cuenta de que la URL no deseada estaba almacenada en la base de datos. Casi te respondo preguntando si eso era lo que querías decir, pero parecía obvio lo que tenía que hacer.

No te preocupes, puedo volver a mapear esas URLs fácilmente a la URL de S3. Esta es una instalación nueva de Discourse y todo el contenido subido está en el mismo lugar, así que es fácil cambiarlo.

Mis preguntas sobre lo que salió mal en mi publicación anterior siguen vigentes.

Creo que es tan simple como que no admitimos cambiar el bucket de Object Storage.

“Admitir” aquí significa que no puedes cambiarlo y esperar que funcione, y no hay ninguna guía escrita ni tarea rake preempaquetada para ello. Así que si terminas necesitando cambiar un bucket, será necesario realizar algunas manipulaciones en la base de datos.

Vale, tiene sentido. Lo que hice y que resultó ser el gran problema fue cuando renombré el bucket de S3 y asumí que actualizar el nombre del bucket en el panel de administración resolvería todo lo necesario. Quizás sería útil incluir una advertencia en la interfaz de administración al editar el nombre del bucket. (Empecé configurando las opciones en la interfaz de administración antes de cambiar al uso de variables de entorno, pensando que eso podría ayudar de alguna manera). Ciertamente no estaba claro que cambiar el nombre del bucket después de la carga podría causar problemas.

He vuelto a mapear los dominios al dominio correcto de AWS S3.

DbHelper.remap("communitycdn.ortussolutions.com", "ortus-discourse-uploads.s3.dualstack.us-west-2.amazonaws.com")
[1] pry(main)> Upload.all.sample(10).pluck(:url)
=> ["//ortus-discourse-uploads.s3.dualstack.us-west-2.amazonaws.com/original/1X/fc05f9be9b783479819fec68b1d8e493110007a4.cfc",
 "/images/d-logo-sketch-small.png",
 "//ortus-discourse-uploads.s3.dualstack.us-west-2.amazonaws.com/original/1X/50f0d6f260cdb4ef91e29023d92b46df096ab34e.cfc",
 "//ortus-discourse-uploads.s3.dualstack.us-west-2.amazonaws.com/original/1X/65d80cddc6dc15b9a4d1b9e9d88cc9a8928c5316.png",
 "//ortus-discourse-uploads.s3.dualstack.us-west-2.amazonaws.com/original/1X/a86aa2a12183428f3289caa95787ea16f22e2e4d.png",
 "//ortus-discourse-uploads.s3.dualstack.us-west-2.amazonaws.com/original/1X/9f76b5238b147a60c8ad5f65bd7fa4bb6b58d852.png",
 "//ortus-discourse-uploads.s3.dualstack.us-west-2.amazonaws.com/original/1X/6a4c9b992e6cd8a15ddeaec0d158ebd473164525.zip",
 "//ortus-discourse-uploads.s3.dualstack.us-west-2.amazonaws.com/original/1X/3a532dec6390d5087ed6154fc0335c2c0f1ea543.zip",
 "//ortus-discourse-uploads.s3.dualstack.us-west-2.amazonaws.com/original/1X/93420848249ecea2261d405e46f7f450cc02a3af.txt",
 "//ortus-discourse-uploads.s3.dualstack.us-west-2.amazonaws.com/original/1X/d67c39e06ce624b9deb7625dd041d21cffd96df9.png"]

He vuelto a compilar la aplicación y ahora estoy regenerando las publicaciones. Veremos si la trigésima séptima vez es la de la suerte :slight_smile:

Todas las cargas tienen la URL correcta del bucket de S3, el contenedor se ha reconstruido y los 30 mil publicaciones se han vuelto a generar. Aún veo

/images/transparent.png

en lugar de todas mis imágenes.

Al editar las publicaciones, esto es lo que sigue apareciendo:

![COMMANDBOXERROR.png|1169x984](upload://yTDVQSa4wbIeLGEZvE7muXe8sAJ.png)

Lo curioso es que otros archivos adjuntos, como los archivos zip, ahora funcionan correctamente.

¿Falta algún paso necesario para que las imágenes incrustadas en las publicaciones antiguas funcionen?

¿Puedes imprimir los atributos del objeto Upload correspondiente a yTDVQSa4wbIeLGEZvE7muXe8sAJ?

Me encantaría ayudarte, pero necesitaré algo de asistencia con este caso. Soy desarrollador, pero no de Ruby. He descubierto cómo imprimir todos los atributos de una subida aleatoria de la siguiente manera:

[17] pry(main)> Upload.all.sample(1)
=> [#<Upload:0x00005633230f8af0
  id: 353,
  user_id: 273,
  original_filename: "helloWorldF.zip",
  filesize: 50542,
  width: nil,
  height: nil,
  url: "//ortus-discourse-uploads.s3.dualstack.us-west-2.amazonaws.com/original/1X/3a532dec6390d5087ed6154fc0335c2c0f1ea543.zip",
  created_at: Wed, 30 Dec 2020 18:46:31 UTC +00:00,
  updated_at: Wed, 30 Dec 2020 18:46:31 UTC +00:00,
  sha1: "3a532dec6390d5087ed6154fc0335c2c0f1ea543",
  origin: nil,
  retain_hours: nil,
  extension: "zip",
  thumbnail_width: nil,
  thumbnail_height: nil,
  etag: nil,
  secure: false,
  access_control_post_id: nil,
  original_sha1: nil,
  animated: nil,
  verification_status: 1>]

He encontrado algunas referencias para Active Record de ROR para buscar registros específicos, pero no he encontrado ningún dato allí que se parezca remotamente a yTDVQSa4wbIeLGEZvE7muXe8sAJ. ¿Cómo puedo encontrar el registro de subida correspondiente?

¡Oh, buenas noticias! Mientras investigaba cómo encontrar los registros de carga, me topé con este post que me mostró cómo convertir la cadena base62 al hash sha1.

Mencionaba que las imágenes que solo mostraban transparent.png habían sido marcadas como ‘tombstoned’. No estoy completamente seguro de qué significa eso, pero asumo que un proceso se ejecutó durante la noche mientras las imágenes estaban rotas y las marcó como no utilizadas. Pude ejecutar

rake uploads:recover_from_tombstone

y parece que todas mis imágenes incrustadas han vuelto y ahora apuntan a mi CDN de S3.

Y por si acaso, aquí está cómo encontré el registro de carga comenzando con la cadena yTDVQSa4wbIeLGEZvE7muXe8sAJ.

[14] pry(main)> Base62.decode("yTDVQSa4wbIeLGEZvE7muXe8sAJ").to_s(16)
=> "f49428d6af35d7e0414408ccb65e7316f5003215"
[15] pry(main)> Upload.where( "original_filename ilike '%f49428d6af35d7e0414408ccb65e7316f5003215%'" )
=> [#<Upload:0x000056313aa91fe8
  id: 899,
  user_id: 549,
  original_filename: "f49428d6af35d7e0414408ccb65e7316f5003215.png",
  filesize: 25514,
  width: 1169,
  height: 984,
  url: "//ortus-discourse-uploads.s3.dualstack.us-west-2.amazonaws.com/original/1X/f49428d6af35d7e0414408ccb65e7316f5003215.png",
  created_at: Tue, 12 Jan 2021 23:01:35 UTC +00:00,
  updated_at: Tue, 12 Jan 2021 23:01:36 UTC +00:00,
  sha1: "f49428d6af35d7e0414408ccb65e7316f5003215",
  origin: nil,
  retain_hours: nil,
  extension: "png",
  thumbnail_width: 594,
  thumbnail_height: 500,
  etag: "6977f35ddbf39a4399dc76f92a5079d4",
  secure: false,
  access_control_post_id: nil,
  original_sha1: nil,
  animated: nil,
  verification_status: 1>]

Gracias nuevamente por tu ayuda @Falco. Soy nuevo en Discourse, pero has demostrado ser muy paciente y útil :+1: