Se intendi che questa istanza sia disponibile su Internet, l’uso di un dominio .local in app.yml causerà problemi. Forse è qualcosa che intendi usare solo a casa o solo per test, ho pensato che valesse la pena menzionarlo.
Supponendo che il tuo networking Docker funzioni correttamente, rendendo il container raggiungibile a quell’indirizzo IP dalla macchina host esterna, avresti anche bisogno che il DNS punti discourse.simonz.local a quell’indirizzo IP.
Sembra che quello che sta succedendo è che il dominio si sta risolvendo sulla macchina host e non stai specificando la porta (ad esempio, discourse.simonz.local:1234) quando cerchi di accedervi, quindi sta raggiungendo solo nginx invece del container Docker.
Se vuoi che Discourse sia disponibile su una porta diversa, probabilmente non ne hai bisogno su un indirizzo IP diverso. Se vuoi che sia disponibile sulla porta standard, così come nginx sulla porta standard, hai bisogno del DNS che ti indirizzi all’IP corretto o hai bisogno che nginx faccia da proxy per Discourse.
I domini .local vengono tipicamente annunciati dal sistema in base al suo hostname configurato. Discourse non ha davvero bisogno di fare ciò normalmente, quindi il container potrebbe non avere nulla per farlo.
Se vuoi seguire la strada della porta standard, IP diverso, DNS, questo è al di fuori dell’ambito di Discourse e la sua configurazione dipenderà da vari fattori nella tua rete.
Se il tuo obiettivo è solo avere qualcosa disponibile in nginx oltre a Discourse sullo stesso host, ti consiglio l’approccio proxy collegato sopra. Sebbene tecnicamente sia un’installazione non supportata, è una configurazione più comune e più persone potranno aiutarti.