Il contenitore nell’host non esegue mai install-nginx come affermato sopra.
Non sono sicuro che questo argomento sia particolarmente utile.
Ti dispiace l’architettura di Discourse, non accetti le parole degli sviluppatori sui modi in cui il prodotto è ottimizzato, non sembri familiare con Docker e, per tua stessa ammissione, menti nelle tue domande, il che sta sprecando il nostro tempo collettivo.
Questo argomento ha già il tag unsupported-install perché ti stai allontanando notevolmente dall’ambito del supporto gratuito fornito alla comunità. Se queste cose ti interessano davvero, perché non iniziare un argomento su Marketplace? In questo modo potrai investire i tuoi soldi pagando un consulente per formarti, invece di sprecare il nostro tempo.
Non l’ho mai fatto, scusa. Quindi devo inserire i comandi sed sopra nella sezione degli hook di app.yml? Esiste da qualche parte un esempio su come farlo per modificare un file nel repository docker_discourse durante l’avvio (bootstrap)? Attualmente quella sezione contiene solo un comando git clone per i plugin.
Potrei probabilmente inserire quei comandi sed in una sezione cmd come quello git clone, ma non so in quale directory si troverà lo script install-nginx.
Inoltre, dove si trova app.yml? Non sono riuscito a collegare alla sezione hooks sopra perché la directory containers è vuota nel repository 
Tutta la documentazione per fare queste cose esiste qui su meta. A tutti noi piace saltare la lettura del manuale, ma in questo caso dovresti davvero tornare alle basi.
Francamente, stai affrontando tutto questo al contrario.
Voglio richiamare l’attenzione sul tag #unsupported-install: l’aspettativa è che se decidi di discostarti dall’installazione standard, tu assuma personalmente l’onere tecnico aggiuntivo.
Come hai installato l’istanza?
Mi dispiace, ma faccio uno sforzo per cercare la documentazione prima di pubblicare. Mi farebbe piacere avere un manuale di Discourse e ho già letto molti argomenti contrassegnati con howto. Purtroppo, non sembra esserci un manuale di Discourse..
Apprezzo molto il tuo aiuto in merito e sono sicuro che sarà utile anche ad altri in futuro che cercheranno documentazione su come fare queste cose…
Prima discourse-setup, che alla fine mi ha dato un’installazione rotta. Poi ho modificato manualmente app.yml seguito da ./launcher rebuild app
Penso che questa sia una discussione interessante, proprio per conoscere meglio Discourse.
Opterei per nginx, magari modificando abbastanza il file app.yml per aggiungere il modulo mod_security durante il processo di compilazione e creando io stesso un’immagine base.
Ora, Discourse è un software complesso che gira su Rails, il quale è ancora più complesso da distribuire in modo semplice e coerente; ecco perché lo staff si è impegnato al massimo nell’immagine Docker che ha creato.
L’immagine comporta molta magia nera, con un’enorme quantità di ottimizzazioni per funzionare nel modo migliore possibile nell’installazione supportata.
Tenendo conto di ciò e riuscendo a capire tutti i pezzi del puzzle (come i 2-3 repository necessari per far funzionare Discourse), non è impossibile ottenere ciò che desideri.
Ora, sapendo che la tua configurazione è nginx -> varnish -> apache, perché non provare nginx -> varnish -> Discourse, aggiungendo mod_security all’immagine base e configurandolo tramite hook?
La probabilità che mod_security aumenti la tua sicurezza è molto, molto bassa. Chi mantiene Discourse è estremamente attento alla sicurezza, quindi le problematiche che mod_security dovrebbe risolvere sono probabilmente già gestite. Inoltre, la probabilità che, se aggiungi mod_security alla tua immagine, Discourse diventi inutilizzabile, è significativamente maggiore di zero. Se installi mod_security e scopri che Discourse non funziona, dovrai occupartene da solo per modificare Discourse in modo che sia compatibile con mod_security, cercando di convincere i maintainer di Discourse che hai individuato una legittima preoccupazione di sicurezza, oppure sarai costretto a mantenere un tuo fork in futuro.
Non può derivarne nulla di buono. È altamente improbabile che da ciò possa derivare qualcosa di positivo.
Concordo, un altro WAF sfiora la sicurezza per oscurità.
Stanno venendo compiuti sforzi proattivi reali per mantenere sicuro Discourse:
Questo argomento si è discostato dalla domanda originale sull’esecuzione di Discourse su Apache (anziché su un proxy di ritorno a Nginx).
Tuttavia, ritengo che una discussione sull’installazione di un WAF (mod_security o altro) davanti a Discourse sia utile per la comunità, quindi ho creato un argomento specifico per discutere esclusivamente di Discourse + WAF qui: