Salut,
Quelqu’un peut-il me guider ou me fournir des exemples sur la façon de configurer un web socket avec HTTPS pour Discourse ?
HTTP simple fonctionne, mais j’en aurais besoin via HTTPS.
Salut,
Quelqu’un peut-il me guider ou me fournir des exemples sur la façon de configurer un web socket avec HTTPS pour Discourse ?
HTTP simple fonctionne, mais j’en aurais besoin via HTTPS.
Pour information, d’après ce que j’ai lu dans votre autre publication, cela pourrait valoir la peine d’essayer
Pas vraiment, j’exécute d’autres sites Web sans problème sur les ports 80/443 comme je l’ai dit, j’exécute déjà des sites Web avec LiteSpeed, même le serveur de messagerie n’est pas bloqué. J’ai même essayé avec le port 8443, mais rien ne s’est affiché. Via Websocket, j’ai pu au moins l’exécuter sur HTTP, mais il était cassé en raison de contenu mixte sur HTTPS.
Discourse ne prend en charge aucune combinaison de ports autre que 80/443.
Discourse ne le prend peut-être pas en charge, mais Docker le fait, mais je peux toujours le transmettre avec des sockets au Nginx extérieur.
Ceci est au-dessus de 8080.
Mon seul problème est que je n’arrive pas à faire fonctionner HTTPS de quelque manière que ce soit.
C’est pourquoi j’ai dit que Discourse ne prend en charge aucun port autre que 80/443.
Si vous voulez vraiment tenter une combinaison alternative, vous êtes seul responsable.
C’est vraiment stupide si vous me demandez mon avis. Les gens exécutent généralement plusieurs services sur le même serveur, vous empêchez littéralement les utilisateurs de le faire. De plus, les conteneurs Docker ne sont généralement pas seuls sur le même serveur. Vous semblez pousser les autres à acheter des serveurs séparés, simplement parce que vous ne voulez pas prendre en charge d’autres ports que ceux par défaut.
Littéralement des milliers de personnes hébergent d’autres services sur le même serveur que Discourse. Il existe des moyens de le faire. Si vous faites vos recherches, c’est un cas d’utilisation très bien pris en charge. Vous devez le placer derrière un proxy inverse pour y parvenir.
Voici une façon de le faire Run other websites on the same machine as Discourse
J’ai mon bac à sable Discourse public hébergé sur un NUC qui héberge plusieurs autres services derrière Nginx Proxy Manager, mais c’est ma façon de faire. Ce n’est pas officiellement pris en charge, mais je sais comment m’y prendre.
J’ai déjà essayé cela auparavant également, cela ne fonctionne pas correctement. Quoi qu’il en soit, je ne vois pas du tout l’intérêt du support dans ce cas, car comme vous l’avez dit, des milliers de personnes le font. Pourtant, il n’y a pas d’étapes claires pour le faire fonctionner nulle part sur Github ou Wiki. Juste l’option directe 80/443, qui agit comme un service unique.
Vous aurez besoin d’un proxy inverse, comme Comment configurer Discourse sur un serveur avec des sites Apache existants.
Sauf que je n’utilise pas Apache de toute façon, je préférerais avoir besoin de nginx et litespeed, mais néanmoins, il serait plus simple de laisser utiliser d’autres ports, puis nous pouvons facilement les transmettre à d’autres serveurs Web.
Non, je ne comprends rien au docker. Mais quand j’ai eu un discours sur le même VPS où j’avais Nginx et Varnish avant Discourse, j’utilisais sock sans problème. Mais est-ce une chose différente ?
De nos jours, j’ai Discourse sur un VPS différent de celui où se trouvent Nginx/Varnish, donc je ne peux pas utiliser de socket. C’est pourquoi Varnish envoie tout le monde au port 82 et de là au VPS de Discourse. Et c’est pourquoi j’ai :
expose:
- "82:80"
Mais est-ce même une chose totalement différente que Discourse ne puisse utiliser que les ports 80/443 ?
Ensuite, vous pourrez trouver le guide nginx ou utiliser celui-ci comme exemple.
Cela ne se produira pas. Vous aurez besoin d’un proxy inverse qui gère le https.
J’ai trouvé un moyen de le faire fonctionner, ce n’était pas si difficile après tout, et vous pouvez exécuter Discourse sur n’importe quel port de votre choix.
Exact. Vous pouvez avoir le conteneur Docker de Discourse ouvrant le port 82 (ou n’importe quel port) si vous avez Varnish devant, de sorte que l’URL soit une URL https normale. Tant que Varnish gère les certificats https, vous devriez pouvoir procéder comme vous le souhaitez.