Si vous avez l’intention que cette instance soit disponible sur Internet, l’utilisation d’un domaine .local dans app.yml va tout casser. Peut-être que vous n’avez l’intention de l’utiliser qu’à la maison ou uniquement pour des tests, je pensais juste que cela valait la peine d’être mentionné.
En supposant que votre réseau Docker fonctionne correctement, que le conteneur soit accessible sur cette adresse IP depuis l’extérieur de la machine hôte, vous auriez également besoin que le DNS pointe discourse.simonz.local vers cette adresse IP.
Il semble que ce qui se passe, c’est que le domaine se résout sur la machine hôte et que vous ne spécifiez pas le port (par exemple, discourse.simonz.local:1234) lorsque vous essayez d’y accéder, de sorte qu’il atteint simplement nginx au lieu du conteneur Docker.
Si vous voulez que Discourse soit disponible sur un port différent, vous n’en avez probablement pas besoin sur une adresse IP différente. Si vous voulez qu’il soit disponible sur le port standard, ainsi que nginx sur le port standard, vous avez besoin que le DNS vous dirige vers la bonne IP ou vous avez besoin que nginx proxy Discourse.
Les domaines .local sont généralement annoncés par le système en fonction de son nom d’hôte configuré. Discourse n’a vraiment pas besoin de faire cela normalement, donc le conteneur pourrait ne rien avoir pour le faire.
Si vous voulez passer par la voie standard du port, IP différente, DNS, c’est vraiment en dehors du champ d’application de Discourse et sa configuration dépendra de divers facteurs dans votre réseau.
Si votre objectif est simplement d’avoir quelque chose de disponible dans nginx ainsi que Discourse sur le même hôte, je recommanderais l’approche proxy liée ci-dessus. Bien qu’il s’agisse techniquement d’une installation non prise en charge, il s’agit d’une configuration plus courante et plus de personnes pourront vous aider.