Dopo una settimana dedicata a trovare una soluzione per installare Discourse insieme ad Apache, mi trovo costretto a chiedere consiglio sui prossimi passi, poiché sembra che attivare un certificato SSL per Discourse dietro Apache sia praticamente impossibile, data la progettazione di Discourse fortemente orientata a Nginx.
Struttura attuale del mio ambiente di hosting:
Droplet Digital Ocean da 10 $
Ubuntu 18.04
Apache con SSL Let’s Encrypt per la homepage HTML
PHP, MySQL e phpMyAdmin
Webmin (senza SSL)
Discourse
Vorrei mantenere la flessibilità di installare WordPress, quindi non sono convinto che Nginx sia la strada da seguire, dato che ho letto come Apache offra una migliore compatibilità con WordPress.
Il mio obiettivo: attivare un certificato SSL per l’intero dominio, incluso Discourse, senza dover spostare Discourse su un droplet separato. Se ciò richiede un uso limitato di Nginx, non c’è problema. Ho solo bisogno di sapere quali tutorial consultare per mettere ordine in questo caos.
Sto cercando qualcosa di simile, ma voi siete più avanti nel processo. Ho alcune domande sulla vostra configurazione di cui non sono sicuro, se non vi dispiace rispondere.
Avete un reverse proxy?
Il reverse proxy gestisce l’SSL?
Gli altri server non gestiscono l’SSL e si affidano al reverse proxy per farlo, oppure state applicando il principio della difesa a più livelli con ogni server che gestisce il proprio SSL?
La comunicazione tra reverse proxy e server avviene esclusivamente tramite socket e non tramite porte?
FWIW, ho effettuato test estesi sia con Apache2 che con nginx come reverse proxy davanti a Discourse in produzione (utilizzando socket Unix) e nginx non è “molto più veloce”.
In questa configurazione, nginx è “leggermente più veloce” e la differenza di velocità non è percepibile dall’utente.
Inoltre, i test Google PageSpeed negli strumenti per i webmaster (Lighthouse), mediati nel tempo, non mostrano differenze significative tra i due reverse proxy.
Questo commento FWIW non si basa su teorie o sulla ripetizione di quanto scritto da altri; è basato su test reali in produzione.
Eseguiamo tutte le nostre istanze di Discourse dietro reverse proxy Apache2 (inizialmente erano reverse proxy nginx) perché preferiamo gestire molti siti web (host virtuali) sui nostri server dove sono già ospitate applicazioni LAMP.
Chiunque desideri utilizzare Apache2 come reverse proxy invece di nginx starà perfettamente bene! Questo fatto rende Discourse facilmente accessibile a una vasta base di utenti/host (Apache2 e nginx).
@fzngagan Non sto ricominciando da capo e quella guida è per CentOS, quando ho chiaramente specificato nel mio post che sto usando Ubuntu.
@EricGT Dai un’occhiata alla soluzione che ho condiviso nella mia stessa discussione, perché trovare supporto se usi qualcosa di diverso da Nginx o CentOS è praticamente impossibile — come dimostra questa discussione in cui non ho ricevuto risposte alla mia domanda, ma solo una discussione fuori tema su Apache contro Nginx.
Potrebbe benissimo essere così, ma Apache è supportato più diffusamente. Discourse è l’unico software di forum che essenzialmente impone Nginx ai suoi utenti. È per questo che preferisco rimanere con Apache perché è più comune, più facile per i nuovi utenti e il supporto sarà molto più facile da trovare. “Ottimizzare” non è qualcosa che mi interessa.
Eppure la comunità Discourse lo scoraggia attivamente e si rifiuta di fornire supporto a chi vuole farlo, con l’eccezione di collegare a guide non supportate. Ho creato più discussioni e fatto ancora più domande, ma sei l’unico che si è avvicinato a fornire supporto (in un’altra discussione) condividendo la tua configurazione e, come principiante, mi è stato chiesto di decifrarla e applicarla al mio caso. Tutto il resto è stato “dai un’occhiata a questa guida obsoleta” o chiacchiere fuori tema.
Bene, come dichiariamo chiaramente più volte, a causa di limiti di tempo e di salute mentale, c’è un limite a ciò che possiamo supportare gratuitamente qui. Per questo motivo offriamo un’installazione standardizzata che funziona bene per il 95% delle persone che la provano, e forniamo pieno supporto per essa.
Se desideri esplorare opzioni di supporto a pagamento per installazioni personalizzate, ti consigliamo di consultare Marketplace.
Questo forum è in gran parte peer-to-peer, quindi la tua affermazione non ha assolutamente alcun senso. Inoltre, non ho mai posto domande complesse, ma solo chiesto chiarimenti o aggiornamenti per tutorial esistenti che vengono continuamente collegati nonostante siano obsoleti o errati. Ho dovuto ottenere assistenza da DigitalOcean, un provider di hosting, per configurare correttamente un reverse proxy. È sbalorditivo, anche per un software open-source.
La tua risposta mi dà l’impressione che il “supporto” qui sia solo una farsa volta a vendere servizi a pagamento.
Innanzitutto, utilizziamo Discourse in produzione dietro un reverse proxy Apache2 (in più di un’istanza) e non abbiamo avuto alcun problema nella configurazione; a parte il normale “cercare su Google quando serve aiuto”, cosa che tutti fanno senza esitazione.
In secondo luogo, non ho mai chiesto al team di Discourse o a chiunque su meta di supportare Apache2 come reverse proxy, poiché questa configurazione non è ufficialmente supportata. Discourse non supporta “ufficialmente” (per quanto ne sappia) configurazioni multi-container, reverse proxy (Apache2), Kubernetes, Docker Swarm e un numero quasi infinito di altre configurazioni. È comprensibile e corretto che il team di Discourse, che offre questo ottimo software gratuitamente e rende open source tutto il codice, ogni commit su Github, limiti le proprie “configurazioni ufficialmente supportate”. Credo che Jeff abbia riassunto la questione in modo eccellente e molto corretto:
Beh, come dichiariamo chiaramente più volte, c’è un limite a ciò che possiamo supportare gratuitamente qui a causa di vincoli di tempo e di sanità mentale. - Jeff A.
In terzo luogo, Discourse fornisce numerosi tutorial per configurazioni “non supportate”, come l’uso di Apache2 come reverse proxy; tuttavia, configurare un reverse proxy non è di per sé un “compito di Discourse”. Configurare un reverse proxy è un “compito generico di sysadmin” che è sostanzialmente lo stesso per qualsiasi applicazione backend, incluso Discourse.
Eseguiamo Apache come reverse proxy davanti a diverse applicazioni web, tra cui Discourse, Docker Registry e altri container e applicazioni Docker. L’uso di Apache2 (o nginx) come reverse proxy non è specifico di Discourse. È un compito generico di sysadmin.
In quarto luogo, c’è un’abbondanza di informazioni online su come configurare Apache2 come reverse proxy per un’applicazione. È totalmente inutile e non utile alla tua causa bullizzare il team di Discourse su questa questione. Bullizzare le persone e usare termini come “farsa” è sia inaccurato che non utile alla tua causa (o a chiunque altro qui).
Quindi, per riassumere per te @OrbitStorm (questo è il mio ultimo post sul tuo argomento, quindi leggi attentamente) ciò che è stato detto prima, incluse le parole gentili e pazienti di J. A., hai molte scelte.
Puoi facilmente andare online e imparare a configurare Apache2 come reverse proxy (questo è ciò che abbiamo fatto noi), ed è divertente e gratuito per te imparare a svolgere questo compito generico di sysadmin.
Puoi assumere qualcuno per farlo se non vuoi imparare, o non riesci a “capirlo” da solo o non hai il tempo.
Puoi pubblicare qui e lamentarti e urlare, definendo meta e questo forum una “farsa” e lanciando insulti a tutti per cercare di costringerli a supportarti personalmente in una configurazione non supportata.
Consiglio vivamente, in qualità di utente Discourse e sysadmin con decenni di esperienza, di non scegliere l’opzione #3 (il bullismo e l’intimidazione non funzioneranno con il team di meta, te lo assicuro); e di considerare l’opzione #1 se non vuoi spendere soldi per aiuto.
Configurare Apache2 come reverse proxy per Discourse è davvero molto semplice. Ci sono alcuni post su Discourse meta a riguardo (alcuni recenti, altri datati) e ci sono innumerevoli tutorial online su come configurare Apache2 come reverse proxy per un’applicazione web. La tecnica è la stessa. Consiglio di esporre una socket Unix quando si esegue in modalità reverse proxy.
Onestamente, è divertente configurare Apache2 come reverse proxy di host virtuale per Discourse. Perché renderlo stressante e lanciare insulti ai ragazzi che hanno creato questo ottimo software e lo offrono gratuitamente? Discourse è un regalo gratuito! Se vuoi configurare Discourse diversamente dalle configurazioni ufficialmente supportate, nessuno ti impedirà di farlo!
Concludendo @OrbitStorm, ti consiglio vivamente (parlando come utente Discourse, non come membro del team) di cambiare il tuo approccio di bullismo su meta per ottenere supporto. Come ho detto, eseguo Discourse in configurazioni “non ufficialmente supportate” e ho pubblicato aggiornamenti e codice qui per aiutare gli altri (restituire qualcosa a questa grande comunità). Ho già pubblicato codice funzionante, facile da seguire, per configurare Apache2 come reverse proxy, come hanno fatto altri prima di me.
Ti chiedo gentilmente di scegliere l’opzione #1 (fallo da solo) o #2 (assumi qualcuno per farlo); e per favore abbandona il tuo attuale approccio #3 (intimidire, bullizzare e insultare il team di meta). Se vuoi scegliere l’opzione #3, vai a pubblicare sui nostri forum Unix e Linux e puoi bullizzarmi lì se vuoi, quanto vuoi
Hai scritto questo muro di testo senza mai affrontare davvero l’argomento originale, in un vano tentativo di fare da cavaliere bianco per qualcosa che non è nemmeno sotto attacco. Mi hai etichettato come “bullo” (lol?) perché ho risposto a sciocchezze fuori tema da parte di un tizio che mi ha aggredito con insulti personali sull’intelligenza e ha trasformato questo thread nella sua cattedra per Nginx (commenti convenientemente cancellati per seppellire le prove della natura tossica che questo forum genera verso i nuovi utenti). Il tuo primo post non era molto diverso: rispondeva alla mia domanda senza effettivamente rispondere. Fai parte del problema.
Continui a parlare di obblighi, eppure eccoti qui, rispondendo persistentemente ai miei thread solo per essere polemico (come aveva fatto Stephen). Non sapevo che esistesse una regola che mi impedisse di chiedere supporto per una configurazione di hosting popolare (W3Techs è stato citato prima e mostra una quota del 67% per Apache). Avresti potuto semplicemente lasciare i miei thread senza risposta se non approvavi, ma hai scelto di essere belligerante e di deviare la conversazione.
Stai intenzionalmente travisando le mie parole perché non mi conformo allo status quo di accettare un tutorial obsoleto e poi non fare più ritorno — un fattore per cui virtualmente tutti i thread riguardanti questa configurazione rimangono irrisolti (cioè bullismo da parte di tizi come te). Pensi davvero che non abbia fatto le mie verifiche prima di pubblicare? Accettavo quello che sapevo sarebbe successo, ma speravo che altri che si trovavano nella mia posizione (come EricGT) potessero offrire qualcosa di valore prima che tutto venisse schiacciato fino all’oblio con risposte pompose.
Faccio game development da 16 anni e non ho mai sperimentato un livello così folle di scarsa professionalità e meschinità come qui in soli cinque giorni. È una cosa da Reddit, una vera e propria barzelletta.
Non riesco a capire perché la configurazione SSL debba avere a che fare con le applicazioni dietro il proxy , purché il template SSL sia disabilitato nell’app.yml? nginx, apache, haproxy o traefik: tutti condividono lo stesso concetto di snippet/serverblock/virtualhost, dove essenzialmente si attiva l’SSL, si specifica la posizione dei certificati sull’host e si impostano alcuni parametri SSL. Qui potrebbero esserci dei pericoli, forse?
Penso che la soluzione che stai cercando non sia legata a Discourse ma ad Apache, e credo che qualsiasi configurazione SSL pronta all’uso di Apache con virtual host funzioni bene con Discourse, come ha funzionato con altri reverse proxy, ma potrei essere un po’ ottimista .
Tuttavia, ricordo di aver avuto un problema con le cifre crittografiche; assicurati di copiare/incollare con attenzione (la riga è molto lunga) quelle utilizzate all’interno del contenitore Docker.
Per quanto riguarda questa scivolata, penso sia come sciare fuori pista: è divertente, ma è molto malvista dai soccorsi montani. Ammetto che la situazione cambia quando si cade in un burrone mentre si sta ancora imparando, sia che si sia sciatori esperti o meno.
Per favore, professionista o meno, sii gentile con il
, purché il template SSL sia disabilitato nell’app.yml? nginx, apache, haproxy o traefik: tutti condividono lo stesso concetto di snippet/serverblock/virtualhost, dove essenzialmente si attiva l’SSL, si specifica la posizione dei certificati sull’host e si impostano alcuni parametri SSL. Qui potrebbero esserci dei pericoli, forse?
.