Discourse + web server. Possibile o meglio evitare?

Supporto Installazione
1

Breve disclaimer: sono relativamente nuovo alla creazione di un ambiente VPS da zero, ma ho abbastanza esperienza con l’hosting web (in particolare shared e managed-dedi) per avere un’idea di ciò che sto facendo e per comprendere i tutorial.

Detto questo, sto attualmente utilizzando il droplet più economico di DigitalOcean per esperimenti. Sono un hobbista, non mi aspetto un traffico elevato e sto cercando di creare due istanze che offrano una pagina principale di qualche tipo (probabilmente WordPress) e un forum Discourse abbinato: un’istanza per il game design e un’altra per la mia community di creatori di contenuti.

So che Discourse e Apache non funzionano bene insieme a causa della decisione di Discourse di utilizzare la porta 80, e so anche che esistono soluzioni alternative, ma sembrano esserci diverse varianti con risultati non confermati e nessuna dichiarazione ufficiale di Discourse che dica “sì, questo funziona”.

Sono un po’ confuso sul motivo per cui una piattaforma così straordinaria sia stata progettata in modo da essere così ostacolante nella gestione di un server web insieme ad essa, ma la mia esperienza con il software finora mi ha reso abbastanza interessato da trovare un modo per farla funzionare. Ho visto che esiste un’integrazione con WordPress ed è promossa in una pagina delle funzionalità, ma ancora una volta, Discourse sembra non essere progettato per essere altro che standalone.

Qualsiasi consiglio o contributo da parte di chi si è trovato nella stessa situazione? Grazie!

2

Penso che questo sia ciò che stai cercando:

@neounix ha esperienza nell’esecuzione di Discourse con apache2, quindi potrebbe essere in grado di fornire alcuni suggerimenti.

3

Quindi è una raccomandazione per passare a Nginx? Non ho assolutamente esperienza con esso e ogni server web che ho mai utilizzato, anche quelli preconfigurati, ha usato Apache.

C’è anche questa guida per Apache: Set up Discourse on a server with existing Apache sites

Tuttavia, sembra esserci un gran numero di problemi nel farlo funzionare correttamente, in particolare con SSL.

Sarebbe più semplice eseguire due droplet, uno per il sito web e uno specificamente per Discourse? Immagino che potrei semplicemente modificare il record DNS del sottodominio per puntare al droplet di Discourse e ciò dovrebbe risolvere il problema. Trovo solo strano dover eseguire due server per un forum.

4

Ciao @OrbitStorm

Benvenuto!

Discourse non è per nulla intrusivo.

Imparare a gestire Discourse in Docker dietro un server web proxy inverso è un’esperienza molto gratificante, sia che tu usi Apache2 o nginx.

Se stai già eseguendo applicazioni dietro Apache, è facile configurare una o anche 100 istanze di Discourse in Docker dietro Apache!

5

Apprezzo la risposta.

Lo dico con il massimo rispetto, ma Discourse, “out of the box”, richiede praticamente un server dedicato. Utilizzare un reverse proxy per eseguire un server web in parallelo a Discourse sullo stesso VPS è un’operazione incerta, come dimostrano i commenti e le altre lamentele, e il SSL potrebbe funzionare o meno. Inoltre, è virtualmente impossibile far funzionare due istanze di Discourse sullo stesso server. Tutto ciò, a mio avviso, è un ostacolo. Non esiste altro software per forum, nemmeno piattaforme di alto livello come XenForo o Invision, che richieda un livello di impegno simile con tanta incertezza. Sono pacchetti costosi, quindi immagino che con Discourse si ottenga ciò che non si paga. Come nuovo utente di fronte a tutti questi ostacoli, sembra che Discourse sia stato progettato senza tenere in considerazione nulla d’altro (cioè i siti web).

Per completezza, come ho già notato nel mio post originale, ho utilizzato una distribuzione con un clic per Discourse. Quindi, dovrò fare tutto al contrario per provare a installare Apache (o Nginx, se non riesco a trovare una guida) sullo stesso server. Se devo usare Discourse come piattaforma principale per il forum, non sono interessato a gestire due server per una sola community. Sarebbe assurdo.

6

