¿Cuáles son los ajustes correctos para usar S3 bucket (con URL no de Amazon)?

Así que tengo configurado un bucket de Amazon S3 para almacenar los recursos de mi foro, lo he asociado a un dominio personalizado y configurado CloudFlare CDN para almacenar en caché el contenido.

Mi dominio personalizado se llama algo como http://forum-storage.com, que apunta a https://forum-storage.com.s3-us-east-1.amazonaws.com. El propio bucket de S3 se llama forum-storage.com.

Todo esto funciona correctamente. Si agrego una imagen a la carpeta principal del bucket, puedo recuperarla en mi URL personalizada, es decir, http://forum-storage.com/test.jpg devuelve la imagen, junto con las cabeceras de CloudFlare.

Tres preguntas sencillas…

#1

Ahora necesito indicar a Discourse que utilice esta nueva URL como mi bucket de S3. ¿Qué debo poner en estos 3 campos?

#2

Actualmente tengo imágenes en las publicaciones de mi foro que están en otro bucket de S3, y también tengo imágenes almacenadas localmente. (Mis URLs de imágenes están dispersas por todas partes.)

Una vez que realice los cambios adecuados (arriba), eso significa que todos los NUEVOS medios agregados a mi foro irán al nuevo bucket, pero las imágenes existentes no se moverán y continuarán accediéndose desde donde residen actualmente, ¿correcto?

#3

Ahora que esto funciona para todas las imágenes a partir de este momento, ¿cómo puedo indicarle a Discourse que MOVA todas las imágenes antiguas que no están en este nuevo bucket al nuevo bucket (y vuelva a procesar las publicaciones según sea necesario)?

El objetivo es tener todo en un solo bucket, este nuevo uno detrás del CDN.

1 me gusta

:rotating_light: DETÉNGASE AHORA :rotating_light:

Cree un nuevo bucket que no tenga un punto en su nombre. Si continúa, encontrará sufrimiento interminable debido a cómo funcionan los certificados SSL comodín.

Ref: Discourse does not allow dot «.» symbol in bucket name while Amazon S3 allows it
Ref: https://stackoverflow.com/questions/62568657/ssl-certificate-issue-with-bucket-name-containing-dots-while-trying-to-use

8 Me gusta

Hmmm, vale. ¡Un pequeño contratiempo momentáneo! :wink: Gracias por la alerta, @riking.

AWS S3 tiene una función donde si nombras el bucket igual que el dominio, te permite simplemente agregar un registro CNAME al dominio y todo funciona automáticamente.

Así que ahora estoy buscando por todas partes información sobre cómo conectar un dominio a un bucket que no tiene el mismo nombre que el dominio… hmm

@BryanV, ¿cómo apuntaste https://discourse-uploads.bokeh.org a tu bucket de S3?

1 me gusta

Hmm, eso está bien, pero quieres tener una CDN, por ejemplo CloudFront, frente al bucket, la cual recibirá el CNAME, así que por ahora esa no es una función útil.

No tener una CDN te dejará con la misma factura de transferencia exorbitante.

3 Me gusta

Bien. Creo que estamos en la misma página, ¿verdad? Para ser más claro, según mi entendimiento, hay tres formas de conectar Discourse con S3:

  1. Que Discourse use directamente la nube de S3. Ventaja: muy fácil de configurar. Desventaja: se vuelve costoso rápidamente.

  2. Que Discourse use la nube de S3 a través de un dominio personalizado (como forum-storage.com) para poder usar una CDN. Ventajas: muy fácil de configurar con S3 si el nombre del bucket coincide exactamente con el dominio personalizado (es decir, forum-storage.com.s3-amazon-aws.com). Desventajas: SSL da problemas.

  3. Que Discourse use la nube de S3 a través de un dominio personalizado (de nuevo, para poder usar una CDN), pero configurando el bucket de S3 de modo que no tenga un punto extra en el nombre (es decir, forum-storage-com.s3-amazon-aws.com). Ventajas: SSL funciona bien. Desventajas: no es tan fácil de configurar con Amazon S3.

