Discourse + serveur web. Possible ou mieux éviter ?

Avertissement rapide : je suis relativement nouveau dans la création d’un environnement VPS à partir de zéro, mais j’ai suffisamment d’expérience en hébergement web (notamment en mutualisé et dédié géré) pour avoir une idée de ce que je fais et pour comprendre les tutoriels.

Cela dit, j’utilise actuellement le droplet le moins cher de DigitalOcean à titre expérimental. Je suis un passionné, je ne m’attends pas à avoir beaucoup de trafic, et je cherche simplement à créer deux instances : l’une pour une page d’accueil d’un certain type (probablement WordPress) et l’autre pour un forum Discourse associé — une instance pour la conception de jeux et l’autre pour ma communauté de créateurs de contenu.

Je suis conscient que Discourse et Apache ne fonctionnent pas bien ensemble en raison de la décision de Discourse d’utiliser le port 80, et je sais aussi qu’il existe des contournements, mais il semble y avoir différentes approches avec des résultats non confirmés et aucune validation officielle de Discourse du type « oui, cela fonctionne ».

Je suis un peu confus quant à la raison pour laquelle une plateforme aussi exceptionnelle a été conçue pour être si contraignante lors de la gestion d’un serveur web à ses côtés, mais mon expérience avec ce logiciel jusqu’à présent m’a suffisamment intéressé pour trouver un moyen de faire fonctionner les choses. J’ai vu qu’une intégration avec WordPress existe et qu’elle est mise en avant sur une page de fonctionnalités, mais encore une fois, Discourse semble ne pas être conçu pour être autre chose qu’une solution autonome.

Avez-vous des conseils ou des retours d’expérience de la part de ceux qui ont rencontré le même problème ? Merci !

Je pense que c’est ce que vous cherchez :

@neounix a de l’expérience avec l’exécution de Discourse avec apache2, il pourrait donc vous donner quelques conseils.

4 « J'aime »

Cela signifie-t-il que je devrais passer à Nginx ? Je n’ai absolument aucune expérience avec lui, et tous les serveurs web que j’ai utilisés jusqu’à présent, y compris ceux préconfigurés, utilisaient Apache.

Il existe également cette ressource pour Apache : Set up Discourse on a server with existing Apache sites

Cependant, il semble y avoir de nombreux problèmes pour le faire fonctionner correctement, en particulier avec SSL.

Serait-il plus simple d’exécuter deux droplets, l’un pour le site web et l’autre spécifiquement pour Discourse ? Je pourrais simplement modifier l’enregistrement DNS du sous-domaine pour qu’il pointe vers le droplet Discourse, ce qui devrait résoudre le problème. Je trouve juste étrange d’utiliser deux serveurs pour un forum.

Bonjour @OrbitStorm

Bienvenue !

Discourse n’est absolument pas un obstacle.

Maîtriser l’exécution de Discourse dans Docker derrière un serveur web proxy inverse est une expérience très gratifiante, que ce soit avec Apache2 ou nginx.

Si vous exécutez déjà des applications derrière Apache, il est facile de configurer une, voire 100, instances de Discourse dans Docker derrière Apache !

5 « J'aime »

Je vous remercie pour votre réponse.

Je le dis avec le plus grand respect, mais Discourse, tel quel, nécessite pratiquement son propre serveur. Utiliser un proxy inverse pour faire tourner un serveur web en parallèle de Discourse sur le même VPS est aléatoire, comme en témoignent les commentaires et autres plaintes, et le SSL peut fonctionner ou non. Il est également virtuellement impossible d’exécuter deux instances de Discourse sur le même serveur. Tout cela, pour moi, est un obstacle. Aucun autre logiciel de forum, y compris les plateformes haut de gamme comme XenForo ou Invision, ne demande un tel niveau d’effort avec autant d’incertitude. Ce sont des packages payants, donc je suppose que vous obtenez ce que vous ne payez pas avec Discourse. En tant que nouvel utilisateur face à tous ces obstacles, il semble que Discourse ait été conçu sans rien d’autre à l’esprit (c’est-à-dire les sites web).

Pour ce que cela vaut, comme mentionné dans mon message initial, j’ai utilisé un déploiement en un clic pour Discourse. Je devrai donc tout faire à l’envers pour essayer d’installer Apache (ou Nginx si je ne trouve pas de tutoriel) sur le même serveur. Si je dois utiliser Discourse comme ma plateforme de forum principale, je ne suis pas intéressé à faire tourner deux serveurs pour une seule communauté. C’est tout simplement absurde.