Onestamente penso che sia fattibile: non sono un esperto e “seguo” semplicemente ottimi guide e tutorial qui e là. Ho avuto pochi o nessun problema nel configurare Discourse dietro nginx, quindi forse ho avuto un po’ di fortuna, ma credo che sia tutt’altro che impossibile :slightly_smiling_face:
Mi piacciono queste:
https://linuxize.com/post/how-to-install-nginx-on-ubuntu-18-04/
https://linuxize.com/post/secure-nginx-with-let-s-encrypt-on-ubuntu-18-04/
Penso che potrebbe non essere una strada semplice aggiungere alla combinazione multisito/multicontainer e un clone S3 :sweat_smile:

E per la combinazione postfix/dovecot:
https://linuxize.com/post/install-and-configure-postfix-and-dovecot/

7

@Benjamin_D Il problema che riscontro è che tutti i tutorial disponibili qui trascurano qualche aspetto del mio ambiente attuale. C’è un tutorial per Apache ma basato su CentOS. Io uso Ubuntu. L’altro tutorial di Kane York utilizza Nginx, ma come ho già detto, io uso Apache.

Non sto facendo nulla di eccessivamente complesso. Sto semplicemente utilizzando DigitalOcean, Linux con Ubuntu 18.04, ospitando tutto sul droplet (senza ricorrere a storage di terze parti), ecc. Sto usando Mailgun come soluzione di posta, ma non credo offra una casella di posta, il che va bene per il momento.

Sto solo cercando di rendere tutto il più semplice possibile.

8

@OrbitStorm

In realtà, Discourse è al momento il miglior software open source per forum e creazione di comunità sul pianeta (a mio avviso), per molte ragioni; ecco solo alcune di esse:

  1. Discourse è open source, ha una comunità solida e un team di sviluppo centrale molto intelligente (e capace).

  2. Discourse è progettato per essere eseguito in un contenitore Docker in produzione, il che offre numerosi vantaggi:

  • Discourse può essere distribuito facilmente in modalità standalone senza bisogno di un server web o di un database esterni.

  • Discourse può essere distribuito facilmente in modalità multi-container, garantendo maggiore affidabilità e aggiornamenti senza interruzioni.

  • Discourse può anche essere distribuito in configurazioni ad alta disponibilità utilizzando Docker Swarm e Kubernetes, consentendo a Discourse di scalare verso l’alto e verso il basso “on demand”.

  • Discourse è facile da eseguire il backup e da ripristinare. Possiamo utilizzare il backup standard di Discourse OOTB e ripristinarlo ovunque nel mondo in un nuovo e vergine contenitore Docker.

  1. Discourse funziona facilmente dietro server proxy inversi web Apache2 e nginx. Anche questo presenta molti vantaggi, ecco alcuni esempi:

  • Discourse può essere eseguito su un server web esistente, sia esso nginx o Apache2, con poco sforzo sia per le porte TCP/IP esposte da Docker che per i socket di dominio UNIX.

  • L’esecuzione di applicazioni basate sul web dietro proxy inversi è una pratica consolidata. Questa configurazione non è specifica di Discourse, ma Discourse fornirà supporto.

  • Configurare SSL è molto semplice dietro un proxy inverso e può essere tanto semplice quanto certbot -d my.great-discourse.site utilizzando LETSENCRYPT, supportato e gratuito.

  1. Discourse è completamente documentato, commit per commit, su GitHub, così chiunque può seguire le modifiche al codice.

  2. Discourse ha un modello di business progressivo, che offre alcuni vantaggi chiave, tra cui:

  • Discourse, il software principale e molti ottimi plugin, temi e componenti, sono gratuiti.

  • Discourse offre supporto gratuito, incluso il supporto per la configurazione standard, su meta.

  • Discourse offre hosting commerciale a chi non desidera ospitare autonomamente o preferisce un approccio più “hands off”.

  • Discourse incoraggia il consulente commerciale e lo sviluppo di plugin nella propria comunità, creando un ecosistema commerciale vitale.

  1. C’è altro, ma voglio concludere!

Noi (io) concordiamo con ogni decisione presa dal team centrale di Discourse e loro concordano con tutte le nostre (o le mie) idee e suggerimenti?

No, ovviamente no; e non dovrebbero farlo, né noi, né io. Siamo liberi di suggerire, inviare suggerimenti di codice, PR, e il team centrale di Discorse accoglierà questi suggerimenti con mente aperta.