Así que… estuve usando la opción #1 hasta que recibí la factura :slight_smile: luego supe que la opción #2 era posible, la configuré, inicié este tema y, de inmediato, aprendí que la opción #2 realmente no era viable.

Ahora estoy trabajando en la opción #3. Creo que tengo que usar el servicio DNS “Route 53” de Amazon, o algo similar. Todavía estoy avanzando con dificultad. Toda la búsqueda que he hecho en Google devuelve información sobre cómo hacer la opción #2, pero nadie parece haber escrito instrucciones claras para la opción #3.

Por favor, corrígeme si estoy equivocado o si estoy malinterpretando algo…

Hay tutoriales para eso, por ejemplo, acabo de encontrar este uno para StackPath:

https://support.stackpath.com/hc/en-us/articles/360001457743-Using-Amazon-S3-as-a-Site-Origin

1 me gusta

@BryanV, ¿cómo apuntaste https://discourse-uploads.bokeh.org a tu bucket de S3?

Agregué un registro CNAME que apunta a la URL <long id>.cloudfront.net de la distribución de CDN de CloudFront a nuestra configuración de DNS para bokeh.org (que en nuestro caso está en Cloudflare, pero eso no debería importar).

Como referencia, nuestro bucket de S3 no tiene puntos en el nombre, pero tampoco recuerdo ningún problema específico al configurar la CDN por esa razón (ni ningún problema al crear el bucket; solo necesita un nombre único).

Esto es, sin duda, lo más frustrante que he experimentado. No logro, por más que lo intento, entender cómo conectar un bucket de Amazon S3 (¡sin punto en el nombre del bucket!), mi dominio personalizado y CloudFlare para que todo funcione correctamente. Si pudiera poner un punto en el nombre del bucket, no habría problema. Pero por ahora, es demasiado confuso. Ughhhhhh ¿Puede alguien ayudarme o indicarme una forma sencilla de configurar CloudFlare con un bucket de S3 que no tenga el mismo nombre que el dominio?

Probé la información de StackPath que aparece arriba; creo que hice algo similar en CloudFlare, pero no estoy seguro. No funcionó. Intenté leer la información de CloudFlare sobre cómo agregar la CDN a un bucket de Amazon, pero, por supuesto, ellos requieren que el nombre del bucket sea igual al del dominio, algo que me han dicho que es una Muy Mala Idea y que no puedo hacer.

Realmente parece reducirse a esto:

  • Si el nombre del bucket es igual al del dominio (con un punto), Amazon S3 lo resuelve todo por mí, maravilloso, excepto que complica el SSL, así que no debería hacerlo.
  • Si el nombre del bucket NO coincide con el del dominio, todo se vuelve mucho más complicado y no logro resolverlo.

¿Puede alguien ayudar o aconsejar? Mientras tanto, estoy recibiendo facturas de más de 100 dólares cada mes por mi almacenamiento en S3. Esto es horrible. ¿Puedo pagarle a alguien 200 dólares ahora mismo para que resuelva todo esto? Argh.

¿Ya lo leíste? Yo también tuve dificultades configurando S3 y Cloudflare, pero finalmente lo resolví. Aún puedes usar Cloudflare por sus beneficios de seguridad, pero estoy bastante seguro de que también necesitas un servicio CDN separado. Cloudflare no es como una CDN normal, funciona de manera diferente. Deberías cambiar a un servicio S3 más económico, Amazon es caro.

Usar Cloudflare para almacenar en caché un bucket de S3 implica que debes manipular la cabecera origin en las solicitudes. Esta función está disponible en el plan empresarial de Cloudflare, por lo que puede ser más fácil utilizar cualquier otro CDN.

2 Me gusta

¿No es irrelevante el punto en el nombre del bucket si va a cachear las imágenes a través de CDN de todos modos? Lo único que importa es tener un buen certificado que cubra las imágenes servidas por Cloudflare. Creo que debe centrarse en los servidores de Cloudflare, el DNS y el certificado para cubrir esos aspectos. No creo que el usuario o el navegador lleguen a saber nunca que la fuente de estas imágenes es un bucket de S3. ¿Cloudflare cacheará/proxeará la imagen en sí, verdad?