Je pense honnêtement que c’est faisable. Je ne suis pas expert et je me contente de suivre les très bons guides et tutoriels ici et là. J’ai eu peu ou pas de problèmes pour configurer Discourse derrière Nginx, donc j’ai probablement un peu de chance, mais je pense que c’est loin d’être impossible :slightly_smiling_face:
J’aime ceux-ci :
https://linuxize.com/post/how-to-install-nginx-on-ubuntu-18-04/
https://linuxize.com/post/secure-nginx-with-let-s-encrypt-on-ubuntu-18-04/
Je pense que ce ne sera pas une route facile d’ajouter au mélange multisite/multiconteneur et un clone S3 :sweat_smile:

Et pour la combinaison Postfix/Dovecot :
https://linuxize.com/post/install-and-configure-postfix-and-dovecot/

1 « J'aime »

@Benjamin_D Le problème que je rencontre est que tous les tutoriels disponibles ici omettent un aspect de mon environnement actuel. Il existe un tutoriel pour Apache, mais il utilise CentOS. Moi, j’utilise Ubuntu. L’autre tutoriel, rédigé par Kane York, utilise Nginx, mais comme je l’ai mentionné, j’utilise Apache.

Je ne fais rien de trop complexe non plus. J’utilise simplement DigitalOcean, Linux + Ubuntu 18.04, et j’héberge tout sur le droplet (sans utiliser de stockage tiers), etc. J’utilise Mailgun comme solution de messagerie, mais je ne pense pas qu’il propose une boîte de réception, ce qui convient pour le moment.

Je cherche simplement à rendre les choses aussi simples que possible.

1 « J'aime »

@OrbitStorm

En fait, Discourse est, à mon avis, le meilleur logiciel open source pour la création de forums et de communautés sur la planète actuellement, et ce pour de nombreuses raisons. En voici quelques-unes :

  1. Discourse est open source et bénéficie d’une communauté solide ainsi que d’une équipe de développement centrale très compétente (et capable).

  2. Discourse est conçu pour s’exécuter dans un conteneur Docker en production, ce qui présente de nombreux avantages :

  • Discourse peut être facilement déployé en mode autonome sans avoir besoin d’un serveur web ou d’une base de données externe.

  • Discourse peut être facilement déployé en mode multi-conteneurs, offrant ainsi une meilleure fiabilité et des mises à jour transparentes.

  • Discourse peut également être déployé dans des configurations de haute disponibilité en utilisant Docker Swarm et Kubernetes, ce qui permet à Discourse de monter ou de descendre en puissance « à la demande ».

  • Discourse est facile à sauvegarder et à restaurer. Nous pouvons utiliser la sauvegarde standard de Discourse fournie par défaut et la restaurer n’importe où dans le monde dans un conteneur Docker neuf et vierge.

  1. Discourse s’exécute facilement derrière les serveurs proxy inversés Apache2 et nginx. Cela présente également de nombreux avantages, en voici quelques-uns :
  • Discourse peut s’exécuter sur un serveur web existant, qu’il s’agisse de nginx ou d’Apache2, avec peu d’effort, que ce soit via des ports TCP/IP exposés par Docker ou des sockets de domaine UNIX.

  • L’exécution d’applications web derrière des proxy inversés est une pratique bien établie. Cette configuration n’est pas spécifique à Discourse, mais Discourse fournira son support.

  • La configuration de SSL est très simple derrière un proxy inversé et peut être aussi simple que certbot -d mon.super-site-discourse.com en utilisant LETSENCRYPT, qui est pris en charge et gratuit.

  1. Discourse est entièrement documenté, commit par commit, sur GitHub, afin que chacun puisse suivre les modifications du code.

  2. Discourse a un modèle commercial progressif, qui présente certains avantages clés, notamment :

  • Discourse, le logiciel de base ainsi que de nombreuses excellentes extensions, thèmes et composants, sont gratuits.

  • Discourse offre un support gratuit, y compris un support de configuration standard, sur meta.

  • Discourse propose un hébergement commercial pour ceux qui ne souhaitent pas auto-héberger ou préfèrent une approche plus « sans effort ».

  • Discourse encourage le conseil commercial et le développement d’extensions au sein de sa communauté, créant ainsi un écosystème commercial viable.

  1. Il y a encore plus à dire, mais je veux conclure !

Est-ce que je (est-ce que nous) sommes d’accord avec chaque décision prise par l’équipe centrale de Discourse, et est-ce qu’ils sont d’accord avec toutes nos (ou mes) idées et suggestions ?

Non, bien sûr que non ; et ils ne devraient pas l’être, ni nous, ni moi. Nous sommes libres de suggérer, de soumettre des propositions de code, des PR, et l’équipe centrale de Discourse abordera ces suggestions avec un esprit ouvert.

