Quali sono le impostazioni corrette per usare S3 bucket (con URL non-Amazon)?

Quindi ho configurato un bucket Amazon S3 per memorizzare le risorse del mio forum, l’ho associato a un dominio personalizzato e ho impostato CloudFlare CDN per memorizzare nella cache i contenuti.

Il mio dominio personalizzato è qualcosa come http://forum-storage.com, che punta a https://forum-storage.com.s3-us-east-1.amazonaws.com. Il bucket S3 stesso si chiama forum-storage.com.

Tutto funziona correttamente. Se aggiungo un’immagine nella cartella principale del bucket, posso recuperarla tramite il mio URL personalizzato, ovvero http://forum-storage.com/test.jpg restituisce l’immagine, con gli header di CloudFlare.

Tre domande semplici…

#1

Ora devo indicare a Discourse di utilizzare questo nuovo URL come bucket S3. Cosa devo inserire in questi 3 campi?

#2

Attualmente ho immagini nei post del forum che si trovano su un altro bucket S3, e ho anche immagini memorizzate localmente. (I miei URL delle immagini sono sparsi un po’ ovunque.)

Una volta apportate le modifiche corrette (sopra), ciò significa che tutte le NUOVE risorse aggiunte al forum verranno inserite nel nuovo bucket, ma le immagini esistenti non verranno spostate e continueranno ad essere accessibili dove risiedono attualmente, corretto?

#3

Ora che tutto funziona per tutte le immagini da questo momento in poi, come posso indicare a Discourse di SPOSTARE tutte le vecchie immagini che non sono in questo nuovo bucket nel nuovo bucket (e rigenerare i post se necessario)?

L’obiettivo è mettere tutto in un unico bucket, questo nuovo bucket dietro la CDN.

:rotating_light: FERMATI ORA :rotating_light:

Crea un nuovo bucket che non contenga un punto nel nome. Continueresti a incontrare problemi infiniti se procedi, a causa del funzionamento dei certificati SSL wildcard.

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

Hmmm ok. Un piccolo intoppo momentaneo! :wink: Grazie per l’avviso @riking.

AWS S3 ha una funzionalità per cui se dai al bucket lo stesso nome del dominio, puoi semplicemente aggiungere un record CNAME al dominio e tutto funziona automaticamente.

Quindi ora sto cercando ovunque informazioni su come collegare un dominio a un bucket che non ha lo stesso nome del dominio… hmm

@BryanV come hai puntato https://discourse-uploads.bokeh.org al tuo bucket S3?

Hmm, è carino, ma vorresti avere un CDN, ad esempio CloudFront, davanti al bucket, che riceverà il CNAME, quindi al momento non è una funzionalità utile.

Non avere un CDN ti porterà comunque una fattura di trasferimento esorbitante.

Giusto. Credo che siamo sulla stessa lunghezza d’onda? Per essere più chiari, per quanto ne capisco, ci sono tre modi per collegare Discourse e S3:

  1. Far usare a Discourse direttamente il cloud S3. Vantaggi: configurazione estremamente semplice. Svantaggi: diventa rapidamente costoso.

  2. Far usare a Discourse il cloud S3 tramite un dominio personalizzato (come forum-storage.com) in modo da poter utilizzare una CDN. Vantaggi: configurazione molto semplice con S3 se il nome del bucket corrisponde esattamente al dominio personalizzato (ad esempio forum-storage.com.s3-amazon-aws.com). Svantaggi: i certificati SSL danno problemi.

  3. Far usare a Discourse il cloud S3 tramite un dominio personalizzato (di nuovo, per poter utilizzare una CDN), ma configurare il bucket S3 in modo che il nome non contenga un punto aggiuntivo (ad esempio forum-storage-com.s3-amazon-aws.com). Vantaggi: i certificati SSL funzionano correttamente. Svantaggi: configurazione non così semplice con Amazon S3.

Quindi… stavo usando l’opzione #1 fino a quando non ho ricevuto la fattura :slight_smile: poi ho scoperto che l’opzione #2 era possibile, l’ho configurata, ho avviato questa discussione e ho subito scoperto che l’opzione #2 non era davvero fattibile.

