¿URL del CDN S3 con nombre del bucket? - MinIO

,

Estoy ejecutando una instancia de MinIO multiserver detrás de un servidor proxy Nginx.
Para la integración de MinIO, he tenido problemas y hoy descubrí que tengo que configurar la ‘URL de CDN de S3’ no como ‘cdn.example.com’, sino como ‘cdn.example.com/nombre_del_bucket’ para mostrar las imágenes cargadas.

Puede que se deba a un problema de configuración de mi propio MinIO, así que permítanme darles un poco más de información aquí.
Tengo dos servidores ejecutando MinIO para los mismos contenidos. Ambos están mapeados con IP internas, como 192.168.1.1 y 192.168.1.2. El puerto de acceso a la API es, digamos, 9000, y el puerto de acceso a la consola es 9001. (Aunque uso diferentes IPs y Puertos, pero a efectos de ilustración).

Inicialmente tuve problemas con el ‘endpoint de S3’.

Con ‘https://cdn.example.com’ como endpoint, seguía recibiendo errores. También probé con el acceso a la consola, como ‘s3.example.com’, la URL que uso para distribuir el tráfico a nivel del servidor proxy Nginx para la consola. Ninguno de ellos funcionó.

Hoy, cambié el endpoint a ‘http://192.168.1.1:9000’, como hago con NextCloud. (Tuve problemas similares con NextCloud). Finalmente, pude ver que los archivos se cargan en S3. Pero, todavía no podía ver la imagen en Discourse. Cuando verifiqué la URL de la imagen en blanco, era como ‘cdn.example.com/original/1x/…’ En otras palabras, faltaba el nombre del bucket S3 que agregué a la configuración.

Así que, cambié la ‘URL de CDN de S3’ a ‘https://cdn.example.com/mi_nombre_de_bucket’. Finalmente puedo ver la imagen en la edición del tema de Discourse, así como en el sitio web en vivo.

Dado que está funcionando, iba a dejarlo y volver a mis otros sitios web, pero entonces, veo que el ‘Bucket de Copia de Seguridad de S3’ tiene que ser un nombre de bucket diferente al bucket de carga principal. Si habilito ‘Usar URL de CDN para todos los archivos cargados en s3 en lugar de solo para imágenes’, ¿qué sucede con la copia de seguridad de S3? ¿Subirá el archivo de copia de seguridad a ‘https://cdn.example.com/bucket_de_copia_de_seguridad’?

Así que intenté ejecutar una copia de seguridad. Como esperaba, recibí el mensaje de error para la copia de seguridad.

Por ahora, a menos que haya configurado mal MinIO y/o Discourse, creo que tiene sentido que la ‘URL de CDN de S3’ deba agregar el nombre del bucket de carga principal y el nombre del bucket de copia de seguridad. Entonces, podría volver de ‘https://cdn.example.com/mi_nombre_de_bucket’ a ‘https://cdn.example.com’.

Además, prefiero no usar la IP interna como el ‘endpoint de S3’. Hice la misma pregunta a Nextcloud. ¿Cómo funciona el módulo S3 de Discourse? Solo me pregunto por qué tengo que dar la IP interna completa + el puerto en lugar del FQDN que he asignado a nivel del servidor proxy. El FQDN ciertamente me ayuda a redirigir el tráfico si uno de los servidores MinIO falla. Con la configuración actual, si el servidor backend principal falla, la lectura puede funcionar (por CDN), pero las acciones de escritura no.

Podría ser, o diría, que es más probable que se deba a mi mala configuración y/o incompatibilidad con el SDK de MinIO/AWS. Por ahora, me conformaré con una solución alternativa.

Parece que está utilizando buckets de estilo de ruta (minio.example.com/bucketname), lo que no funcionará. Debe configurar MINIO_DOMAIN, que habilitará implícitamente buckets de estilo de host virtual (bucketname.minio.example.com)

Consulte Core Settings | AIStor Object Store Documentation

Gracias por la rápida respuesta.

Entonces, solo me pregunto por qué la URL de la imagen no era ‘bucketname.cdn.example.com’.
¿Fue porque agregué la URL de CDN que funciona como la URL de CloudFront? En mi caso, sin la URL de CDN, me temo que la ruta del archivo de imagen podría ser http://bucket_name.192.168.1.1:9000/original/1x/…

Si de hecho tengo que asignar un FQDN a MinIO de cada servidor y tengo que usar uno de los FQDN como punto final, entonces el servidor múltiple para el balanceo de carga no tiene sentido.