No parece que tenga permiso para editar la wiki, pero sí utilicé con éxito un proveedor diferente.
OVHcloud
Nombre del servicio: Almacenamiento de objetos
Las regiones corresponden a centros de datos que se identifican por un código de tres letras. Si no sabe dónde creó su bucket, consúltelo en la pestaña de almacenamiento de objetos en su portal de cliente.
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: [código del centro de datos]
DISCOURSE_S3_ENDPOINT: https://s3.[código del centro de datos].io.cloud.ovh.net/
DISCOURSE_S3_ACCESS_KEY_ID: [clave]
DISCOURSE_S3_SECRET_ACCESS_KEY: [clave]
DISCOURSE_S3_BUCKET: [nombre del bucket]
DISCOURSE_S3_BACKUP_BUCKET: [nombre del bucket]
DISCOURSE_BACKUP_LOCATION: s3
Inicialmente, tanto en mi versión de prueba, pero fui a producción solo con copias de seguridad ya que la máquina de producción tiene mucho espacio de todos modos.
Es muy compatible con S3, pero hay algunas cosas que faltan, como las reglas de ciclo de vida para eliminar archivos antiguos o mover estos a almacenamiento en frío, las cuales están siendo activamente trabajadas por OVH. Sin embargo, funciona bien para servir archivos.
Así que para las copias de seguridad, simplemente usé la opción de Discourse para eliminar automáticamente copias antiguas.
[cita=“pfaffman, post:439, tema:148916”]
¿Seguiste los enlaces?
Parece que el CDN no tiene información sobre los metadatos. ¡Pero podrías probarlo y ver si funciona! Avísanos si lo haces. Me preguntaba si se había arreglado hace unos días. Por la apariencia de la documentación, no voy a intentarlo yo mismo en un futuro cercano.
[/cita]
Esta es una respuesta realmente decepcionante y completamente inútil. ¿Qué exactamente es el problema? Enlazar a un documento de soporte que cambia significa que nadie puede decir realmente qué diablos es la “pinchazón horrible y rota” mencionada en este hilo.
Mencionas “metadatos” y que el CDN “no sabe sobre ellos”. ¿Qué metadatos? Sería útil saber qué no está funcionando.
Solo quería añadir a esta publicación mía instrucciones sobre cómo usar E2 de iDrive.
Parece que hay algo que iDrive ha activado recientemente que hace que las claves de acceso asignadas a un solo bucket fallen a menos que se omita una verificación de autenticación del bucket.
Puedes omitir esto al usar rclone con no_check_bucket = true en el archivo rclone.conf, pero no estoy seguro de que exista una configuración de entorno para la compilación de Discourse.
Como resultado, con iDrive E2, actualmente debes usar una clave que tenga acceso para escribir en todos tus buckets, en lugar de solo en uno.
¿Por qué alguien más conocería el problema exacto para un proveedor que no usa?
De todos modos, parece que casi hemos terminado con Cloudflare R2. Según:
Cuando ingresé toda la información en la Interfaz de Usuario Web, las nuevas cargas se enviaron correctamente al almacenamiento S3, y las copias de seguridad se envían correctamente a S3. Las cargas actuales obviamente no se movieron.
Luego fui a app.yml y ingresé esta información:
## Este conjunto de líneas permite que los archivos alojados en S3 de R2 se carguen y descarguen.
DISCOURSE_CDN_URL: https://eufiles.technospider.com
DISCOURSE_USE_S3: true
DISCOURSE_S3_ENDPOINT: https://randomnumber.r2.cloudflarestorage.com
DISCOURSE_S3_CDN_URL: https://eufiles.technospider.com
DISCOURSE_S3_BACKUP_BUCKET: exotics-unlimited-backups
DISCOURSE_INCLUDE_S3_UPLOADS_IN_BACKUPS: true
DISCOURSE_BACKUP_LOCATION: s3
DISCOURSE_S3_BUCKET: exotics-unlimited
DISCOURSE_S3_REGION: auto
DISCOURSE_S3_ACCESS_KEY_ID: randomnumbers
DISCOURSE_S3_SECRET_ACCESS_KEY: randomnumbers
DISCOURSE_S3_INSTALL_CORS_RULE: false
## El contenedor Docker no tiene estado; todos los datos se almacenan en /shared
volumes:
- volume:
host: /var/discourse/shared/standalone
guest: /shared
- volume:
host: /var/discourse/shared/standalone/log/var-log
guest: /var/log
## Los plugins van aquí
## ver https://meta.discourse.org/t/19157 para más detalles
hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
- git clone https://github.com/discourse/docker_manager.git
# - git clone https://github.com/discourse/discourse-subscriptions.git
- git clone https://github.com/discourse/discourse-follow.git
- git clone https://github.com/discourse/discourse-solved.git
- git clone https://github.com/communiteq/discourse-private-topics.git
# - git clone https://github.com/discourse/discourse-assign.git
- git clone https://github.com/tknospdr/discourse-auto-remove-group.git
- git clone https://github.com/discourse/discourse-topic-voting.git
- git clone https://github.com/discourse/discourse-livestream.git
# - git clone https://github.com/discourse/discourse-calendar.git
- git clone https://github.com/jannolii/discourse-topic-trade-buttons.git
## - git clone https://github.com/tknospdr/force-tag-group-order.git
## Hooks para S3
after_assets_precompile:
- exec:
cd: $home
cmd:
- sudo -E -u discourse bundle exec rake s3:upload_assets
- sudo -E -u discourse bundle exec rake s3:expire_missing_assets
Después de una reconstrucción, mi sitio se rompió debido a una gran cantidad de archivos faltantes, así que intenté subirlos al servidor y obtuve este error para cada archivo:
root@talk-app:/var/www/discourse# rake uploads:migrate_to_s3
Tenga en cuenta que la migración a S3 actualmente no se puede revertir.
[CTRL+c] para cancelar, [ENTER] para continuar
Migrando cargas a S3 para 'default'...
Cargando archivos a S3...
- Listando archivos locales
. => 31 archivos
- Listando archivos S3
. => 4 archivos
- Sincronizando archivos a S3
#<Thread:0x00007ff89dcbcb20 /var/www/discourse/lib/file_store/to_s3_migration.rb:212 run> terminado con excepción (report_on_exception es true):
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.226.0/lib/seahorse/client/plugins/raise_response_errors.rb:17:in `call': Solo puedes especificar un checksum no predeterminado a la vez. (Aws::S3::Errors::InvalidRequest)
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/plugins/sse_cpk.rb:24:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/plugins/dualstack.rb:21:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/plugins/accelerate.rb:43:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.226.0/lib/aws-sdk-core/plugins/checksum_algorithm.rb:169:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.226.0/lib/aws-sdk-core/plugins/jsonvalue_converter.rb:16:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.226.0/lib/aws-sdk-core/plugins/invocation_id.rb:16:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.226.0/lib/aws-sdk-core/plugins/idempotency_token.rb:19:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.226.0/lib/aws-sdk-core/plugins/param_converter.rb:26:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.226.0/lib/seahorse/client/plugins/request_callback.rb:89:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.226.0/lib/aws-sdk-core/plugins/response_paging.rb:12:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.226.0/lib/seahorse/client/plugins/response_target.rb:24:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.226.0/lib/aws-sdk-core/plugins/telemetry.rb:39:in `block in call'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.226.0/lib/aws-sdk-core/telemetry/no_op.rb:29:in `in_span'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.226.0/lib/aws-sdk-core/plugins/telemetry.rb:53:in `span_wrapper'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.226.0/lib/aws-sdk-core/plugins/telemetry.rb:39:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.226.0/lib/seahorse/client/request.rb:72:in `send_request'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/client.rb:17315:in `put_object'
from /var/www/discourse/lib/file_store/to_s3_migration.rb:215:in `block (2 levels) in migrate_to_s3'
Me encantaría recibir algún consejo para terminar esto de una forma u otra.
Los archivos faltantes son probablemente recursos, por lo que necesita la tarea rake que los envía a s3 (s3:upload_assets – está cerca de la parte superior).
Pero sus errores se deben probablemente a que la nueva biblioteca aws s3 rompió un montón de servicios. Por lo tanto, necesitará ingeniárselas para degradar el gem de aws o usar otro servicio.
Creo que puede haber un tema sobre cómo hacer eso. Lo he hecho en uno o dos sitios, pero no estoy seguro de cómo o dónde se ha documentado.
¿Necesito ejecutar eso aunque sea parte de los cambios que puse en el archivo app.yml? Pensé que estaba ahí para enviar automáticamente los archivos durante una reconstrucción.
No deberías, pero esas son las cosas que harían que tu sitio estuviera “roto” (¿o “roto” significa “faltan imágenes” para ti?) Subir imágenes con migrate_to_s3 solo afecta a las imágenes.
No puedo explicar exactamente cómo se subieron todos los activos (¿qué estaba roto en el sitio? ¿Cómo se subieron si tu configuración de S3 está rota?)
Dado que todo parece estar ahí en mi bucket, probablemente haya alguna variable de entorno que deba actualizarse para que todo funcione correctamente.
Si podemos resolver esto, podemos decir que R2 está listo para el horario estelar.
¿Dónde se supone que está “extra-locales”? No lo veo en ‘public’ ni en ‘assets’, ni siquiera dentro del contenedor. ¿Dónde debería buscar?
Disculpa las preguntas tontas, pero esto es algo totalmente nuevo para mí.
¿Es QUÉ mi CDN o mi bucket?
¿Con los guiones iniciales y todas las comillas simples y dobles? No tengo nada de eso en mi archivo app.yml. ¿Debería agregarlos y reconstruir para probar?
Este es exactamente el aspecto de mi archivo, con una indentación de 2 espacios cada uno:
## Este conjunto de líneas permite que los archivos alojados en R2 S3 se suban y descarguen.
DISCOURSE_CDN_URL: https://eufiles.technospider.com
DISCOURSE_USE_S3: true
DISCOURSE_S3_ENDPOINT: https://randomnumber.r2.cloudflarestorage.com
DISCOURSE_S3_CDN_URL: https://eufiles.technospider.com
DISCOURSE_S3_BACKUP_BUCKET: exotics-unlimited-backups
DISCOURSE_INCLUDE_S3_UPLOADS_IN_BACKUPS: true
DISCOURSE_BACKUP_LOCATION: s3
DISCOURSE_S3_BUCKET: exotics-unlimited
DISCOURSE_S3_REGION: auto
DISCOURSE_S3_ACCESS_KEY_ID: randomnumbers
DISCOURSE_S3_SECRET_ACCESS_KEY: randomnumbers
DISCOURSE_S3_INSTALL_CORS_RULE: false
Funcionó cuando tenía la configuración introducida a través de la interfaz web, luego cuando puse todo en el archivo app.yml obtuve lo que viste cuando fuiste al sitio.
Aquí está lo que veo cuando accedo a uno de sus recursos:
Este objeto no existe o no es accesible públicamente en esta URL. Compruebe la URL del objeto que está buscando o póngase en contacto con el propietario para habilitar el acceso público.
Puede ver si https://eufiles.technospider.com/extra-locales/ca382c69f8e6b85162b2ba58f2ce100bfe741966/en/mf.js?__ws=eu.technospider.com funciona si cambia el nombre de host a su punto final de Cloudflare.
¿Puede encontrar ese archivo en su bucket? ¿Puede acceder a él?
No lo sé, pero es una URL que copié de las herramientas de desarrollador de mi navegador.
Así que primero encuentre ese archivo en su bucket y vea si está allí y luego podrá averiguar por qué la CDN no puede encontrarlo.
No. Utilizo una herramienta diferente para la configuración, pero esas son las configuraciones de ENV que estoy bastante seguro de que funcionaron para mí en algún momento.
Este archivo XML no parece tener ninguna información de estilo asociada. Se muestra el árbol del documento a continuación.
<Error>
<Code>InvalidArgument</Code>
<Message>Authorization</Message>
</Error>
Un bucket es ese “directorio principal” que has creado y donde están todos los archivos. CDN son un montón de servidores en todo el mundo y estos obtienen una copia de ese bucket. El tuyo se identifica mediante la URL que le diste cuando se creó esa conexión, como por ejemplo cdn.example.com.
Parece que con R2 se crea automáticamente la CDN si le das al bucket un dominio personalizado. Eso fue un poco confuso ya que no tuve que hacer nada con la CDN.
Este archivo XML no parece tener ninguna información de estilo asociada. El árbol del documento se muestra a continuación.
<Error>
<Code>InvalidArgument</Code>
<Message>Authorization</Message>
</Error>
Me da:
Dado que el error habla de autorización, investigué un poco y encontré este fragmento:
Nota
Por defecto, solo ciertos tipos de archivo se almacenan en caché. Para almacenar en caché todos los archivos de su bucket, debe configurar una regla de página “Cache Everything”.
