Sì e no. Facciamo un passo indietro e analizziamo la situazione.
Prima, sembra che tu stessi eseguendo diversi siti web con Apache. Apache ascoltava sulle porte 80 e 443 e poi “proxyava” (reindirizzava) le richieste come “host virtuali”, permettendoti di eseguire molti siti web sullo stesso server, tutti in ascolto sulle stesse porte (80 e 443). Questo era il “LAMP 101”… il modo degli host virtuali.
Ora, supponiamo che tu installi Discourse nel modo ufficiale OOTB (Out Of The Box). Discourse OOTB cercherà di associarsi alle stesse porte e fallirà perché Apache le sta già utilizzando (è già associato a quelle porte). Hai delle opzioni:
- Esegui Discourse su una socket di dominio Unix e configura Apache per fare il reverse proxy dell’applicazione Discourse come host virtuale.
Nota: L’ho testato e funziona; ma questa soluzione non è supportata ufficialmente (né tantomeno in modo non ufficiale) da Discourse.
- Passa da Apache a nginx ed esegui tutti i tuoi server web su nginx, facendo anche il reverse proxy dell’applicazione Discourse come host virtuale, utilizzando una socket di dominio Unix per l’applicazione di produzione di Discourse-Docker.
Nota: Anche questa non è supportata ufficialmente da Discourse; e la maggior parte delle persone che gestiscono siti Apache troverà un po’ “complicato” convertire tutti i propri moduli mod_rewrite e codificati geo-ip di Apache2 in nginx; ma è certamente fattibile, specialmente se le tue applicazioni sono progettate per funzionare sia con nginx che con Apache2 (questo rende le cose più semplici, ma comunque non è supportato ufficialmente).
- Esponi il contenitore Docker di Discourse su porte diverse da 80 e 443.
Nota: Anche questa non è (davvero) raccomandata (anche se, a quanto ricordo, è supportata ufficialmente). Tuttavia, la maggior parte delle persone non vuole accedere a un’applicazione web digitando numeri di porta come https://la-mia-grande-app-discourse.org:3334, quindi nella produzione reale quasi nessuno lo fa. Lo sviluppo è un’altra storia.
La mia raccomandazione “senza conoscere tutti i tuoi dettagli”, da qualcuno che ha molta esperienza con LAMP e sempre più con Discourse, è di eseguirli su server separati (questa soluzione è supportata ufficialmente da Discourse); ma se sei davvero a corto di denaro e devi eseguirli tutti sullo stesso server (o semplicemente ti piace avere un unico grande server complicato), allora dovrai imparare a configurare Apache2 per fare il reverse proxy verso una socket di dominio Unix da/per l’applicazione Discourse.
L’ho testato ed è possibile configurare Apache2 per fare il reverse proxy verso Discourse utilizzando una socket di dominio Unix; ma questa soluzione non è supportata ufficialmente (per nulla).
Nota: Il link per configurare Apache2 con HAProxy era una soluzione che non sono riuscito a far funzionare facilmente; quindi l’ho abbandonata (non c’è bisogno di usare solo HAProxy, esistono “vecchi modi” per farlo). Tuttavia, potresti trovare più conveniente seguire semplicemente questo tutorial di Discourse:
Spero che questo possa esserti utile in qualche piccola misura, @nekodroid