Mais en fin de compte, l’équipe centrale doit maintenir la communauté Discourse dans une direction cohérente, ce qui n’est pas facile lorsque des centaines de personnes de cultures différentes souhaitent des configurations différentes et ont des priorités, des modèles commerciaux et des idées divergentes.

Autrement dit, il n’y a rien à « éviter » (les mots de votre titre de sujet) dans Discourse, surtout en ce qui concerne la configuration de proxy inversés et la maîtrise de Docker. Beaucoup (y compris moi) passent à Kubernetes à cause de Discourse, non seulement pour Discourse mais aussi pour d’autres applications web.

Discourse est la « chose la plus éloignée » de l’« obstructif » (encore une fois, vos mots, pas les miens) ; et parce qu’il est basé sur des conteneurs, par conception, « le ciel est la limite » quant à la manière dont les administrateurs système expérimentés peuvent déployer Discourse dans des environnements de production hautement évolutifs ; et il est également suffisamment simple pour que les débutants puissent facilement le déployer en mode autonome.

Ai-je besoin d’en dire plus ?

Comme le dit la chanson REM (Losing My Religion) :

Oh non, j’en ai trop dit, je l’ai bien cherché

Je termine ce sujet… Bonne chance @OrbitStorm

2 « J'aime »

Si je comprends bien, ce que vous voulez, c’est que Nginx écoute et redirige un sous-domaine vers Apache d’un côté, et un autre sous-domaine vers le conteneur où se trouve Discourse de l’autre (en exposant le bon port dans app.yml ou en utilisant le modèle web.socketed), ou bien utilisez-vous Apache comme proxy ?

Je pense que Nginx est utilisé à la place de HAProxy dans le tutoriel CentOS :thinking:

Presque, mais non. Pour réitérer, je suis sous Linux + Ubuntu 18.04. J’utilise Apache pour servir un site web HTML standard (WordPress à l’avenir) et j’ai installé Discourse sur un sous-domaine. Je dois simplement comprendre comment configurer un proxy inverse (selon ces tutoriels) qui redirigera le trafic des ports 80 et 443 vers de nouveaux ports, car Apache utilise déjà ces deux ports. Je ne suis pas intéressé par l’utilisation de Nginx car je n’ai aucune expérience avec et je ne veux pas l’ajouter à Apache pour rendre ma configuration encore plus complexe.

Je ne suis pas un développeur avancé. Je suis juste quelqu’un qui maîtrise bien le frontend, a des notions de base sur les panneaux d’administration, une compréhension limitée de SSH et pratiquement aucune compréhension du reste (c’est pourquoi j’utilise des tutoriels).

Mon objectif final est d’avoir deux domaines avec une page d’accueil respective et plusieurs instances de Discourse (une pour chaque site). Des choses simples.

1 « J'aime »

Je ne sais pas si c’est plus complexe d’utiliser Apache à la fois comme serveur et comme proxy que de regrouper nginx ou HAProxy :sweat_smile:
Concernant le tutoriel, CentOS ou Ubuntu ne devrait pas faire une grande différence, apt au lieu de yum,
https://support.cloudflare.com/hc/en-us/articles/360029696071-Restoring-original-visitor-IPs-Option-2-Installing-mod-remoteip-with-Apache au lieu de

Je peux suggérer ceci pour Apache en tant que proxy inverse :

1 « J'aime »

Si vous voulez que votre vie soit facile, installez Discourse sur un droplet dédié. Vous ne pouvez vraiment pas faire tourner Discourse et Apache sur un droplet de 1 Go, donc deux droplets de 1 Go ne coûtent même pas plus cher.

2 « J'aime »

@pfaffman Mon intention n’a jamais été de rester sur la plus petite instance ; je l’utilise simplement le temps de configurer tout le reste. Inutile de payer un taux horaire plus élevé pendant les expérimentations.

La seule raison pour laquelle je n’ai pas trop envie de faire tourner deux instances, c’est que je devrai probablement migrer 3 à 4 domaines différents vers DigitalOcean. Je ne veux pas avoir à payer pour 6 à 8 instances. C’est de la folie.

Si vous voulez plus de 3 sites Discourse, vous voudrez probablement configurer un multisite. J’utilise une configuration avec Traefik, bien que j’explore d’autres proxys inversés.

Si vous utilisez Apache et que vous souhaitez plusieurs sites distincts, le terme de recherche pertinent est VirtualHost.

4 « J'aime »

Avec un petit droplet, vous voudrez peut-être réduire les tampons. Mon droplet dispose de 4 Go de mémoire et de 4 cœurs partagés.

2 « J'aime »

J’ai pu trouver une solution grâce à Bobbyiliev de DigitalOcean.

Vous pouvez trouver cette solution ici : Discourse not loading with Apache and proxy redirect - #8 by OrbitStorm

3 « J'aime »

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.