@Falco - Sería bueno agregar una advertencia para Scaleway, de que solo admite 1000 partes para la carga multipart, mientras que AWS admite 10 000. Esto no es un problema para las cargas normales, pero es un problema para las cargas de copia de seguridad de cierto tamaño, ya que el SDK de S3 utilizará 10 000 partes a menos que se modifique manualmente y falle.
4 Me gusta
¡Gran hallazgo! Por favor, agrégalo a la wiki del OP si puedes.
4 Me gusta
Gracias, también me gustaría añadir que puede utilizar cualquiera de estas herramientas para copiar de la nube a la nube, especialmente hacia/desde almacenamiento de objetos compatible con S3, por ejemplo, Rclone, Shargate, Gs Richcopy360 y GoodSync. todas estas son compatibles con nubes similares.
1 me gusta
Hemos descubierto un problema, Cloudflare R2 no permite la lectura pública desde la URL del endpoint S3, sino solo el dominio personalizado o un dominio aleatorio r2.dev.
(Las descargas pre-firmadas funcionan, simplemente no se admite el acceso público directo).
Pero Discourse solo usa la URL de la CDN para las imágenes incrustadas, y no para las descargas directas, que usan la URL del endpoint S3.
¿Hay alguna forma de hacer que use la URL de la CDN para todos los archivos, o forzar el uso de una URL pre-firmada?
Relacionado:
La solución mencionada en esa publicación funciona, agregar ?dl=1 lo soluciona, porque obliga a Discourse a usar una URL S3 pre-firmada.
1 me gusta
Corregido en 2023-03-16 ahora R2 funciona con Discourse a la perfección con el plan gratuito.
3 Me gusta
También veo esto con cierta frecuencia (cada varios meses) a pesar de que mi Discourse se está ejecutando en AWS Lightsail y estoy subiendo a AWS S3. Así que no estoy seguro de que sea culpa de wasabi.
¿Sería posible detectar este error y alertar al administrador? Reviso el espacio en disco y elimino las copias de seguridad antiguas cuando actualizo, pero a veces es demasiado tarde y el foro deja de funcionar por falta de espacio en disco.
1 me gusta
Estoy bastante seguro de que el problema era que los reinicios automáticos del sistema operativo para actualizaciones de seguridad ocurrían mientras se ejecutaba la copia de seguridad. Asegúrate de programar los reinicios de tu sistema operativo y tus copias de seguridad en momentos diferentes. Fue después de haber trasladado ese sitio de wasabi cuando se me ocurrió esta explicación, pero estoy bastante seguro de que eso fue lo que sucedió.
2 Me gusta
uptime dice que ha estado activo durante 300 días, así que no creo que ese sea el problema. Pero en líneas similares, tenía copias de seguridad de Discourse programadas a las 2:00 a. m. y capturas de Lightsail a las 2:30 a. m., así que tal vez la carga a veces no se completa y la captura interfiere. He separado las dos operaciones por una hora; veremos si marca la diferencia.
De todos modos, creo que es razonable advertir a los administradores si la carga falla, por cualquier motivo.
2 Me gusta
Creo que es hora de que hagas actualizaciones del kernel y reinicies. 
¿Podría quedarse sin RAM?
Después de implementar las copias de seguridad remotas de Backblaze, veo este error en mi panel de control:
El servidor está configurado para subir archivos a S3, pero no hay ninguna CDN de S3 configurada. Esto puede generar costos elevados de S3 y un rendimiento más lento del sitio. Consulte “Uso del almacenamiento de objetos para cargas” para obtener más información.
No configuré la carga de archivos, solo configuré las copias de seguridad a través de esta configuración:
DISCOURSE_S3_REGION: "s3.us-west-00X"
DISCOURSE_S3_INSTALL_CORS_RULE: false
DISCOURSE_S3_ENDPOINT: https://s3.us-west-00X.backblazeb2.com
DISCOURSE_S3_ACCESS_KEY_ID: mykeyid
DISCOURSE_S3_SECRET_ACCESS_KEY: myaccesskey
DISCOURSE_S3_BUCKET: community-forum
DISCOURSE_S3_BACKUP_BUCKET: community-forum/backups
DISCOURSE_BACKUP_LOCATION: s3
¿Hice algo mal?
Algo parece estar mal configurado, noto que cuando intento subir un archivo a una publicación, recibo este error:
Valor no admitido para canned acl ‘public-read’
Cualquier ayuda sería apreciada.
2 Me gusta
Elimina esto si no quieres que las cargas vayan a s3.
4 Me gusta
Me salvaste el día, hermano. 
¡Muchas gracias!
2 Me gusta
¿Funcionó eso?
1 me gusta
Ha ocurrido una vez en el último mes desde que separé los dos procesos por una hora, así que no lo “solucionó”, y no ocurre con la frecuencia suficiente como para decir si ayudó.
En el lado positivo, noté que hay una sección de estado de copia de seguridad en la página de administración que muestra el espacio libre en disco, lo que me ahorra tener que abrir constantemente una terminal y ejecutar un df solo para verificar si hay copias de seguridad atascadas. Personalicé el texto para recordarme que espero alrededor de 80 GB libres.
1 me gusta
Es una buena idea.
Vi la imagen antes de leer que habías personalizado el texto y me preguntaba qué lógica había detrás para determinar que eso era “bueno”.
1 me gusta
No pude hacer que esto funcionara con Scaleway usando la imagen de Bitnami Discourse.
Las variables de entorno estaban configuradas pero claramente no se estaban leyendo/aplicando correctamente (¿o en absoluto?).
Así que he configurado las variables de S3 en el panel de administración y he establecido la región directamente en la consola de Rails (todavía esperando que esto se convierta solo en un campo de texto):
SiteSetting.s3_region="fr-par"
Me dio un error de validación, pero simplemente comenté la verificación de validación antes de actualizar la configuración, y luego la volví a poner.
1 me gusta
La imagen de Bitnami no está empaquetada por nosotros y no sigue nuestras recomendaciones. Todo lo documentado aquí solo se prueba con la instalación oficial.
4 Me gusta
Esto se ha resuelto habilitando “s3 use cdn url for all uploads”, una opción añadida recientemente por Discourse.
Dado que antes usábamos R2, necesitábamos usar discourse remap para reemplazar manualmente los enlaces rotos, sincronizamos los archivos s3 por si acaso y luego volvimos a hornear todas las publicaciones.
1 me gusta
Estoy intentando configurar esto con idrive e2, que es compatible con s3. Sin embargo, estoy recibiendo un error/rastreo de pila no muy útil al final de ./launcher rebuild app:
I, [2023-10-14T15:08:08.026184 #1] INFO -- : cd /var/www/discourse && sudo -E -u discourse bundle exec rake s3:upload_assets
rake aborted!
Aws::S3::Errors::InternalError: We encountered an internal error, please try again.
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/plugins/raise_response_errors.rb:17:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/plugins/sse_cpk.rb:24:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/plugins/dualstack.rb:27:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/plugins/accelerate.rb:56:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/checksum_algorithm.rb:111:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/jsonvalue_converter.rb:22:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/idempotency_token.rb:19:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/param_converter.rb:26:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/plugins/request_callback.rb:71:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/response_paging.rb:12:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/plugins/response_target.rb:24:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/request.rb:72:in `send_request'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/client.rb:12369:in `put_object'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/object.rb:1472:in `put'
/var/www/discourse/lib/s3_helper.rb:78:in `upload'
/var/www/discourse/lib/tasks/s3.rake:41:in `block in upload'
/var/www/discourse/lib/tasks/s3.rake:41:in `open'
/var/www/discourse/lib/tasks/s3.rake:41:in `upload'
/var/www/discourse/lib/tasks/s3.rake:197:in `block (2 levels) in <main>'
/var/www/discourse/lib/tasks/s3.rake:197:in `each'
/var/www/discourse/lib/tasks/s3.rake:197:in `block in <main>'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rake-13.0.6/exe/rake:27:in `<top (required)>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'
Tasks: TOP => s3:upload_assets
(See full trace by running task with --trace)
I, [2023-10-14T15:08:16.413098 #1] INFO -- : Installing CORS rules...
skipping
Uploading: assets/admin-2ebebf57104b0beb47a1c82fe5a8c6decd07f60a706640345fed296a094d1536.js
Esta es la configuración que he estado usando, pero también la he probado con DISCOURSE_S3_CONFIGURE_TOMBSTONE_POLICY y DISCOURSE_S3_HTTP_CONTINUE_TIMEOUT
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: Dallas
DISCOURSE_S3_ENDPOINT: https://y0o9.tx21.idrivee2-4.com
DISCOURSE_S3_ACCESS_KEY_ID: <snip>
DISCOURSE_S3_SECRET_ACCESS_KEY: <snip>
DISCOURSE_S3_BUCKET: discourse
DISCOURSE_S3_INSTALL_CORS_RULE: false
Tenga en cuenta que no lo estoy usando para copias de seguridad (eso ya está configurado en la interfaz de usuario con backblaze) ni DISCOURSE_CDN_URL porque no estoy seguro de que idrive lo soporte; planeaba experimentar con eso una vez que tuviera algunos archivos reales en el bucket.
1 me gusta
Parece que no es lo suficientemente compatible con S3 para las necesidades de Discourse.
Si quieres investigar más, el siguiente paso sería reproducir esto en una instalación de desarrollo y obtener la llamada API exacta que falla.
2 Me gusta