S3 CDN URL mit Bucket-Name? - MinIO

,

Ich betreibe eine MinIO-Multi-Server-Instanz hinter einem Nginx-Proxy-Server.
Bei der MinIO-Integration hatte ich Schwierigkeiten bei der Integration und habe heute festgestellt, dass ich ‘S3 CDN URL’ nicht als ‘cdn.example.com’, sondern als ‘cdn.example.com/bucket_name’ einstellen muss, um hochgeladene Bilder anzuzeigen.

Es könnte an meinen eigenen MinIO-Einstellungen liegen, daher gebe ich hier ein paar weitere Informationen.
Ich habe zwei Server, auf denen MinIO für dieselben Inhalte läuft. Beide sind mit internen IPs wie 192.168.1.1 und 192.168.1.2 zugeordnet. Der API-Zugriffsport ist z. B. 9000 und der Konsolenzugriffsport ist 9001. (Obwohl ich unterschiedliche IPs und Ports verwende, dient dies nur zur Veranschaulichung.)

Ich hatte anfangs Probleme mit dem ‘S3-Endpunkt’.
Mit ‘https://cdn.example.com’ als Endpunkt erhielt ich ständig Fehler. Ich habe auch versucht, über den Konsolenzugriff zu gehen, wie z. B. ‘s3.example.com’, die URL, die ich auf der Nginx-Proxy-Server-Ebene für die Konsole zur Verteilung des Datenverkehrs verwende. Keines von beiden funktionierte.

Heute habe ich den Endpunkt auf ‘http://192.168.1.1:9000’ geändert, wie ich es bei NextCloud tue. (Ich hatte ähnliche Probleme mit NextCloud). Endlich konnte ich sehen, dass Dateien nach S3 hochgeladen werden. Ich konnte das Bild jedoch immer noch nicht in Discourse sehen. Als ich die URL des leeren Bildes überprüfte, sah sie so aus: ‘cdn.example.com/original/1x/…’. Mit anderen Worten, der S3-Bucket-Name, den ich in die Einstellung eingefügt hatte, fehlte.

Also habe ich ‘S3 CDN URL’ in ‘https://cdn.example.com/my_bucket_name’ geändert. Endlich kann ich das Bild in der Discourse-Themenbearbeitung sowie auf der Live-Website sehen.

Da es funktioniert, wollte ich mich zurückziehen und zu meinen anderen Websites zurückkehren, aber dann sehe ich, dass ‘S3 Backup Bucket’ ein anderer Bucket-Name sein muss als der Haupt-Upload-Bucket. Wenn ich ‘Use CDN URL for all the files uploaded to s3 instead of only for images’ aktiviere, was passiert dann mit dem S3-Backup? Wird die Backup-Datei nach ‘https://cdn.example.com/backup_bucket’ hochgeladen?

Also habe ich versucht, ein Backup durchzuführen. Wie erwartet, erhielt ich die Fehlermeldung für das Backup.

Vorerst, es sei denn, ich habe MinIO und/oder Discourse falsch konfiguriert, denke ich, dass es sinnvoll ist, dass ‘S3 CDN URL’ den Namen des Haupt-Upload-Buckets und den Namen des Backup-Buckets anhängen sollte. Dann kann ich von ‘https://cdn.example.com/my_bucket_name’ zu ‘https://cdn.example.com’ zurückkehren.

Außerdem ziehe ich es vor, keine interne IP als ‘S3-Endpunkt’ zu verwenden. Ich habe die gleiche Frage an Nextcloud gestellt. Wie funktioniert das S3-Modul von Discourse? Ich frage mich nur, warum ich die vollständige interne IP + Port anstelle des FQDN angeben muss, den ich auf der Proxy-Server-Ebene zugewiesen habe. Der FQDN hilft mir sicherlich, den Datenverkehr umzuleiten, wenn einer der MinIO-Server ausfällt. Mit der aktuellen Einstellung, wenn der Haupt-Backend-Server ausfällt, kann das Lesen funktionieren (durch CDN), aber keine Schreibvorgänge.

Könnte sein, oder ich sage, es liegt eher an meiner Fehlkonfiguration und/oder Inkompatibilität mit dem MinIO/AWS SDK. Ich werde mich vorerst mit einem Workaround begnügen.

Sie scheinen Pfad-Style-Buckets zu verwenden (minio.example.com/bucketname), was nicht funktionieren wird. Sie müssen MINIO_DOMAIN konfigurieren, was implizit virtuelle-Host-Style-Buckets (bucketname.minio.example.com) aktiviert.

Siehe Core Settings | AIStor Object Store Documentation

Vielen Dank für die schnelle Antwort.

Ich frage mich dann, warum die Bild-URL nicht ‘bucketname.cdn.example.com’ war?
Lag es daran, dass ich die CDN-URL hinzugefügt habe, die wie die URL von CloudFront funktioniert? In meinem Fall befürchte ich, dass der Bilddateipfad ohne CDN-URL http://bucket_name.192.168.1.1:9000/original/1x/… lauten könnte.

Wenn ich jedem Server von MinIO tatsächlich einen FQDN zuweisen und einen der FQDN als Endpunkt verwenden muss, dann ist Multi-Server für Load Balancing sinnlos.