CDN per sito completo con AWS CloudFront

Ciao a tutti. Recentemente ho configurato la mia installazione di Discourse utilizzando AWS CloudFront (CF) per l’accelerazione completa del sito e lo scaricamento SSL utilizzando certificati AWS in CF. Si noti che questa installazione si discosta dalla guida ufficiale per quanto riguarda la configurazione CDN e SSL, quindi potrebbe essere controversa e portare a futuri problemi di supporto. Quindi, siete avvisati… ci sono draghi qui. Condivido la configurazione che ha funzionato per me qui:

  1. Configura discourse per ascoltare solo sulla porta 80 e disabilita Let’s Encrypt commentando le righe indicate in app.yml:

  2. Configura discourse per prestare attenzione all’header CF, cloudfront-forwarded-proto, piuttosto che a x-forwarded-proto (che CF non passa e stranamente non può essere configurato per passare all’origine… assurdo! :angry:)

  3. Configura la tua distribuzione CF con un cname per il tuo nome host pubblico previsto (ad es. forum.example.com) utilizzando un certificato AWS ACM (che hai generato).

  4. Configura l’origine CF utilizzando l’IP elastico pubblico del server EC2 che ospita discourse (ad es. ec2-xxx-xxx-xxx-xxx.compute-1.amazonaws.com). configurarlo solo per http (cioè solo porta 80 - no 443). non è necessario configurare la tua origine con un nome host sofisticato in DNS come forum-origin.example.com. Il nome host o l’IP di EC2 vanno benissimo.

  5. Configura i “behaviors” di CF per i diversi percorsi di richiesta. La chiave qui è configurare il comportamento di caching per le cose che sono ovviamente risorse statiche; e configurare il non-caching per tutto il resto (cioè, quelle richieste vengono semplicemente passate così come sono all’origine senza caching). Un’altra cosa fondamentale qui è che l’ultima regola di pass-through (“default”) utilizza una “politica di richiesta di origine” personalizzata che passa tutti gli header originali all’origine oltre all’header CF cloudfront-forwarded-proto. Configura anche i reindirizzamenti da http a https nei tuoi behaviors, in modo che tutte le richieste degli utenti finali vengano forzate a https da CF.

  6. Non configurare “DISCOURSE_CDN_URL”

  7. Abilita “force https”

  8. Non configurare “long polling base url” - lascialo vuoto. Nonostante tutti gli avvertimenti severi sul fatto che questo sia problematico quando viene passato attraverso un proxy, finora sta funzionando bene per me. Forse il keep alive predefinito di CF è abbastanza lungo da impedirgli di interrompere la connessione.

Penso che sia tutto… :thinking:

Il risultato finale è che tutte le richieste, http/documenti, tutte le risorse statiche di supporto, tutte le chiamate ajax, ecc. sono tutte servite sullo stesso nome di dominio (ad es. forum.example.com). Il comportamento di caching (e il comportamento di pass-through) è dettato dai tuoi “behaviors” configurati in CF. E tutte le connessioni sono crittografate utilizzando certificati AWS ACM terminati sul bordo CF - e quindi il traffico non crittografato/http viene inviato al server di origine.

Oserei dire che questo potrebbe essere più pulito di quello che meta.discourse.org sta facendo al momento :shushing_face:.

7 Mi Piace

Ciao @jaffadog

Mi trovo in uno scenario simile ma in modalità sito completo con una CDN diversa. Nel tuo esperimento, hai mai testato la configurazione di DISCOURSE_CDN_URL con l’URL del dominio del sito web. Ad esempio, in modalità CDN completa, se l’URL del tuo sito web è https://foo.bar.com; allora l’URL della CDN dovrebbe essere lo stesso https://foo.bar.com. Se lasciamo DISCOURSE_CDN_URL vuoto, l’URL delle risorse del sito web inizierà con un percorso relativo. Ad esempio, come nello snippet seguente,

      <link rel="preload" href="/extra-locales/admin?v=8f522e122c802d1ed66dfa7fecafbb35" as="script">
      <script defer src="/extra-locales/admin?v=8f522e122c802d1ed66dfa7fecafbb35"></script>

Questo semplicemente non sembra elegante in un sito web di produzione, sebbene entrambi gli URL effettuino richieste a https://foo.bar.com.