Ma alla fine della giornata, il team centrale deve mantenere la comunità di Discourse in una direzione coerente, il che non è facile quando centinaia di persone provenienti da culture diverse desiderano configurazioni diverse e hanno priorità, modelli di business e idee differenti.

In altre parole, non c’è nulla da “evitare” (le parole del titolo del tuo argomento) in Discourse, specialmente per quanto riguarda la configurazione di proxy inversi e la padronanza di Docker. Molti (io incluso) si stanno spostando verso Kubernetes grazie a Discourse, non solo per Discourse ma anche per altre applicazioni web.

Discourse è la “cosa più lontana” dall’essere “ostacolante” (ancora una volta, le tue parole, non le mie); e poiché è basato su contenitori, per progettazione, il “cielo è il limite” per quanto riguarda come gli amministratori di sistema esperti possono distribuire Discourse in ambienti di produzione altamente scalabili; ed è anche abbastanza semplice che i principianti possano facilmente distribuirlo in modalità standalone.

Devo aggiungere altro?

Come recita la canzone dei REM (Losing My Religion):

Oh no, ho detto troppo, l’ho preparato

Concludo questo argomento… Buona fortuna @OrbitStorm

9

Se ho capito correttamente, ciò che desideri è nginx in ascolto che reindirizza un sottodominio ad Apache da un lato e un altro sottodominio al container dove è installato Discourse dall’altro lato (configurato esponendo la porta corretta nell’app.yml o utilizzando il template web.socketed), oppure stai usando Apache come proxy?

Nel tutorial per CentOS viene utilizzato nginx invece di HAProxy, credo :thinking:

10

Quasi, ma non proprio. Per ribadire, sto usando Linux con Ubuntu 18.04. Utilizzo Apache per servire un sito HTML standard (in futuro WordPress) e ho installato Discourse su un sottodominio. Devo solo capire come configurare un reverse proxy (come indicato in questi tutorial) che reindirizzi il traffico dalle porte 80 e 443 a nuove porte, dato che Apache utilizza già entrambe. Non sono interessato a usare Nginx perché non ho esperienza con esso e non voglio integrarlo con Apache, rendendo la mia configurazione ancora più complessa.

Non sono uno sviluppatore avanzato. Sono solo una persona con una conoscenza fluente del frontend, una comprensione di base dei pannelli, una conoscenza limitata di SSH e praticamente nessuna conoscenza di tutto il resto (ecco perché sto usando i tutorial).

Il mio obiettivo finale è avere due domini con una rispettiva pagina iniziale e con più istanze di Discourse (una per ogni sito). Roba semplice.

11

Non sono sicuro che sia più complesso usare Apache come server e proxy rispetto a bundlare nginx o HAproxy :sweat_smile:
Per quanto riguarda la guida, CentOS o Ubuntu non dovrebbero fare molta differenza, apt invece di yum,
https://support.cloudflare.com/hc/en-us/articles/360029696071-Restoring-original-visitor-IPs-Option-2-Installing-mod-remoteip-with-Apache invece di

Posso suggerire questo per Apache come reverse proxy:

12

Se vuoi che la tua vita sia semplice, esegui Discourse su un droplet dedicato. Non puoi davvero far funzionare Discourse e Apache su un droplet da 1 GB, quindi due droplet da 1 GB non costano nemmeno di più.

13

@pfaffman La mia intenzione non è mai stata quella di rimanere sul droplet più piccolo; lo sto usando solo mentre provo a configurare tutto. Non ha senso pagare una tariffa oraria più alta durante la sperimentazione.

L’unico motivo per cui non sono molto entusiasta di eseguire due droplet è che probabilmente avrò 3-4 domini diversi da migrare su DigitalOcean. Non voglio dover pagare per 6-8 droplet. Sarebbe una follia.

14

Se vuoi più di 3 siti Discourse, probabilmente dovresti valutare la configurazione multisito. Io uso una configurazione con Traefik, anche se sto valutando altri proxy inversi.

15

Se stai utilizzando Apache e desideri avere più siti distinti, il termine di ricerca rilevante è VirtualHost.

16

Con un droplet di piccole dimensioni, potresti voler ridurre i buffer. Il mio droplet ha 4 GB di memoria e 4 core condivisi.

17

Sono riuscito a trovare una soluzione grazie a Bobbyiliev di DigitalOcean.

Puoi trovare la soluzione qui: Discourse not loading with Apache and proxy redirect - #8 by OrbitStorm