Ora sto lavorando sull’opzione #3. Credo di dover utilizzare il servizio DNS “Route 53” di Amazon, o qualcosa di simile. Sto ancora cercando di capire come fare. Tutte le ricerche che ho fatto su Google restituiscono informazioni su come implementare l’opzione #2, ma nessuno sembra aver scritto istruzioni chiare per l’opzione #3.

Per favore, correggetemi se sbaglio o se ho frainteso qualcosa…

Ci sono tutorial per questo, ad esempio ho appena trovato questo per StackPath:

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

@BryanV come hai puntato https://discourse-uploads.bokeh.org al tuo bucket S3?

Ho aggiunto un record CNAME che punta all’URL .cloudfront.net per la distribuzione CDN di Cloudfront alla nostra configurazione DNS per bokeh.org (che nel nostro caso si trova su Cloudflare, ma ciò non dovrebbe avere importanza).

Per riferimento, il nostro bucket S3 non contiene punti nel nome, ma non ricordo problemi specifici nella configurazione della CDN a causa di ciò (né problemi nella creazione del bucket, che richiede semplicemente un nome univoco).

Questa è, senza alcun dubbio, la cosa più frustrante in assoluto. Per quanto ci provi, non riesco a capire come collegare un bucket Amazon S3 (con un nome senza punti!), il mio dominio personalizzato e CloudFlare in modo che funzionino tutti insieme. Se potessi inserire un punto nel nome del bucket, non ci sarebbero problemi. Ma al momento è tutto troppo confuso. Ughhhhhh, può qualcuno aiutarmi o indicarmi un modo semplice per configurare CloudFlare con un bucket S3 che non abbia lo stesso nome del dominio?

Ho provato le informazioni StackPath sopra riportate: penso di aver fatto qualcosa di simile su CloudFlare, ma non sono sicuro. Non ha funzionato. Ho anche letto le informazioni di CloudFlare su come aggiungere la CDN a un bucket Amazon, ma ovviamente vogliono che il nome del bucket coincida con quello del dominio, cosa che mi è stata detta essere una pessima idea e che non posso fare.

Sembra davvero che tutto si riduca a questo:

  • Se il nome del bucket è uguale al nome del dominio (con un punto), Amazon S3 se ne occupa per me: splendido, meraviglioso, tranne il fatto che crea problemi con SSL, quindi non dovrei farlo.
  • Se il nome del bucket NON corrisponde al nome del dominio, tutto diventa enormemente più complicato e non riesco a risolverlo.

Qualcuno può aiutarmi o darmi un consiglio? Nel frattempo, mi arrivano bollette di oltre 100 dollari ogni mese per lo storage S3. È una situazione terribile. Potrei pagare qualcuno 200 dollari ora per risolvere tutto questo? Blargh.

L’hai già letto? Anche io ho avuto difficoltà a configurare S3 e Cloudflare, ma alla fine ci sono riuscito. Puoi comunque usare Cloudflare per i suoi vantaggi in termini di sicurezza, ma sono abbastanza sicuro che ti serva anche un servizio CDN separato. Cloudflare non è come una CDN normale, funziona in modo diverso. Dovresti passare a un servizio S3 più economico, Amazon è costoso.

Utilizzare Cloudflare per memorizzare nella cache un bucket S3 richiede la manipolazione dell’header origin nelle richieste. Questa funzionalità è disponibile nel piano Enterprise di Cloudflare, quindi potrebbe essere più semplice utilizzare un’altra CDN.

Il punto nel nome del bucket non è irrilevante se le immagini verranno comunque memorizzate nella cache tramite CDN? L’unica cosa che conta è avere un certificato valido che copra le immagini servite da Cloudflare.

Credo che debba concentrarsi sui server di Cloudflare, sul DNS e sul certificato per coprire quell’aspetto. Non penso che l’utente o il browser verranno mai a sapere che la fonte di queste immagini è un bucket S3. Cloudflare memorizzerà nella cache e farà da proxy per l’immagine stessa, giusto?

