Problemi con Patreon Login, Force HTTPS e S3 CDN (tre) Problemi

Installazione
1

Potrei dover dividere questo in tre post separati, ma sono correlati, quindi inizierò con uno.

Qualche giorno fa, ho utilizzato questo tutorial (How to Scale a Discourse Deployment with a Load Balancer and Managed Database Cluster | DigitalOcean) praticamente alla lettera e ho migrato il mio Discourse Droplet standalone su Digital Ocean a due Droplet all’interno di un Load-Balancer, finora tutto bene.

Poi ho seguito questo tutorial (Configure an S3 compatible object storage provider for uploads), ma dopo aver ricostruito Discourse dalla riga di comando, il mio sito Discourse mostrava solo una schermata vuota. Ho controllato nell’Inspector del browser per scoprire che il browser stava bloccando tutto il mio contenuto perché veniva servito da HTTP e non da HTTPS. Questo è probabilmente dovuto al fatto che il load balancer è SSL Terminated, quindi tutto ciò che è esterno è HTTPS, ma i server stessi sono in esecuzione su HTTP.

A questo punto, ho completamente rovinato di nuovo i miei server, cercando di farli funzionare con HTTPS all’interno del Load-Balancer, ma semplicemente non è stato possibile. Non sono riuscito a far funzionare lo spazio/CDN di Digital Ocean con S3/CDN secondo questo tutorial (Configure an S3 compatible object storage provider for uploads). L’ho esaminato attentamente e ho ispezionato ogni aspetto più volte, ma non ha funzionato. L’unico modo per far ricostruire Discourse è stato rimuovere il parametro DISCOURSE_S3_ENDPOINT: https://sfo3.digitaloceanspaces.com da app.yml, ma poi, anche se si era ricostruito, non sono riuscito a far rispondere il server. Ho ottenuto un errore 503 server non rispondente o un normale errore del browser server non rispondente o server disconnesso. Differiva in base alle impostazioni del Load-Balancer e dello spazio/CDN di DO che stavo provando. Ho provato ogni possibile combinazione di impostazioni e nulla mi ha permesso di servire una pagina.

Quando ho lasciato il parametro DISCOURSE_S3_ENDPOINT attivo, ho ricevuto il seguente errore durante la ricostruzione di Discourse, ma è scomparso quando ho commentato il parametro S3_ENDPOINT.
Aws::S3::Errors::InvalidAccessKeyId: Aws::S3::Errors::InvalidAccessKeyId

Tutti i miei file sono stati sincronizzati su S3, quindi penso sia sicuro presumere che la chiave di accesso fosse corretta e il problema fosse causato in qualche modo dal parametro S3_ENDPOINT.

Oggi, ho rinunciato a cercare di far funzionare il tentativo precedente e ho ripristinato un backup dei miei Droplet che stavano solo bilanciando il carico con solo HTTP e finalmente sono riuscito a farlo funzionare di nuovo seguendo questo tutorial (Set up file and image uploads to S3), ma questa volta ho modificato le impostazioni S3 tramite il pannello di amministrazione di Discourse invece di modificare app.yml con le impostazioni nel tutorial consigliato. Alla fine ha funzionato, ma la differenza importante è che ho deliberatamente omesso le impostazioni del CDN S3. Ho confermato che le immagini caricate nei post vengono archiviate su S3 e posso eseguire il backup di Discourse direttamente su S3, ed è tutto ciò che voglio, ma ora ho tre problemi che mi perseguitano, uno è critico e due sono ignorabili, anche se vorrei confermarli qui, se possibile.

Quindi, il problema critico è che gli utenti non possono più accedere utilizzando il pulsante di accesso Patreon sulla pagina di accesso di Discourse. Viene visualizzato questo messaggio:
Mi dispiace, si è verificato un errore durante l’autorizzazione del tuo account. Riprova.

L’URL è questo:
https://mbp.community/auth/failure?message=invalid_credentials&origin=https%3A%2F%2Fmbp.community%2Flogin&strategy=patreon

Apprezzerei molto qualche consiglio su cosa potrei provare per far funzionare questo, ma di nuovo, mi chiedo se questo sia dovuto al fatto che internamente i server non stanno eseguendo HTTPS. Come puoi vedere dall’URL, esternamente sono su HTTPS, quindi è difficile saperlo con certezza. Immagino che speri che qualcuno qui abbia esperienza con il Load-Balancing di Digital Ocean, ecc. con Discourse.

Gli altri due problemi vengono ora segnalati nella Console di amministrazione come segue:

