URL CDN S3 con nome bucket? - MinIO

,

Sto eseguendo un’istanza multi-server MinIO dietro un server proxy Nginx.
Per l’integrazione MinIO, ho avuto problemi e oggi ho scoperto che devo impostare ‘S3 CDN URL’ non come ‘cdn.example.com’, ma come ‘cdn.example.com/nome_bucket’ per visualizzare le immagini caricate.

Potrebbe essere dovuto a un mio problema di configurazione MinIO, quindi fornirò maggiori informazioni.
Ho due server che eseguono MinIO per gli stessi contenuti. Entrambi sono mappati con IP interni, come 192.168.1.1 e 192.168.1.2. La porta di accesso API è, diciamo, 9000 e la porta di accesso Console è 9001. (Sebbene utilizzi IP e porte diversi, è a scopo illustrativo.)

Inizialmente ho avuto problemi con ‘S3 endpoint’.

Con ‘https://cdn.example.com’ come endpoint, continuavo a ricevere errori. Ho anche provato con l’accesso alla console, come ‘s3.example.com’, l’URL che utilizzo per distribuire il traffico a livello di server proxy Nginx per la console. Nessuno dei due ha funzionato.

Oggi ho cambiato l’endpoint in ‘http://192.168.1.1:9000’, come faccio con NextCloud. (Ho avuto problemi simili con NextCloud). Finalmente, ho potuto vedere che i file vengono caricati su S3. Tuttavia, non sono ancora riuscito a vedere l’immagine su Discourse. Quando ho controllato l’URL dell’immagine vuota, era simile a ‘cdn.example.com/original/1x/…’ In altre parole, mancava il nome del bucket S3 che ho aggiunto all’impostazione.

Quindi, ho cambiato ‘S3 CDN URL’ in ‘https://cdn.example.com/nome_mio_bucket’. Finalmente posso vedere l’immagine nell’editor di argomenti di Discourse e sul sito web live.

Poiché funziona, stavo per passare ad altri siti web, ma poi vedo che ‘S3 Backup Bucket’ deve essere un nome di bucket diverso da quello di caricamento principale. Se abilito ‘Usa CDN URL per tutti i file caricati su s3 invece che solo per le immagini’, cosa succede al backup S3? Caricherà il file di backup su ‘https://cdn.example.com/backup_bucket’?

Quindi ho provato a eseguire un backup. Come previsto, ho ricevuto il messaggio di errore per il backup.

Per ora, a meno che non abbia configurato male MinIO e/o Discourse, penso che abbia senso che ‘S3 CDN URL’ debba aggiungere il nome del bucket di caricamento principale e il nome del bucket di backup. Quindi, potrei tornare da ‘https://cdn.example.com/nome_mio_bucket’ a ‘https://cdn.example.com’.

Inoltre, preferisco non utilizzare l’IP interno come ‘S3 endpoint’. Ho posto la stessa domanda a Nextcloud. Come funziona il modulo S3 di Discourse? Mi chiedo solo perché devo fornire l’IP interno completo + la porta invece del FQDN che ho assegnato a livello di server proxy. Il FQDN mi aiuta sicuramente a reindirizzare il traffico se uno dei server MinIO dovesse fallire. Con l’impostazione attuale, se il server backend principale si guasta, la lettura potrebbe funzionare (tramite CDN), ma non le azioni di scrittura.

Potrebbe essere, o direi, più probabilmente è dovuto alla mia errata configurazione e/o incompatibilità con MinIO/AWS SDK. Per ora mi accontenterò di una soluzione temporanea.

Sembra che tu stia utilizzando bucket in stile percorso (minio.example.com/bucketname), che non funzioneranno. Devi configurare MINIO_DOMAIN che abiliterà implicitamente i bucket in stile virtual-host (bucketname.minio.example.com)

Vedi Core Settings | AIStor Object Store Documentation

Grazie per la rapida risposta.

Allora, mi chiedo solo perché l’URL dell’immagine non fosse ‘bucketname.cdn.example.com’?
È stato perché ho aggiunto l’URL CDN che funziona in modo simile all’URL di CloudFront? Nel mio caso, senza l’URL CDN, temo che il percorso del file immagine possa essere http://bucket_name.192.168.1.1:9000/original/1x/…

Se devo effettivamente assegnare un FQDN a MinIO di ciascun server e devo usare uno dei FQDN come endpoint, allora il multi-server per il bilanciamento del carico è inutile.