Discourse genererà URL diretti per i bucket e li utilizzerà per operazioni interne, come “caricare un file”. Questo è ancora rilevante.

@riking Tutto ciò che sembra richiedere Discourse è un nome di bucket, corretto? Il caricamento e la gestione possono essere effettuati tramite URL di AWS con i loro certificati, se l’HTTPS è addirittura necessario. Finora, c’è qualche motivo per cui stiamo parlando di certificati di sicurezza?

L’OP può poi esaminare separatamente cosa deve fare per permettere alla sua CDN o soluzione di caching di recuperare le immagini da S3. Che siano sicure o meno, non importa a meno che l’OP o la CDN non abbiano requisiti specifici, giusto? Discourse si preoccupa della configurazione dell’OP tra S3 e CDN?

Infine, l’OP deve assicurarsi che le immagini vengano servite dalla CDN con un certificato valido. Questo ha qualcosa a che fare con Discourse oltre al fatto che l’OP fornirà l’URL di base dove risiederanno le immagini? Una volta che la sua CDN o cache avrà recuperato le immagini da S3, allora AWS, i bucket, e via dicendo escono completamente di scena.

Capisco che ci siano problemi relativi a un punto nei nomi dei bucket S3 se si intende servire le immagini direttamente da lì, ma l’OP NON lo fa. Quindi si riduce tutto a scegliere un nome di bucket qualsiasi che Discourse accetti, purché non interferisca con la configurazione che l’OP ha con la CDN.

Anche se è possibile evitare gli URL bucket-in-domain, in realtà non vengono evitati a causa del modo in cui viene utilizzato l’SDK di AWS S3 e delle difficoltà di configurazione.

Ancora una volta, queste operazioni aggirano la CDN; l’unico modo per risolverle è intervenire nel codice sorgente di Discourse. Possono essere corrette, ma al momento non lo sono. Molti di questi problemi non si verificano sul percorso critico e si manifestano solo in un secondo momento. Quindi, finché non cambierà qualcosa, non utilizzare nomi di bucket contenenti punti.

Quindi, per semplificare al massimo… La domanda dell’OP era cosa inserire in tre impostazioni da configurare:

(1) NOME DEL BUCKET – quindi si dice che i punti non sono… consigliati? non consentiti? Sospetto che questo potrebbe non essere un problema per l’OP. (Deve solo trovare un modo separato per far sì che la sua CDN memorizzi e serva le immagini.) Quindi siamo tutti sulla stessa lunghezza d’onda, giusto?

(2) ENDPOINT S3 – lasciarlo vuoto, non serve nulla se sta utilizzando AWS, altrimenti può compilare per un altro provider?

(3) URL CDN S3 – è semplicemente l’URL di base che Discourse premette al percorso dell’immagine? Se è così, allora è semplice e diretto e l’OP può configurare la sua CDN e fornire quell’URL di base qui.

Non vedo come i certificati SSL wildcard entrino in gioco in questo. All’OP è stato detto che un punto nella configurazione di Discourse è negativo perché romperà il suo certificato. Ma se sta utilizzando una CDN o una cache, il nome del bucket potrebbe essere del tutto irrilevante per il certificato, giusto? Se ciò romperà Discourse in un altro modo, è utile saperlo.

Non sono sicuro di seguire tutto così da vicino, ma per allargare un po’ la prospettiva, forse questo semplice insieme di requisiti può aiutare:

Gli obiettivi:

  1. Non memorizzare le immagini del mio Discourse sul server Discourse
  2. Avere un bucket S3 per memorizzare le immagini (deve essere S3 poiché è ciò che Discourse supporta)
  3. Non avere costi S3 elevati
  4. Una CDN non è obbligatoria, ma è un bel vantaggio poiché potrebbe aiutare a ridurre (o essere l’unico modo per eliminare) i costi S3 elevati e fornisce anche una migliore disponibilità in tutto il mondo, un backup nel caso in cui il server principale vada offline, ecc., ecc.

Correggetemi se qualcosa di tutto ciò è errato