Discourse generará URLs directas de buckets y las utilizará para operaciones internas, como “subir un archivo”. Esto sigue siendo importante.

@riking Lo único que parece requerir Discourse es un nombre de bucket, ¿correcto? La subida y la gestión pueden realizarse mediante las URL de AWS con sus certificados, si es que incluso se requiere HTTPS. ¿Hasta ahora hay alguna razón para estar hablando de certificados de seguridad?

Luego, el OP puede examinar por separado qué necesita hacer para permitir que su CDN o solución de caché obtenga las imágenes desde S3. ¿Importa si es seguro o no, a menos que el OP o la CDN tengan requisitos específicos, verdad? ¿Le importa a Discourse cómo está configurado el OP entre S3 y la CDN?

Por último, el OP debe asegurarse de que las imágenes se sirvan desde la CDN con un certificado válido. ¿Esto tiene algo que ver con Discourse más allá de que el OP proporcione la URL base donde residirán finalmente las imágenes? Una vez que su CDN o caché obtenga las imágenes desde S3, entonces AWS, los buckets, etc., quedan completamente fuera de la ecuación.

Entiendo que hay problemas relacionados con el punto en los nombres de los buckets de S3 si planeas servir tus imágenes directamente desde allí, pero el OP NO lo hará. Así que simplemente se reduce a que el OP elija cualquier nombre de bucket que Discourse acepte, siempre que no interfiera con la configuración que tenga con la CDN.

Aunque es posible evitar las URLs de tipo bucket-in-domain, en realidad no se evitan debido a la forma en que se utiliza el SDK de AWS S3 y a la dificultad de configurarlo.

Nuevamente, estas operaciones eluden la CDN; la única forma de solucionarlas es en el código fuente de Discourse. Pueden solucionarse, pero actualmente no lo están. Muchos de los problemas tampoco ocurren en la ruta crítica y solo aparecen más tarde. Por lo tanto, hasta que esto cambie, no utilices nombres de bucket que contengan puntos.

1 me gusta

Así que, para resumir esto de forma extremadamente sencilla… la pregunta del OP era qué rellenar en tres configuraciones:

(1) NOMBRE DEL BUCKET: ¿se está diciendo que los puntos no son… recomendados? ¿no permitidos? Sospecho que esto puede no ser un problema para el OP. (Solo necesita averiguar por separado cómo hacer que su CDN guarde en caché y sirva las imágenes). ¿Estamos todos en la misma página, verdad?

(2) ENDPOINT DE S3: déjelo en blanco, no se necesita nada si está usando AWS; de lo contrario, puede rellenarlo para otro proveedor.

(3) URL DE CDN DE S3: ¿es simplemente la URL base que Discourse añadirá al principio de la ruta de la imagen? Si es así, entonces es algo sencillo y directo, y el OP puede configurar su CDN y proporcionar esa URL base aquí.

No veo en qué entran los certificados comodín SSL en esto. Se le dijo al OP que un punto en la configuración de Discourse es malo porque romperá su certificado. Pero si está usando una CDN o una caché, el nombre del bucket podría ser muy irrelevante para el certificado, ¿verdad? Si esto romperá Discourse de otra manera, sería útil saberlo.

No estoy seguro de seguir todo esto tan de cerca, pero para hacer un poco de zoom hacia atrás, quizás este conjunto simple de requisitos ayude:

Los objetivos:

  1. No almacenar mis imágenes de Discourse en mi servidor de Discourse
  2. Tener un bucket S3 para almacenar imágenes (debe ser S3, ya que es lo que Discourse soporta)
  3. No tener cargos costosos de S3
  4. Un CDN no es obligatorio, pero es un buen extra ya que puede ayudar a reducir (o ser la única forma de eliminar) los costosos cargos de S3 y también proporciona mejor disponibilidad a nivel mundial, un respaldo en caso de que el servidor principal se caiga, etc., etc.

Por favor corrígeme si algo de esto está mal

