Merci, Jay @pfaffman,
Vous êtes vraiment une ressource précieuse de premier plan ici, sans aucun doute !
Qu’en pensez-vous, cette idée peut-être folle (basée sur ma compréhension encore limitée) :
Mettre en place nginx comme proxy inverse en façade ; selon ce tutoriel :
Ensuite, avoir deux répertoires / instances avec discourse_docker (standalone) configurés, par exemple :
- /var/discourse1
- /var/discourse2
Dans ces deux instances, configurez discourse_docker (standalone) pour qu’il écoute sur un socket différent, en modifiant ce modèle dans chaque instance :
- "templates/web.socketed.template.yml"
Ainsi, en résumé, nous avons simplement reconstruit la production (à un moment calme) pour qu’elle s’exécute dans un conteneur différent en écoutant sur un socket différent (nginx.https.sock2), évitant ainsi tout conflit de socket ; ce que nous pouvons également construire en mode standalone (dans le but d’éliminer le besoin de deux conteneurs, data et web-only).
Par exemple (pour discussion / illustration), dans web.socketed.template.yml de discourse1 :
- replace:
filename: "/etc/nginx/conf.d/discourse.conf"
from: /listen 80;/
to: |
listen unix:/shared/nginx.http.sock;
set_real_ip_from unix:;
- replace:
filename: "/etc/nginx/conf.d/discourse.conf"
from: /listen 443 ssl http2;/
to: |
listen unix:/shared/nginx.https.sock ssl http2;
set_real_ip_from unix:;
et dans discourse2 :
- replace:
filename: "/etc/nginx/conf.d/discourse.conf"
from: /listen 80;/
to: |
listen unix:/shared/nginx.http.sock2;
set_real_ip_from unix:;
- replace:
filename: "/etc/nginx/conf.d/discourse.conf"
from: /listen 443 ssl http2;/
to: |
listen unix:/shared/nginx.https.sock2 ssl http2;
set_real_ip_from unix:;
Cependant, au lieu de laisser le modèle Discourse faire la magie, nous basculons simplement manuellement les sockets dans /etc/nginx/conf.d/discourse.conf et redémarrons nginx. Nous supprimerions donc la directive replace: dans le modèle web.socketed.template.yml.
Dans cette configuration proposée (peut-être folle), nous pouvons avoir deux conteneurs standalone écoutant sur deux sockets différents (sans conflit) et simplement configurer nginx pour se connecter au socket souhaité, puis redémarrer nginx.
Cela semble clair, simple et peut-être utile (pendant une période calme sans nouveaux messages sur l’instance en direct) pour ceux qui ne veulent pas (ou n’ont pas besoin) de la complexité de deux conteneurs (data et web-only) par instance Discourse unique (app).
Bien sûr, la configuration la plus robuste (d’un point de vue des données), cependant, pour la perfection sur les sites occupés, serait la solution à « deux conteneurs », car nous voudrions avoir les instances data et web-only (écoutant maintenant sur deux sockets différents, sock et sock2).
Dans la « solution à deux conteneurs » avec la façade nginx, la « configuration standard » consiste à faire écouter les deux conteneurs web-only sur le même socket, de sorte qu’ils ne peuvent pas fonctionner simultanément ; mais si (par exemple uniquement) nous les faisions écouter sur un socket différent, ils pourraient tous deux fonctionner en même temps et nous pourrions simplement utiliser le fichier de configuration nginx (et un redémarrage de nginx) pour basculer entre les deux.
Est-ce la bonne compréhension ?
Commençais-je à (lentement mais j’espère sûrement) à comprendre cela ?
Merci !
Note de suivi uniquement : J’ai la configuration « deux conteneurs » fonctionnelle sur l’un de mes Mac de bureau :
Les seules précautions dans notre installation étaient la nécessité de créer manuellement ces répertoires (et de définir la propriété et les permissions), car ces répertoires ne sont pas créés pour une raison quelconque par les scripts :
~discourse/discourse/shared/data
~discourse/discourse/shared/web-only
et bien sûr, au début, j’ai essayé avec un mot de passe vide pour la base de données, et cela n’a pas fonctionné (les instructions disent bien de définir un mot de passe, mais je faisais juste des expériences).
Ensuite, je vais configurer la façade nginx et essayer de passer à cette configuration avec websocket pour l’application web-only.