Salut !
Mon site web utilise la version 2.9 de Discourse. Pour une raison quelconque, j’ai dû utiliser un double Nginx pour Discourse. J’ai déployé deux nœuds conteneurisés web_only pour Discourse et j’ai utilisé un Nginx pour faire du proxy devant eux. Mon diagramme d’architecture système :
J’étais confus lorsque mon proxy Nginx personnalisé redirigeait deux nœuds conteneurisés web_only et distribuait aléatoirement les requêtes à n’importe quel nœud web_only, mon site web Discourse signalait parfois des erreurs : “Could not find module ‘handlebars’ imported from ‘discourse-common/lib/raw-handlebars’”, cette fois-ci, le navigateur affichait un écran vierge en visitant le site. Mais lorsque j’utilisais mon proxy Nginx personnalisé pour transférer toutes les requêtes vers un seul des nœuds web_only, cette erreur ne se produisait pas. J’ai recherché ce problème, il y avait eu des commits auparavant pour résoudre cette même erreur, j’ai confirmé que ma version contenait le code de ces commits.
Au fait, partagez un problème où l’utilisation de doubles nginx empêche d’obtenir la véritable adresse IP de l’utilisateur.
Ceci est dû au fait que mon nginx personnalisé active le champ d’en-tête X-Forwarded-For pour obtenir l’adresse IP du client, mais ne désactive pas le X-Forwarded-For du nginx de Discourse. Cela provoque l’écrasement de la configuration X-Forwarded-For du nginx personnalisé par le nginx de Discourse.
Et peu importe lequel vous utilisez ? Et ils exécutent la même image ? C’est déroutant.
Le seul avantage que je vois à exécuter deux conteneurs comme ça sur le même hôte est de permettre des mises à niveau sans temps d’arrêt. Puisque vous n’effectuez pas de mises à niveau très souvent, il semble que vous ayez une complexité inutile.
Vous avez besoin de quelque chose comme ceci dans votre web_only.yml :
Oui, peu importe lequel j’utilise. Ils exécutent la même image web_only. Je continuerai à chercher des problèmes en utilisant le mode sans échec et si j’ai des conclusions, je ferai un rapport ici.
Désolé pour le malentendu dans mon diagramme d’architecture système, j’ai utilisé une machine différente pour déployer web_only. La raison pour laquelle j’utilise deux web_only est que mon conteneur web_only s’est déjà planté en raison d’un trop grand nombre de connexions, mais je n’ai pas trouvé la raison à ce moment-là. J’ai donc essayé d’utiliser deux web_only pour éviter le même problème à nouveau.
Merci, cela m’a aidé à résoudre le problème de l’obtention de l’adresse IP réelle de l’utilisateur.
Il existe un réglage pour augmenter le nombre de connexions.
Je ferais une mise à niveau. Il doit y avoir un problème avec cette version et je suis à peu près sûr que plusieurs problèmes de sécurité ont été corrigés depuis.
Merci. Actuellement, j’obtiens toujours la même erreur lorsque j’essaie de déboguer en mode sans échec. Je serai prêt à essayer de mettre à niveau mon discourse pour voir si cela fonctionne.
