¡Gracias por el agradecimiento! Marqué para que un moderador prestara atención porque en ese momento no tenía derechos de edición, pero ahora los tengo gracias a la publicación que hice. Es irónico cómo funciona eso, ¿eh?
Pero antes de crear un anuncio general fuera de la sección MinIO, ¿podemos confirmar que Discourse en su conjunto ya no admite rutas basadas en no dominios como las del siguiente post que inició mi búsqueda de edición?
Si sabemos que Discourse en su conjunto no admite el modo de ruta (es decir, rutas minio.server.com/BUCKET/foo/bar/...) y en su lugar solo admite rutas de dominio (es decir, BUCKET.minio.server.com/foo/bar/...), entonces podemos hacer de eso un aviso general en la wiki y estaré feliz de hacerlo. Sin embargo, necesito escucharlo de alguien mucho más arriba en la cadena que yo (como una simple persona de la comunidad) que este sea de hecho el requisito para Discourse. Si es así, podré editarlo, de lo contrario… bueno, simplemente lo dejaré como un anuncio en los requisitos de MinIO.
MinIO es el único clon popular de S3 con antecedentes de uso del ahora obsoleto estilo de ruta S3, por lo que no creo que justifique una advertencia global, solo en la sección de MinIO es suficiente.
Gracias, Falco, lo he dejado en los requisitos de MinIO, pero también he puesto mucho énfasis en esa sección de advertencia debido al hilo vinculado de arriba que se refiere a por qué vuelvo a insistir.
FALLÓ
--------------------
Pups::ExecError: cd /var/www/discourse && sudo -E -u discourse bundle exec rake s3:upload_assets falló con retorno #<Process::Status: pid 2064 exit 1>
Ubicación del fallo: /usr/local/lib/ruby/gems/2.7.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec falló con los parámetros {"cd"=>"$home", "cmd"=>["sudo -E -u discourse bundle exec rake s3:upload_assets"]}
el arranque falló con el código de salida 1
** FALLÓ EL ARRANQUE ** por favor desplázate hacia arriba y busca mensajes de error anteriores, puede haber más de uno.
./discourse-doctor puede ayudar a diagnosticar el problema.
Hola @Falco. ¿Tiene sentido? Estoy revisando las respuestas para asegurarme de que se han gestionado para poder activar la opción de eliminar después de 30 días en este tema.
Revisé algunas de las cargas marcadas como privadas y estaban en temas normales, así que no pude entender por qué estaban marcadas como seguras. (¿No estaba configurada la opción de cargas seguras?)
Tiene sentido. Actualicé la parte superior del OP con esa información. ¿Alguna idea de por qué las cargas locales se habrían marcado como seguras en un sitio que no tenía S3 o cargas seguras habilitadas?
Creo que este problema al subir a Cloudflare R2 puede resolverse con Upload.where(secure: true).update_all(secure: false). Intentaré llegar a eso antes de que se elimine este mensaje (pero agregué una nota al OP).
Hmm, no tenemos ninguna carga segura. Creo que voy a probar Cloudflare R2, ya que sus límites gratuitos son bastante generosos y tienen un migrador S3 (beta). Supongo que lo descubriré, pero ¿viste si R2 estaba bien al final @pfaffman?
Ya no recuerdo si el problema surgió al intentar subir imágenes o al subir una nueva. Pensándolo bien, creo que lo probé en un sitio nuevo.
Migrar a una plataforma S3 diferente es bastante complicado. Hay algunos temas al respecto, pero si quieres usar Cloudflare R2, primero intentaría probarlo en un sitio de prueba; hay una muy buena posibilidad de que no funcione.
Funciona más o menos, pero no está listo para uso en producción.
Tenía una instalación de desarrollo local de Discourse 2.7 antigua y funcionaba bien, en cuanto a cargas de imágenes, uso de CDN y copias de seguridad en un bucket privado cuando se configuraba para Cloudflare R2. Actualicé a la última versión 2.9 (como usa nuestro foro) y parece que falla en el procesamiento de recuperación de Jobs::UpdateGravatar, donde utiliza la notación de bucket incorrectamente para Cloudflare, ya que intenta almacenar en caché una imagen remota de gravatar en R2. Ejemplo (donde el nombre de mi bucket en R2 es ‘uploads’):
Actualización de carga (0.3ms) UPDATE "uploads" SET "url" = '//uploads.123123redact.r2.cloudflarestorage.com/original/1X/123123example.jpeg', "updated_at" = '2022-12-12 20:44:02.929494', "etag" = '9c02b086b2aa5e2088ed44e1017fa63e' WHERE "uploads"."id" = 3
Así que iniciaría la interfaz de usuario y los avatares en mi configuración de prueba/desarrollo local apuntarían a //uploads.123123redact.r2.cloudflarestorage.com/original/1X/123123example.jpeg
Mi mejor suposición es que S3 funciona bien con la notación de punto del bucket y Cloudflare R2 no, ¿o tal vez la caché de gravatar necesita usar el valor del CDN de S3 en su lugar? Es una pena, ya que parece bastante cercano.
Recibí una respuesta de Cloudflare que indica que para R2, hasta que implementen correctamente el ACL de objetos, lo han cambiado para que devuelva un 200 si obtienen valores en esa propiedad que aún no admiten. Este comportamiento cambiado en R2, aparentemente, ocurrió a finales de noviembre. Obviamente, no es ideal (está en un bucket público, con la API pidiendo que sea privado), pero significa que para este problema ahora “funciona”.
¡Oh! Eso suena prometedor. Creo que quizás necesitarías un bucket separado para las cargas, aunque sería un juego de adivinanzas obtener el nombre de archivo de una copia de seguridad.
Uso cubos de carga y copia de seguridad separados, y pareció funcionar bien, en el sentido de que el cubo de copia de seguridad R2 no está configurado como público y Discourse, a través de la interfaz de administración, escribió una copia de seguridad comprimida allí correctamente. Lo descargué, lo revisé y pareció sensato (no es lo mismo que una restauración real, pero es suficiente para un lunes). Mi cubo de cargas lo he probado con una configuración de dominio personalizado para S3_CDN y parece funcionar bien.
Para ser honesto, no puedo decir realmente qué pasa con mi 2.9 que no muestra una interfaz de usuario en ember-cli (se queda en blanco después de crear el usuario administrador), pero probablemente sea algo que usted verá mal rápidamente.
EDITAR: Oh, parece que está intentando cargar los activos de javascript del plugin desde Pseudo-S3/R2, por ejemplo, muchos 404 en cosas como assets/locales/en.br.js.
No tengo suerte con un bundle exec rake s3:upload_assets, así que esa es mi mejor pista actual.
EDITAR2: Sí, está relacionado con los activos, en el sentido de que si borro mi DISCOURSE_S3_CDN_URL, la interfaz de usuario se carga. Intentaré subir manualmente los activos en su lugar por ahora.
EDITAR3: El problema parece ser simplemente que la aplicación necesita que los activos se precompilen y dónde apunta DISCOURSE_S3_CDN_URL, y para un entorno de desarrollo local eso no es habitual. Estaré interesado en lo que encuentre @pfaffman, ya que creo que esto funcionaría en una instancia autoalojada implementada en docker, utilizando el hook after_assets_precompile para R2.
Sí. ¿Una CDN para un entorno de desarrollo local? No puedo imaginar que funcione. Sí suena como que debería funcionar para un despliegue de producción.
Sí, en retrospectiva, no sorprende en una configuración de desarrollo. Creo que lo que no esperaba era que con DISCOURSE_S3_CDN_URL configurado en el CDN de Cloudflare para R2, pero luego DISCOURSE_CDN_URL configurado en blanco (o local o ngrok), todavía quisiera usar la URL de extracción de Cloudflare para los activos precompilados, etc., y no solo para las cargas/imágenes. Creo que funcionará bien en producción en un contenedor adecuado, así que intentaré hacerlo rápidamente. Mi plan será algo como hacer que las cargas de medios sean TL4 temporalmente, cambiar los IDs, etc., a Cloudflare en el app.yaml, probarlo y, si es bueno, dejarlo en R2 y luego transferir todos los objetos S3 existentes con rclone. Después de eso, volveré a hornear las publicaciones y, con suerte, todo estará bien .
.