Alcuni consigli basati sulle impostazioni attuali del tuo sito

Quindi, non mi dispiace provare ad attivare force_https, ma temo che mi bloccherà l’accesso al mio server perché internamente i server bilanciati dal carico non sono in esecuzione su HTTPS e a causa dei problemi che ho avuto ieri, sono riluttante a passare altre dodici ore a sbattere la testa contro un muro guardando innumerevoli ricostruzioni di Discourse di 15 minuti senza ottenere nulla. Di nuovo, se qualcuno sa che è sicuro attivare force_https con le mie configurazioni, per favore fatemelo sapere.

E il secondo problema, di nuovo, non è andato bene tramite i parametri aggiunti al file app.yml, quindi sono riluttante a riprovare anche questo. Puoi confermare che questo farebbe essenzialmente la stessa cosa dei parametri aggiunti al file app.yml? Se è così, ignorerò semplicemente questo secondo messaggio. Al contrario, se per qualche motivo è sicuro provare, fammelo sapere e farò un backup e ci proverò.

Scusa per il post lungo. Spero tu possa capire cosa sto cercando di ottenere come consiglio.

1 Mi Piace
2

Allora avrai davvero bisogno di aiuto lì perché qui è supportata solo un’installazione standard.

Ti aspetti più di 200.000 visualizzazioni di pagina al giorno? Se no, un singolo droplet da 8 GB con CDN sarà molto più facile da gestire e probabilmente più economico. E da quello che posso capire, ci sono almeno un paio di modi in cui quelle istruzioni probabilmente non funzioneranno per nessuno.

Innanzitutto, hai configurato un redis esterno come descritto nel passaggio 5? Se no, mi aspetto che le cose siano almeno un po’ rotte. Implicano che l’uso di sticky “risolverà” il problema, ma in realtà non lo farà. Quindi puoi aspettarti errori spurii difficili da diagnosticare. E non specificano un modo per assicurarsi che tutte le tue istanze eseguano esattamente la stessa versione di Discourse, quindi anche questo probabilmente renderà le cose rotte.

Avresti davvero dovuto farlo prima, altrimenti, in realtà, quella configurazione non può funzionare, perché alcuni caricamenti saranno su un server e altri su un altro, e quelle istruzioni non menzionano la parola “upload”, quindi mi aspetto che se l’hai usato per più di un test, hai un bel pasticcio tra le mani e dovrai sincronizzare i caricamenti tra i tuoi droplet multipli.

Dichiara specificamente che la CDN di Digital Ocean non funziona con Discourse.

Hai usato una CDN diversa come raccomandato? Bunny.net è abbastanza facile e semplice da configurare.

2 Mi Piace
3

Oh cielo, non so chi abbia scritto quella guida, ma di sicuro non era qualcuno molto familiare con Discourse su larga scala.

L’ultimo passaggio dice che puoi aggiungere altri backend al load balancer utilizzando la funzione di snapshot del droplet, ma poiché la guida non menziona l’uso dell’Object Storage per i caricamenti, farlo romperà completamente i caricamenti degli utenti. Inoltre, se segui quella guida, gli aggiornamenti diventeranno non banali.

Il mio consiglio a @Martin_Bailey è di non seguire nulla di ciò che è scritto lì. Risulterà solo in un’installazione non funzionante, come hai scoperto.

Segui la nostra guida ufficiale all’installazione se desideri un’installazione rapida e sensata di Discourse. Uscire da quel percorso può rapidamente diventare un lavoro a tempo pieno.

3 Mi Piace
4

Divertente. Ho lasciato un commento lì delineando alcuni dei problemi e collegandomi al post di Rafael, ma è stato cancellato.

3 Mi Piace
5

Wow! OK, quindi pensavo fosse andato bene anche se c’erano alcune cose che ho notato essere errate, ma ora ho un’installazione bilanciata del carico. Naturalmente, la prima cosa che ho scoperto è che i caricamenti delle immagini non funzionavano, motivo per cui ho usato S3 per archiviare le immagini.

Per come stanno le cose, ci vorrà un altro carico di lavoro per tornare a un singolo server, quindi c’è qualcosa che posso fare riguardo al problema di accesso a Patreon? Ignorerò gli altri due problemi.

Grazie per il tuo aiuto in ogni caso. Fate un ottimo lavoro qui.

6

Ciao Jay, grazie per il tuo aiuto. In risposta alle tue domande…

