Qualcuno ha configurato con successo Discourse in esecuzione su un vhost Apache, invece del predefinito Nginx?
Sembra che la maggior parte delle discussioni su Apache in questi forum riguardi l’esecuzione di Discourse su un host che esegue già Apache. In ogni caso che ho visto, le persone fanno semplicemente il proxy di Apache verso Nginx. Per essere chiari: voglio che il container backend Docker che esegue Discourse gestisca il virtual host in Apache, non in Nginx.
Nello specifico, spero di eseguire il backend di Discourse in Apache invece di Nginx per abilitare mod_security. Configurare Nginx con mod_security richiede la compilazione di Nginx dal sorgente, una complessità che vorrei evitare.
Il mio server di produzione attuale esegue già diversi siti (WordPress, MediaWiki, ecc.). Usiamo Nginx per terminare HTTPS e per applicare un limitazione base del rate di attacco DOS, che poi passa alla cache Varnish e infine al backend Apache con mod_security. Se possibile, vorrei mantenere questa architettura anche per Discourse, con il container Docker backend di Discourse che esegue Apache con mod_security, non Nginx.
Qualcuno ha configurato con successo Discourse per l’esecuzione in Apache?
Scusa, sono nuovo con Docker. Fatico molto a capire come il file ‘/etc/nginx/conf.d/discourse.conf’ venga posizionato all’interno del container Docker. Qualcuno potrebbe chiarire i passaggi su come quel file viene generato e posizionato nel container dallo script ‘./launcher’?
EDIT: aspetta, Nginx viene già compilato dal codice sorgente da Discourse?
No, nessuno ci è riuscito. Discourse è strettamente legato a nginx. Sarebbe difficile, se non impossibile, sostituirlo con Apache. Inoltre, dato che saresti l’unico a farlo, quando qualcosa si rompe nessuno si prenderà la briga di aiutarti.
Usa semplicemente il contenitore Docker che tutti sulla Terra utilizzano e posiziona Apache davanti, se pensi che questo possa migliorare la sicurezza in qualche modo.
Sembra che /etc/nginx/conf.d/discourse.conf venga generato nel container dal file di modello /var/docker/templates/web.template.yml, che lo copia nella posizione corretta da $home/config/nginx.sample.conf, apportando poi delle modifiche tramite i blocchi YAML replace (che vengono ulteriormente aggiornati in modelli successivi, come templates/web.socketed.template.yml).
Davo per scontato che il file nginx.sample.conf venisse semplicemente installato nella posizione corretta da nginx durante la compilazione da sorgente in image/base/install-nginx, ma l’unico file nginx.sample.conf che ho trovato nel container (/var/www/discourse/config/nginx.sample.conf) conteneva già direttive specifiche di Discourse.
Per essere chiaro: pensi che sarebbe più sicuro per me aggiornare lo script ‘image/base/install-nginx’ per compilare nginx nel contenitore Docker di Discourse con il supporto per mod_security, piuttosto che aggiornare il contenitore per eseguire il vhost di Discourse dietro Apache (invece di Nginx)? Se sì, quali sono i rischi di modificare lo script install-nginx? Come potrebbe rompere la mia installazione di Discourse in futuro?
PSA: Tutto ciò che state proponendo di fare, sebbene tecnicamente fattibile, è completamente non supportato. Non possiamo supportare in modo ragionevole ogni possibile combinazione che le persone escogitano per servire Discourse sul web. Pertanto, il supporto in questo forum è limitato alle installazioni che seguono la guida discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub.
Prima o poi, si romperà in molti modi. Dovrete assumervi la responsabilità di fondere continuamente le modifiche a monte e gestire il vostro fork per sempre.
@ledimeo È quello che ha suggerito @pfaffman, e quello che penso sarebbe meglio in questo caso, per non rompere le cose in modo grave in futuro quando verranno rilasciate nuove versioni. Ma sembra che lui stia già utilizzando un altro nginx all’ingresso come reverse proxy e non voglia:
Detto questo, penso che proxygare apache verso nginx (anche se alla fine si arrivasse a quei 4 livelli) sarebbe almeno più mantenibile rispetto a cercare di cambiare il modo in cui Discourse funziona nell’installazione ufficiale.
Quindi, aggiungere Apache come proxy a Discourse dietro nginx è sicuramente un’opzione.
Sono d’accordo sul fatto che un professionista renderebbe gli aggiornamenti futuri più semplici, ed è un punto importante.
Tuttavia, aggiungere un ulteriore passaggio all’architettura non solo renderebbe più complessa la risoluzione dei problemi in futuro, ma ho anche preoccupazioni riguardo alle prestazioni di Apache come proxy per un’applicazione web che utilizza il long polling, come evidenziato da @sam in questo post del 2016.
In generale preferisco nginx ad Apache, tranne quando si tratta di mod_security. Sarebbe fantastico se i repository del sistema operativo includessero pacchetti per abilitare mod_security in nginx, come fanno per Apache, ma attualmente abilitare mod_security su nginx richiede la compilazione di nginx da sorgente sia su RHEL/Cent che su Debian. E evito di dipendere da pacchetti compilati da sorgente in produzione come la peste.
Correlato: Stavo dando un’occhiata allo script install-nginx e ho individuato un piccolo errore di logica: la riga di pulizia che dovrebbe eliminare il codice sorgente di nginx da /tmp/ in realtà non fa nulla.
Non esiste la directory /tmp/nginx/: è /tmp/nginx-$VERSION/ (al momento è /tmp/nginx-1.17.4/) e c’è anche il file tarball /tmp/nginx-1.17.4.tar.gz.
Sfortunatamente, il mio script aggiornato /var/discourse/image/base/install-nginx non sembra essere eseguito quando eseguo /var/discourse/launcher destroy app && /var/discourse/launcher rebuild app.
C’è qualche motivo per cui il comando rebuild non riesegua lo script install-nginx aggiornato?
Se non hai familiarità con Docker, questo sarà un percorso difficile…
discourse_docker contiene il codice sorgente della nostra immagine Docker base, che risiede nel registro Docker pubblico e che non verrà mai eseguita localmente. L’intera ragione è avere un’immagine riutilizzabile.
Ok. Beh, ho mentito riguardo a vim per semplificare le cose. In realtà sto eseguendo questi comandi per aggiornare lo script in modo idempotente e robusto.
cd /var/discourse/image/base
cp install-nginx install-nginx.`date "+%Y%m%d_%H%M%S"`.orig
# aggiungi un blocco per scaricare il modulo nginx ModSecurity subito prima di scaricare il sorgente di nginx
grep 'ModSecurity' install-nginx || sed -i 's%\(curl.*nginx\.org/download.*\)%# mod_security --maltfield\napt-get install -y libmodsecurity-dev modsecurity-crs\ncd /tmp\ngit clone --depth 1 https://github.com/SpiderLabs/ModSecurity-nginx.git\n\n\1%' install-nginx
# aggiorna la riga di configurazione per includere il modulo ModSecurity scaricato sopra
sed -i '/ModSecurity/! s%^[^#]*./configure \(.*nginx.*\)%#./configure \1\n./configure \1 --add-module=/tmp/ModSecurity-nginx%' install-nginx
# aggiungi una riga alla sezione di pulizia
grep 'rm -fr /tmp/ModSecurity-nginx' install-nginx || sed -i 's%\(rm -fr.*/tmp/nginx.*\)%rm -fr /tmp/ModSecurity-nginx\n\1%' install-nginx
Dove dovrei inserire questi comandi in modo che lo script install-nginx effettivo utilizzato dal container durante l’avvio venga modificato?
