¿Se agregará compatibilidad/soporte para Contabo S3? ¿O alguien encontró una solución alternativa para que funcione?
2 Me gusta
Nosotros, los mantenedores de Discourse, solo admitimos AWS S3. Los proveedores que se enumeran aquí fueron probados por nosotros o por la comunidad para ver si implementan suficiente API de S3 para ser compatibles con Discourse.
Según el OP, @tuxed probó Contabo y lo encontró deficiente. Depende de Contabo evolucionar su implementación para cumplir con S3, si lo consideran alineado con sus intereses comerciales, no es algo que podamos hacer.
4 Me gusta
¿Sigue esto con errores? ¿Por qué la CDN de Digitalocean no es buena?
1 me gusta
¿Seguiste los enlaces?
Parece que la CDN no sabe nada de metadatos. ¡Pero podrías probarlo y ver si funciona! Háznoslo saber si lo haces. Me preguntaba si se había arreglado el otro día. Por la pinta de la documentación, no voy a probarlo yo mismo en mucho tiempo.
2 Me gusta
Estoy buscando una forma sencilla de añadir soporte CDN a mi foro en DigitalOcean. Si S3 es más fácil, me inclinaré por esa opción.
No quiero arriesgarme con una configuración que no haya funcionado bien antes.
2 Me gusta
La solución recomendada es simplemente no usar su CDN. Puedes usar Spaces, si sigues las instrucciones anteriores, y algo como bunny.net para la CDN. Es barato y fácil.
AWS S3 es lo que usa cdck, por lo que está un poco mejor probado y soportado, pero a menos que ya estés familiarizado con AWS, el bucket de Spaces es una buena solución. Simplemente no uses la CDN de DigitalOcean.
2 Me gusta
Acabo de pasar por esto: configuración de CDN, manteniendo las imágenes locales por ahora, primero con Fastly, luego con otro que no recuerdo. Me decidí por Bunny.net. muy fácil de configurar. Tienen guías específicas para Discourse. Estamos autoalojados en DO con más de 100 GB de imágenes. Tasa de aciertos de caché del 65% y en aumento.
2 Me gusta
¿la política de tumba de configuración s3 solo funciona en aws.amazon?
1 me gusta
No. Es un problema solo en Backblaze.
2 Me gusta
3 publicaciones se dividieron en un nuevo tema: Explorando soluciones para problemas de carga de fotos de perfil de usuario
Vaya, ¿por dónde empiezo? Estoy usando Cloudflare para el almacenamiento en caché y DNS, y Backblaze B2 para el almacenamiento. Pude hacerlo funcionar, pero solo parcialmente. Durante un ./launcher rebuild app vi que estaba subiendo activos, así que estaba súper emocionado de que pareciera estar funcionando. Después de que se completó la reconstrucción con éxito, no pude acceder al sitio. Simplemente obtengo unos puntos en movimiento en medio de la página.
Basándome en el artículo de Backblaze Deliver Public Backblaze B2 Content Through Cloudflare CDN, he configurado un registro CNAME proxy que apunta al origen de la URL amigable f000.backblazeb2.com llamado gtech-cdn.
CNAME gtech-cdn –\u003e f000.backblazeb2.com
El artículo también habla de las Reglas de Página; he intentado activarlas y desactivarlas sin éxito.
Aquí están los elementos de configuración pertinentes:
DISCOURSE_HOSTNAME: mmhmm.com
DISCOURSE_CDN_URL: https://mmhmm.com
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: us-west-000
DISCOURSE_S3_ENDPOINT: https://s3.us-west-000.backblazeb2.com
DISCOURSE_S3_ACCESS_KEY_ID: <secret>
DISCOURSE_S3_SECRET_ACCESS_KEY: <secret>
DISCOURSE_S3_CDN_URL: https://gtech-cdn.mmhmm.com
DISCOURSE_S3_BUCKET: gtech-uploads
DISCOURSE_S3_BACKUP_BUCKET: gtech-uploads/backups
DISCOURSE_BACKUP_LOCATION: s3
En la sección **hooks:**...
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
Una de las cosas que me confunde es qué poner en las dos variables DISCOURSE_S3_CDN_URL y DISCOURSE_CDN_URL. ¿Las tengo configuradas correctamente según la información que he proporcionado?
Mirando la consola de herramientas de desarrollador del navegador, estoy obteniendo errores 404 en scripts .js. La URL no parece construirse correctamente. ¿No debería tener /file/ antes de /assets? Si lo añado manualmente para crear una URL correcta, funciona:
https://gtech-cdn.mmhmm.com/file/gtech-uploads/assets/google-universal-analytics-v4-e154af4adb3c483a3aba7f9a7229b8881cdc5cf369290923d965a2ad30163ae8.br.js
¡Gracias por cualquier ayuda, es muy apreciada!
1 me gusta
https://gtech-cdn.mmhmm.com no se resuelve, así que eso es lo primero que hay que arreglar.
No estoy seguro de que puedas usar Cloudflare como CDN de esa manera, pero quizás me equivoque.
1 me gusta
Lo siento, debería haber mencionado que mmhmm.com es un dominio falso. Responde a un ping.
En cuanto a que Cloudflare no se pueda usar como CDN, supongo que no te sigo. El artículo que enlacé claramente es para usarlo como CDN. Si eso no es cierto, entonces, de nuevo, ¿qué valores se deben usar en las dos variables DISCOURSE_S3_CDN_URL y DISCOURSE_CDN_URL?
Saludos,
Si proporcionas URLs falsas, solo obtendrás respuestas falsas.
¿La URL sirve los datos esperados? ¿Puedes recuperarlos de la URL del foro?
Creo que la CDN de S3 debería funcionar. Está usando la URL del foro para la CDN del foro, de la que no estoy seguro.
Una CDN normal tiene una URL diferente a la del foro y la CDN puede contar con que los datos sean estáticos en lugar de tener que adivinar qué es dinámico.
1 me gusta
Hago todo lo posible por no divulgar mi información en varios foros, así que por favor disculpen mi secretismo al respecto.
El foro se encuentra en “https://mmhmm.com”, que es un registro DNS de Cloudflare que está en proxy (en caché). Antes de configurar Discourse para usar Backblaze, todo funcionaba correctamente.
“https://gtech-cdn.mmhmm.com”, como se indicó anteriormente, se resuelve y también responde a un ping. El objetivo del registro CNAME, f000.backblazeb2.com, también se resuelve. Ese origen de URL amigable de B2 es lo que el artículo le indica que use. Sin embargo, ese no es el problema. El problema es que Discourse está sirviendo URLs para los archivos .js usando una URL inválida que nunca funcionará, ya que le falta la parte “/file/gtech-cdn” de la ruta. Si toma una de esas URLs .js incompletas y le agrega manualmente la información faltante, cargará el texto del archivo .js sin problemas.
Por supuesto, todavía estoy tratando de entender cómo se supone que todo esto funciona con esas dos variables. Soy más de aprendizaje visual y realmente agradecería un diagrama de flujo o algo que me ayude a comprender lo que se supone que debe suceder con las interacciones entre Cloudflare CDN, Discourse y Backblaze B2.
Gracias por tu ayuda.
Y, intentaré abordar tu última frase sobre una CDN normal…
El artículo de Backblaze te pide que crees dos reglas de página por bucket (en mi caso, se usa 1 bucket), lo que, si lo entiendo correctamente, es algo así como una regla de firewall en la forma en que procesa.
La Regla 1 dice que https://gtech-cdn.mmhmm.com/file/*/* debe usar el almacenamiento en caché estándar (que se establece en otro lugar en Cloudflare a 1 mes).
La Regla 2 redirige cualquier cosa (302 - redirección temporal) que no coincida con el patrón de la Regla 1.
Por lo tanto, no todo se almacenará en caché al ir a mmhmm.com… al menos esa es mi comprensión.
EDITAR: Esto no funcionó.
Centrándome un poco más en esto, decidí, por razones obvias, que debería usar la URL de S3 como destino del CNAME en lugar de la URL amigable que sugería el artículo de Backblaze. Ahora solo estoy esperando que expire el TTL del registro DNS.
Con respecto a este hook:
No veo nada con s3 en el volcado de rake --tasks. ¿Sigue siendo relevante o me falta algún plugin?
También veo esto cuando ejecuto manualmente:
uploads:migrate_to_s3
rake aborted!
FileStore::ToS3MigrationError: No se pudieron migrar algunas cargas al nuevo esquema. Debes solucionarlo manualmente. (FileStore::ToS3MigrationError)
/var/www/discourse/lib/file_store/to_s3_migration.rb:156:in `migrate_to_s3'
/var/www/discourse/lib/file_store/to_s3_migration.rb:59:in `migrate'
/var/www/discourse/lib/tasks/uploads.rake:126:in `migrate_to_s3'
/var/www/discourse/lib/tasks/uploads.rake:106:in `block in migrate_to_s3_all_sites'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rails_multisite-6.0.0/lib/rails_multisite/connection_management/null_instance.rb:49:in `with_connection'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rails_multisite-6.0.0/lib/rails_multisite/connection_management/null_instance.rb:36:in `each_connection'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rails_multisite-6.0.0/lib/rails_multisite/connection_management.rb:21:in `each_connection'
/var/www/discourse/lib/tasks/uploads.rake:104:in `migrate_to_s3_all_sites'
/var/www/discourse/lib/tasks/uploads.rake:100:in `block in <main>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'
Tasks: TOP => uploads:migrate_to_s3
(Ver el rastreo completo ejecutando la tarea con --trace)
root@ubuntu-s-2vcpu-4gb-nyc2-01-app:/var/www/discourse#
root@ubuntu-s-2vcpu-4gb-nyc2-01-app:/var/www/discourse# rake uploads:migrate_to_s3
Ten en cuenta que la migración a S3 actualmente no se puede revertir.
6 publicaciones se dividieron en un nuevo tema: Cloudflare R2: Navegando la configuración y manejando errores de configuración
Parece que Cloudflare funciona ahora:
Ver Cloudflare R2: Navigating Setup and Handling Configuration Errors - #13 by pfaffman
2 Me gusta