Non mi aspetto molti utenti, dato che si tratta di una community Patreon chiusa. Il mio obiettivo principale era poter aggiornare un server senza che questo mandasse offline il sito. Ho infatti confermato che è possibile, quindi ero soddisfatto della configurazione. Sì, ho eseguito il passaggio cinque, quindi lo stato viene archiviato su un droplet Redis esterno.

L’altra cosa che ho dovuto capire, che mi ha bloccato per un po’, è stata la necessità di aggiungere anche il parametro qui sotto ad app.yml, altrimenti la ricostruzione continuava a fallire perché tentava di connettersi a Postgres sulla porta predefinita, nonostante avesse la porta effettiva nel parametro DISCOURSE_DB.

DISCOURSE_DB_BACKUP_PORT: 25060

Non avevo pensato ai caricamenti fino a dopo aver fatto funzionare tutto in base al primo tutorial, e inizialmente ha mandato tutto all’aria quando ho provato a configurare S3, ma questo perché le impostazioni del CDN di DO Space che fornite qui non funzionano.

Si afferma specificamente che il CDN di Digital Ocean non funziona con Discourse.

Lo so, ma poi il tutorial ci fa aggiungere questo:
DISCOURSE_S3_ENDPOINT: https://sfo3.digitaloceanspaces.com

Che proviene dallo spazio DO, giusto? Non ho idea, basandomi su tutto ciò che ho letto in questi tutorial, di come potrei lavorare con un CDN diverso, ma al momento non sono preoccupato, dato che ne parlerò tra un attimo.

No, non ho usato un CDN diverso. In realtà mi va bene non usare un CDN. Lascerò vuote le impostazioni del CDN. Come ulteriore aggiornamento, basandomi sui consigli che mi avete gentilmente fornito finora, stavo per ripristinare il mio backup della scorsa settimana, ma ho pensato di provare prima ad abilitare l’opzione force_https, e abilitandola si è risolto il problema di accesso a Patreon, come avevo pensato potesse accadere. Non è stato modificato nulla sui server, quindi il problema di accesso a Patreon è stato probabilmente causato da una logica interna di Discourse, anche se di nuovo, mi rendo conto (ora) che sto facendo qualcosa che non raccomandate o supportate.

Quindi, a questo punto, la mia configurazione è quasi come raccomanda il primo tutorial, ma immagini e backup vanno tutti su S3, senza CDN. Sta funzionando molto bene. Apprezzo che mi consigliate di usare semplicemente l’installazione standalone, ma mandare offline il sito per 15 minuti ogni volta che esce un aggiornamento è davvero doloroso. Proprio ieri ho trovato i vostri riferimenti a data.yml e web_only.yml per una configurazione multiservizio, ma non sono riuscito a capire cosa avrei dovuto fare, quindi ho rinunciato.

Per ora andrò avanti con quello che ho. Grazie per il tuo aiuto e per tutto quello che fate.

7

OK ragazzi, avete vinto. :slight_smile:

Ho iniziato a vedere altri problemi con le immagini che non si caricavano di nuovo perché a volte venivano condivise tramite http e non https. Avete ragione, è un casino.

Ho annullato quasi tutto, lasciando il database Postgres al suo posto ma tornando a un solo server droplet, senza load-balancer e con immagini/Redis archiviati localmente. Ho lasciato S3 per i backup del sito. Adoro quanto funzioni senza intoppi.

Suppongo che tornerò a interruzioni di 15 minuti con ogni aggiornamento, ma finora ho dedicato un totale di circa cinque giorni interi a questo, e non posso dedicarci più tempo, quindi sono felice che siate stati tutti in grado di correggermi riguardo al tutorial originale che ho seguito. È quasi come se volessero solo che la gente pagasse per più Droplets. :slight_smile:

Grazie ancora per il vostro aiuto.

8

In realtà, se potessi chiedere, esiste un tutorial che ci aiuti a configurare Discourse in modo da evitare l’interruzione di 15 minuti ad ogni aggiornamento. Ho visto la nota su data.yml e web_only.yml ma non ho idea di cosa devo fare per realizzarlo.

9

Avere file YAML data e web_only separati deriva dalla configurazione a due container:

1 Mi Piace
10

Questo funzionerà e risolverà alcuni problemi. E se dovessi rimanere bloccato fuori per qualche (altro) motivo, puoi sempre usare launcher enter app per rientrare e disattivare l’impostazione del sito dalla console Rails.

Come altri hanno già detto, è meglio seguire una guida diversa.

1 Mi Piace
11

Ciao ragazzi,