Limitaciones/requisitos:

  1. El almacenamiento externo de imágenes debe soportar el protocolo S3 (ya que es con lo que funciona Discourse), pero, estrictamente hablando, no necesita ser el S3 de Amazon.
  2. Discourse requiere que el nombre del bucket S3 no tenga puntos.
  3. El origen de las imágenes (S3 o CDN) debe servir contenido por https://, ya que un navegador se quejará si la página es https pero las imágenes no lo son.

Por favor corrígeme si algo de esto está mal

Soluciones:

Anteriormente, servía las imágenes directamente desde Amazon S3. Funcionaba muy bien, excepto que los cargos de Amazon por DataTransfer-Out-Bytes son extremadamente costosos. ¡Esto llevó a facturas mensuales altas de Amazon! Así que lo volví a mover al servidor principal. Dos posibles soluciones para esto: colocar un CDN frente al bucket de Amazon S3 para que el CDN maneje toda la transferencia de datos, y/o cambiar a un proveedor S3 diferente.

Intenté poner el CDN de CloudFlare encima del bucket de Amazon S3, pero muy pronto me encontré con muchos problemas que no pude resolver.

¿Otra opción?

Acabo de ver esta oferta de almacenamiento compatible con S3 de Digital Ocean. (DigitalOcean Spaces | S3-Compatible Object Storage) Tiene CDN integrada (no estoy seguro exactamente de lo que significa eso, pero suena prometedor), con precios accesibles. ¿Esto funcionaría con Discourse?

Como referencia, serví aproximadamente 300 GB desde S3 en los últimos 30 días. Parte de eso son copias de seguridad del sitio, y gran parte son imágenes estáticas. Es MUY difícil para mí averiguar cómo medir estas cosas en Amazon… su interfaz de informes de facturación, como todo lo demás de Amazon AWS, es realmente confusa de administrar.

Creo que la solución más sencilla es AWS y KeyCDN, siguiendo las pautas de Uso de almacenamiento de objetos para cargas (S3 y clones). Si tus usuarios no están en Sudamérica, KeyCDN es bastante económico y fácil de configurar.

Una solución potencialmente menos costosa podría ser Cómo configurar BackBlaze S3 con BunnyCDN. He quedado satisfecho con BackBlaze en mis pruebas iniciales para copias de seguridad, pero aún no lo he probado para cargas.

1 me gusta

Nos distrajimos enormemente con un punto en el nombre de un bucket y los certificados del navegador, pero creo que toda esa discusión es completamente irrelevante. CUALQUIER CDN permitirá la configuración de HTTPS, por lo que NO HAY NINGÚN PROBLEMA con el problema del “certificado comodín” y con que haya o no un punto en el nombre del bucket EN LO QUE RESPECTA AL CERTIFICADO DEL NAVEGADOR DEL USUARIO FINAL. Porque, repito, CUALQUIER CDN sin duda permitirá esto.

Así que el OP simplemente puede…
(1) Elegir una solución de almacenamiento compatible con S3 y CDN, y configurar el endpoint y el nombre del bucket en la configuración de Discourse.
(2) Configurar la CDN para que obtenga las imágenes desde S3. Seguro o inseguro. No creo que al OP le importe, siempre que la CDN sirva el contenido al usuario a través de HTTPS.

Alguien por favor corríjame si me estoy perdiendo algo. Creo que el problema del certificado del navegador del usuario final más el punto en el nombre del bucket SOLO es un problema si vas a servir las imágenes DESDE el bucket. Es irrelevante si se sirven desde la CDN.

P.D. Este tema, al que @pfaffman enlazó amablemente arriba, señala que el producto S3 de Digital Ocean (“Spaces”) tiene una CDN “extremadamente defectuosa”.

Y veo que para otros proveedores de S3, hay varios ajustes que deben modificarse.

Esto es lo que me dice:

  • Los ajustes variarán de un proveedor a otro, incluso si todos afirman seguir el protocolo “S3”.
2 Me gusta

Aún

:warning: NO incluyas un punto en el nombre de tu bucket

A menos que disfrutes del sufrimiento.