Limitazioni/requisiti:

  1. L’archivio immagini esterno deve supportare il protocollo S3 (poiché è con quello che lavora Discourse), ma, strettamente parlando, non deve essere l’S3 di Amazon.
  2. Discourse richiede che il nome del bucket S3 non contenga punti.
  3. La sorgente delle immagini (S3 o CDN) deve servire contenuti via https:// poiché un browser protesterà se la pagina è in https ma le immagini no.

Correggetemi se qualcosa di tutto ciò è errato

Soluzioni:

In precedenza, servivo direttamente da Amazon S3. Funzionava benissimo, tranne per il fatto che i costi di Amazon per DataTransfer-Out-Bytes sono super costosi. Questo ha portato a bollette mensili elevate da parte di Amazon! Quindi l’ho riportato sul server principale. Due possibili soluzioni: posizionare una CDN davanti al bucket Amazon S3 in modo che la CDN gestisca tutto il trasferimento dati e/o passare a un provider S3 diverso.

Ho provato a mettere la CDN CloudFlare sopra il bucket Amazon S3, ma molto rapidamente ho incontrato molti problemi che non sono riuscito a risolvere.

Un’altra opzione?

Stavo guardando questa offerta di archiviazione compatibile con S3 di Digital Ocean. CDN integrata (non sono sicuro di cosa significhi esattamente, ma sembra promettente), prezzi vantaggiosi. Funzionerebbe con Discourse?

Per riferimento, ho servito circa 300 GB da S3 negli ultimi 30 giorni. Una parte di ciò sono backup del sito, una grande parte sono immagini statiche. È MOLTO difficile per me capire come misurare queste cose su Amazon… la loro interfaccia di reporting delle fatture, come tutto il resto di Amazon AWS, è davvero confusa da amministrare.

Credo che la soluzione più semplice sia AWS e KeyCDN, seguendo le linee guida di Utilizzo dell’archiviazione oggetti per i caricamenti (S3 e cloni). Se i tuoi utenti non si trovano in Sud America, KeyCDN è piuttosto economico e facile da configurare.

Una soluzione potenzialmente meno costosa potrebbe essere Come configurare BackBlaze S3 con BunnyCDN. Sono rimasto soddisfatto di BackBlaze nei miei test iniziali per i backup, ma non l’ho ancora provato per i caricamenti.

Ci siamo lasciati distrarre in modo eccessivo da un punto nel nome di un bucket e dai certificati del browser, ma penso che tutta quella discussione sia completamente irrilevante. QUALSIASI CDN permetterà la configurazione HTTPS, quindi c’è ZERO PROBLEMA con il problema del “certificato wildcard” e con la presenza o assenza di un punto nel nome del bucket PER QUANTO RIGUARDA IL CERTIFICATO DEL BROWSER DELL’UTENTE FINALE. Perché, ripeto, QUALSIASI CDN lo permetterà sicuramente.

Quindi l’OP può semplicemente…
(1) scegliere una soluzione di storage compatibile con S3 e CDN e configurare l’endpoint e il nome del bucket nelle impostazioni di Discourse.
(2) configurare la CDN per recuperare le immagini da S3. In modo sicuro o non sicuro. Non credo che all’OP importi, purché la CDN serva le immagini all’utente tramite HTTPS.

Qualcuno prego correggetemi se sto trascurando qualcosa. Penso che il problema del certificato del browser dell’utente finale più il punto nel nome del bucket sia UN PROBLEMA SOLO se si intendono servire le immagini DIRETTAMENTE dal bucket. Irrilevante per la distribuzione tramite CDN.

P.S. Questo argomento, a cui @pfaffman ha gentilmente fatto riferimento sopra, segnala che il servizio S3 di Digital Ocean (“Spaces”) ha una CDN “terribilmente difettosa”.

E vedo che per altri provider S3 ci sono varie impostazioni che devono essere modificate.

Ciò che questo mi sta dicendo:

  • Le impostazioni varieranno da provider a provider, anche se tutti affermano di seguire il protocollo “S3”.

Ancora

:warning: Non inserire un punto (.) nel nome del bucket

Intendo, a meno che tu non ami soffrire.