No logré entender por qué en la última actualización nuestra instalación dejó de servir activos desde el CDN. Estamos usando CloudFront y funcionaba bien para servir tanto las cargas como los activos, pero parece que en la última actualización los activos se están sirviendo desde el servidor en su lugar.
Otro problema que tenemos es que si pasamos la variable DISCOURSE_CDN_URL, Discourse comienza a solicitar activos que no son generados ni cargados por la tarea s3:upload_assets (por ejemplo, hojas de estilo). Esto rompe completamente el sitio mostrando una página en blanco. Este post menciona algo similar.
Eliminé DISCOURSE_CDN_URL, que estaba configurado con el mismo valor que DISCOURSE_S3_CDN_URL, ya que eso rompía el sitio (intentaba cargar activos que no existían en S3).
Al revisar el sitio con el que tenía problemas, parece que olvidé incluir https:// en la URL del CDN que estaba utilizando. No estoy seguro de cómo es que alguna vez funcionó, o si nunca funcionó, cómo no me di cuenta de eso al agregar el valor incorrecto.
@eatcodetravel, por supuesto necesitas ocultar las contraseñas de SMTP y las claves de S3, pero creo que necesitarás compartir al menos los valores del CDN para que alguien pueda hacer alguna conjetura sobre cuál podría ser el problema.
Sí, tuve que eliminar DISCOURSE_CDN_URL, comenzó a solicitar activos que no se están subiendo a S3 mediante la tarea rake s3:upload_assets y esto rompe completamente el sitio. Quizás esa fue la parte que cambió y necesitamos actualizar rake s3:upload_assets para que vuelva a funcionar correctamente.
Sí, es posible usar la misma URL de CDN tanto para DISCOURSE_CDN_URL como para DISCOURSE_S3_CDN_URL, pero requiere muchas configuraciones de inicio de sesión en la CDN para utilizar la fuente correcta de cada activo según la URL. Por ejemplo, el CSS proviene de la aplicación, el JS de S3, y este es solo un caso; tenemos docenas.
Por lo tanto, se espera que configures ambos: DISCOURSE_CDN_URL como un “proxy” de tu aplicación web, y DISCOURSE_S3_CDN_URL como un proxy de tu bucket de almacenamiento de objetos.
Oh, vale, ¿es algo que cambió recientemente? No estoy seguro de si CloudFront admite ser un proxy inverso para nuestra aplicación en lugar de un bucket de S3.
Veo que estás usando CloudFront en meta, ¿haces algo especial para ejecutarlo o Discourse se encarga de todo?
Si inspeccionas esta página, verás que tenemos dos URLs diferentes de Cloudfront, por lo que utilizamos lo que mencioné anteriormente: dos distribuciones, una para la CDN normal y otra para S3.
El problema del título del OP es este: el CSS proviene de la aplicación y el JS de S3. Necesitas una CDN que conozca el origen de cada activo y pueda acceder al lugar necesario, o bien dos CDNs. Por eso, después de todo, tenemos dos configuraciones diferentes.
Aunque esto tiene todo el sentido del mundo ahora que lo entiendo, no estoy seguro de que esté documentado. Y es probable que tengas problemas (¡al menos yo los tuve!), ya que la tarea rake move-uploads-to-s3 requiere que tengas un s3_cdn. Esto explica por qué varias veces he intentado mover cosas a S3 y terminé renunciando.
Creo que sería genial que hubiera alguna advertencia tipo: “Oye, no puedes tener un CDN de S3 sin un CDN de activos” en algún lugar.
Ok, ahora entiendo lo que estás diciendo; no sabía que esto era necesario. ¿Puedo preguntar por qué el CSS debe provenir de la aplicación? ¿Por qué no podemos subirlo mediante la tarea rake s3:upload_assets?
Haré algunas investigaciones sobre cómo lograr esto en Cloudfront y compartiré aquí mis hallazgos o los obstáculos que encuentre.
Bueno, quizás lo estoy explicando mal. Puedes hacerlo, pero es complicado, como muestran tus temas y este en particular.
El sitio de @eatcodetravel está funcionando ahora mismo solo con S3_CDN configurado, pero luego entras en un estado extraño donde el CSS (que bloquea la renderización) se sirve desde tu servidor, mientras que las imágenes en los mensajes no, lo cual no tiene sentido.
Porque Admin > Personalizar es una opción. Los usuarios pueden cambiar el CSS desde el panel de administración. Los fragmentos de JS personalizados que viven en los temas también se sirven desde la aplicación, según mi conocimiento.
Al final, lo solucioné proporcionando una segunda distribución de CloudFront que apunta al servidor web, y manteniendo la otra solo para S3. Gracias @Falco por el feedback, pero estoy de acuerdo en que esto necesita estar documentado un poco mejor.
s”?