URL CDN S3 avec nom de bucket ? - MinIO

,

Je fais fonctionner une instance MinIO multi-serveurs derrière un serveur proxy Nginx.
Pour l’intégration MinIO, j’ai eu des difficultés et aujourd’hui, j’ai constaté que je devais définir ‘S3 CDN URL’ non pas comme ‘cdn.example.com’, mais comme ‘cdn.example.com/nom_du_bucket’ pour afficher les images téléchargées.

Cela pourrait être dû à un problème de configuration de mon MinIO, alors laissez-moi vous donner quelques informations supplémentaires.
J’ai deux serveurs exécutant MinIO pour le même contenu. Les deux sont mappés avec une adresse IP interne, comme 192.168.1.1 et 192.168.1.2. Le port d’accès API est, disons, 9000, et le port d’accès Console est 9001. (Bien que j’utilise des adresses IP et des ports différents, c’est à titre d’illustration.)

J’ai d’abord eu des problèmes avec le ‘S3 endpoint’.

Avec ‘https://cdn.example.com’ comme endpoint, j’ai continué à recevoir des erreurs. J’ai également essayé avec l’accès console, comme ‘s3.example.com’, l’URL que j’utilise pour distribuer le trafic au niveau du serveur proxy Nginx pour la console. Aucun des deux n’a fonctionné.

Aujourd’hui, j’ai changé l’endpoint en ‘http://192.168.1.1:9000’, comme je le fais avec NextCloud. (J’ai eu des problèmes similaires avec NextCloud). Finalement, j’ai pu constater que les fichiers étaient téléchargés vers S3. Cependant, je n’ai toujours pas pu voir l’image sur Discourse. Lorsque j’ai vérifié l’URL de l’image vide, elle ressemblait à ‘cdn.example.com/original/1x/…’ Autrement dit, il manquait le nom du bucket S3 que j’avais ajouté au paramètre.

J’ai donc changé ‘S3 CDN URL’ en ‘https://cdn.example.com/mon_nom_de_bucket’. Je peux enfin voir l’image dans l’édition du sujet Discourse ainsi que sur le site web en direct.

Comme cela fonctionne, j’allais passer à autre chose et revenir à mes autres sites web, mais j’ai constaté que ‘S3 Backup Bucket’ doit être un nom de bucket différent de celui du bucket de téléchargement principal. Si j’active ‘Utiliser l’URL CDN pour tous les fichiers téléchargés sur S3 au lieu de seulement pour les images’, qu’advient-il de la sauvegarde S3 ? Le fichier de sauvegarde sera-t-il téléchargé vers ‘https://cdn.example.com/bucket_de_sauvegarde’ ?

J’ai donc essayé d’exécuter une sauvegarde. Comme prévu, j’ai reçu un message d’erreur pour la sauvegarde.

Pour l’instant, à moins que je n’aie mal configuré MinIO et/ou Discourse, il me semble logique que ‘S3 CDN URL’ doive ajouter le nom du bucket de téléchargement principal et le nom du bucket de sauvegarde. Ensuite, je pourrai revenir de ‘https://cdn.example.com/mon_nom_de_bucket’ à ‘https://cdn.example.com’.

De plus, je préfère ne pas utiliser l’adresse IP interne comme ‘S3 endpoint’. J’ai posé la même question à Nextcloud. Comment fonctionne le module S3 de Discourse ? Je me demande juste pourquoi je dois fournir l’adresse IP interne complète + le port au lieu du FQDN que j’ai attribué au niveau du serveur proxy. Le FQDN m’aide certainement à rediriger le trafic si l’un des serveurs MinIO tombe en panne. Avec le réglage actuel, si le serveur backend principal tombe en panne, la lecture peut fonctionner (via CDN), mais pas les actions d’écriture.

Ce pourrait être, ou je dirais, plus probablement dû à ma mauvaise configuration et/ou à une incompatibilité avec le SDK MinIO/AWS. Je vais me contenter d’une solution de contournement pour l’instant.

Il semble que vous utilisiez des buckets de style chemin (minio.example.com/nomdubucket), ce qui ne fonctionnera pas. Vous devez configurer MINIO_DOMAIN, ce qui activera implicitement les buckets de style hôte virtuel (nomdubucket.minio.example.com)

Voir Core Settings | AIStor Object Store Documentation

Merci pour la réponse rapide.

Je me demande alors pourquoi l’URL de l’image n’était pas « bucketname.cdn.example.com » ?
Était-ce parce que j’ai ajouté l’URL CDN qui fonctionne un peu comme l’URL de CloudFront ? Dans mon cas, sans URL CDN, je crains que le chemin du fichier image ne soit http://bucket_name.192.168.1.1:9000/original/1x/…

Si je dois effectivement attribuer un FQDN à chaque serveur MinIO et utiliser l’un des FQDN comme point de terminaison, alors le multi-serveur pour l’équilibrage de charge est inutile.