Ho scritto quell’articolo su DigitalOcean, sembra che abbia commesso alcuni errori, colpa mia!

Vorrei aggiornare l’articolo per correggere i problemi.

Quindi vorrei solo fare alcune domande per assicurarmi di fare le cose per bene con la versione corretta.

Nell’articolo ho detto che si poteva usare facoltativamente un’istanza Managed Redis, il mio pensiero all’epoca era che l’uso di sticky session avrebbe permesso di usare il Redis integrato nell’immagine di Discourse. È corretto? Forse questo non è sufficiente e un’istanza Redis esterna dovrebbe essere un requisito obbligatorio.

Sono d’accordo con il commento di @Falco riguardo all’Object Storage, è una mia dimenticanza. Posso aggiornare l’articolo per includere le istruzioni per l’uso di DigitalOcean Spaces per gestire i caricamenti di immagini.

Sospetto che rimuovere tutto lo stato dai Droplet sia la risposta per risolvere i problemi di installazione, speravo che l’uso di un Redis esterno fosse facoltativo a causa delle sticky session, ma potrei sbagliarmi.

Sono anche d’accordo sul fatto che questo renda la tua installazione di Discourse più complicata da aggiornare, penso però che se rimuovi tutto lo stato dai Droplet, dovresti essere in grado di aggiornarne solo uno, quindi creare uno snapshot e sostituire gli altri Droplet con nuovi creati dagli snapshot (un po’ come i Deployments di Kubernetes, tranne che esegui il re-deployment manualmente).

Sono anche d’accordo sul fatto che probabilmente ci sono modi migliori per scalare Discourse, vorrei comunque correggere l’articolo in modo che le persone possano seguirlo se lo desiderano.

Grazie,
Francis

12

Sono un felice cliente di Digital Ocean e ho una dashboard in cui i miei clienti inseriscono chiavi API e un nome host, quindi crea automaticamente un droplet, configura Mailgun, attende la configurazione dei record DNS e quindi installa Discourse.

Non funziona affatto come suggerisci. Ho contattato DigitalOcean sul tuo forum (non ho trovato un altro modo) per informarti e il mio messaggio è stato cancellato. Poi, 9 mesi dopo, rispondi qui.

Farcela correttamente è un’impresa piuttosto complicata e i casi in cui sarebbe utile sono piuttosto improbabili. Ho un sito con 100.000 visualizzazioni di pagina al giorno su un droplet da 8 GB. Chi pensi che sia il pubblico di destinazione per questa guida?

Sì, hai bisogno di Redis esterno, PostgreSQL e bucket S3 con una CDN, e la CDN di Digital Ocean non funziona, quindi la tua guida dovrebbe guidarli attraverso la configurazione della CDN di un’altra azienda. Non credo che tu voglia farlo. E questo è solo per la configurazione. Se poi vogliono fare un aggiornamento, sarebbe un’altra serie di procedure che nessun altro sul pianeta saprebbe come aiutare.

La cosa migliore che potresti fare sarebbe eliminare del tutto quella guida. Se vuoi essere un vero eroe, potresti correggere l’installazione “1-click” in modo che non utilizzi il tuo script proprietario per la configurazione dell’email e così via, in modo che sia effettivamente un’installazione standard. È piuttosto confuso dover premere control-c per poter arrivare a dove si trova Discourse, e poiché le persone che hanno utilizzato l’installazione “1-click” non hanno utilizzato gli strumenti standard di Discourse, non sanno come usarli quando arriva il momento di un aggiornamento da riga di comando. Sarebbe davvero, davvero fantastico se potessi farlo.

Qui puoi vedere persone che l’hanno usato e hanno avuto problemi: Search results for 'digital ocean one-click' - Discourse Meta

1 Mi Piace
13

No, poiché Redis non è una semplice cache, ma gestisce molti conteggi, limiti di frequenza, processi in background, pub sub. Avere più Redis comporterà conteggi corrotti e comportamenti errati.

Ciò risolverebbe il problema, ma aggiungere un Redis gestito, un PostgreSQL gestito, un Load Balancer gestito, Object Storage, Container Registry sarebbe anche più costoso che pagare semplicemente per il nostro hosting standard e molto più complicato da mantenere.

A quel punto l’intersezione tra le persone che vogliono pagare centinaia di dollari al mese e non si preoccupano se il loro servizio va in crash a causa di un SPOF è piuttosto piccola, e diventa più una configurazione per hobbisti che ciò che raccomanderemmo per gli amministratori di forum.

1 Mi Piace