Après avoir passé une semaine à chercher une solution pour installer Discourse à côté d’Apache, je demande à contrecoeur des conseils pour mes prochaines étapes, car il semble que l’activation d’un certificat SSL pour Discourse derrière Apache soit pratiquement impossible, étant donné la conception de Discourse qui privilégie Nginx.
Structure actuelle de mon environnement d’hébergement :
Droplet Digital Ocean à 10 $
Ubuntu 18.04
Apache avec SSL Let’s Encrypt pour la page d’accueil HTML
PHP, MySQL et phpMyAdmin
Webmin (sans SSL)
Discourse
Je souhaite conserver la flexibilité d’installer WordPress, donc je ne suis pas convaincu que Nginx soit la bonne voie, car j’ai lu qu’Apache assure une meilleure compatibilité avec WordPress.
Mon objectif : activer un certificat SSL sur l’ensemble de mon domaine, y compris Discourse, sans avoir à déployer Discourse sur un droplet séparé. Si cela nécessite une utilisation limitée de Nginx, ce n’est pas un problème. J’ai juste besoin de savoir quels tutoriels consulter pour résoudre ce problème.
Je recherche quelque chose de similaire, mais vous êtes en avance dans le processus. J’ai quelques questions sur votre configuration, si vous ne voyez pas d’inconvénient à y répondre.
Disposez-vous d’un proxy inverse ?
Le proxy inverse gère-t-il le SSL ?
Les autres serveurs ne gèrent-ils pas le SSL et se reposent-ils sur le proxy inverse pour cela, ou appliquez-vous une défense en profondeur avec chaque serveur gérant son propre SSL ?
La communication entre le proxy inverse et les serveurs se fait-elle exclusivement via des sockets et non des ports ?
À titre d’information, j’ai effectué des tests approfondis avec Apache2 et nginx en tant que proxys inversés devant Discourse en production (en utilisant des sockets Unix), et nginx n’est pas « beaucoup plus rapide ».
Dans cette configuration, nginx est « légèrement plus rapide », mais la différence de vitesse n’est pas perceptible pour l’utilisateur.
De plus, les tests Google PageSpeed dans les outils pour webmasters (Lightspeed), moyennés dans le temps, ne montrent aucune différence significative entre les deux proxys inversés.
Ce commentaire à titre d’information ne repose ni sur la théorie ni sur la répétition de ce que d’autres ont écrit ; il est basé sur des tests réels en production.
Nous faisons tourner toutes nos instances Discourse derrière des proxys inversés Apache2 (elles étaient initialement des proxys inversés nginx) car nous aimons gérer de nombreux sites web (hôtes virtuels) sur nos serveurs où des applications LAMP sont déjà hébergées.
Toute personne souhaitant utiliser Apache2 comme proxy inversé au lieu de nginx n’aura aucun problème ! Ce fait rend Discourse facilement accessible à un large éventail d’utilisateurs et d’hébergeurs (Apache2 et nginx).
@fzngagan Je ne repars pas de zéro et ce tutoriel est destiné à CentOS, alors que j’ai clairement indiqué dans mon message que j’utilise Ubuntu.
@EricGT Jetez un œil à la solution que j’ai partagée dans mon propre fil, car trouver de l’aide si vous n’utilisez ni Nginx ni CentOS est pratiquement impossible — comme en témoigne ce fil où je n’ai reçu aucune réponse à ma question, mais plutôt un débat hors sujet sur Apache contre Nginx.
Cela peut très bien être le cas, mais Apache est mieux pris en charge. Discourse est le seul logiciel de forum qui impose essentiellement Nginx à ses utilisateurs. C’est pourquoi je préfère rester sur Apache, car il est plus courant, plus facile pour les nouveaux utilisateurs, et il sera beaucoup plus simple de trouver de l’aide. Le « réglage fin » n’est pas quelque chose qui m’intéresse.
Pourtant, la communauté Discourse le décourage activement et refuse de fournir un support aux personnes qui souhaitent le faire, à l’exception de la liaison vers des tutoriels non pris en charge. J’ai créé plusieurs fils et posé encore plus de questions, mais vous êtes le seul à vous être approché de la fourniture d’un soutien (dans un autre fil) en partageant votre configuration, et en tant que novice, on s’attendait à ce que je déchiffre et l’applique à mon propre cas. Tout le reste s’est résumé à « consultez ce tutoriel obsolète » ou à des bavardages hors sujet.
Eh bien, comme nous l’avons clairement indiqué à plusieurs reprises, il y a une limite à ce que nous pouvons prendre en charge gratuitement ici en raison de contraintes de temps et de santé mentale. C’est pourquoi nous proposons une installation standardisée qui fonctionne bien pour 95 % des personnes qui l’essaient, et nous la prenons entièrement en charge.
Si vous souhaitez explorer des options de support payant pour des installations personnalisées, je vous recommande de consulter Marketplace.
Ce forum fonctionne largement en pair-à-pair, donc votre affirmation n’a aucun sens. De plus, je n’ai jamais posé de question complexe, seulement demandé des clarifications ou des mises à jour pour des tutoriels existants qui sont continuellement liés alors qu’ils sont obsolètes ou incorrects. J’ai dû obtenir l’aide de DigitalOcean, un fournisseur d’hébergement, pour mettre en place un véritable proxy inverse. C’est époustouflant, même pour un logiciel open source.
Votre réponse me donne l’impression que le « support » ici n’est qu’une mascarade visant à vendre des services supplémentaires.
Tout d’abord, nous utilisons Discourse en production derrière un proxy inverse Apache2 (dans plusieurs instances) et nous n’avons rencontré aucun problème lors de sa configuration ; mis à part le « Google quand on a besoin d’aide » que tout le monde fait sans hésiter.
Deuxièmement, je n’ai jamais demandé à l’équipe Discourse ou à quiconque sur Meta de prendre en charge Apache2 en tant que proxy inverse, car cette configuration n’est pas officiellement prise en charge. À ma connaissance, Discourse ne prend pas « officiellement » en charge les configurations multi-conteneurs, les proxies inverses (Apache2), Kubernetes, Docker Swarm, et un nombre pratiquement infini d’autres configurations. Il est compréhensible et correct que l’équipe Discourse, qui offre ce logiciel gratuitement et rend tout le code source accessible, y compris chaque commit sur GitHub, limite ses « configurations officiellement prises en charge ». Je pense que Jeff a bien résumé cela de manière très juste :
Eh bien, comme nous l’avons clairement indiqué à plusieurs reprises, il y a une limite à ce que nous pouvons prendre en charge gratuitement ici en raison de contraintes de temps et de santé mentale. - Jeff A.
Troisièmement, Discourse fournit plusieurs tutoriels pour des configurations « non prises en charge », comme l’utilisation d’Apache2 en tant que proxy inverse ; cependant, configurer un proxy inverse n’est pas une « tâche Discourse » en soi. Configurer un proxy inverse est une « tâche générique d’administration système » qui est fondamentalement la même pour n’importe quelle application backend, y compris Discourse.
Nous utilisons Apache en tant que proxy inverse devant plusieurs applications web, notamment Discourse, Docker Registry, et d’autres conteneurs et applications Docker. L’utilisation d’Apache2 (ou nginx) en tant que proxy inverse n’est pas spécifique à Discourse. C’est une tâche générique d’administration système.
Quatrièmement, il existe une multitude d’informations sur le web concernant la configuration d’Apache2 en tant que proxy inverse pour une application. Il est totalement inutile et peu utile à votre cause d’intimider l’équipe Discourse sur cette question. Intimider les gens et utiliser des termes comme « charade » est à la fois inexact et peu utile à votre cause (ou à quiconque ici).
Donc, pour résumer @OrbitStorm (ce sera mon dernier message sur votre sujet, alors veuillez lire attentivement) ce qui a déjà été dit, y compris les mots gentils et patients de J. A., vous avez plusieurs choix :
Vous pouvez facilement aller sur le web et apprendre à configurer Apache2 en tant que proxy inverse (c’est ce que nous avons fait), et c’est amusant et gratuit d’apprendre à réaliser cette tâche générique d’administration système.
Vous pouvez engager quelqu’un pour le faire si vous n’êtes pas disposé à apprendre, si vous ne pouvez pas « trouver la solution » par vous-même ou si vous n’avez pas le temps.
Vous pouvez poster ici, vous plaindre et crier, qualifier Meta et ce forum de « charade » et lancer des insultes à tout le monde pour essayer de les intimider afin qu’ils vous soutiennent personnellement dans une configuration non prise en charge.
Je recommande fortement, en tant qu’utilisateur de Discourse et administrateur système depuis plusieurs décennies, de ne pas choisir l’option #3 (l’intimidation et le harcèlement ne fonctionneront pas avec l’équipe Meta, je peux vous l’assurer) ; et de considérer l’option #1 si vous ne souhaitez pas dépenser d’argent pour obtenir de l’aide.
Configurer Apache2 en tant que proxy inverse pour Discourse est en réalité assez simple. Il existe quelques publications sur Meta Discourse à ce sujet (certaines récentes, d’autres plus anciennes) et d’innombrables tutoriels sur le web expliquant comment configurer Apache2 en tant que proxy inverse pour une application web. La technique est la même. Je recommande d’exposer un socket Unix lorsque vous exécutez en mode proxy inverse.
Honnêtement, c’est amusant de configurer Apache2 en tant que serveur virtuel proxy inverse pour Discourse. Pourquoi rendre cela stressant et poster des insultes envers les personnes qui ont créé ce formidable logiciel et le donnent gratuitement ? Discourse est un cadeau gratuit ! Si vous souhaitez configurer Discourse autrement que dans les configurations officiellement prises en charge, personne ne vous en empêchera !
Pour conclure @OrbitStorm, je vous conseille vivement (en tant qu’utilisateur de Discourse, et non membre de l’équipe) de changer votre approche consistant à intimider Meta pour obtenir du soutien. Comme je l’ai dit, j’exécute Discourse dans des configurations « non officiellement prises en charge » et j’ai publié des mises à jour et du code ici pour aider les autres (en redonnant à cette grande communauté). J’ai déjà publié du code fonctionnel, facile à suivre, pour configurer Apache2 en tant que proxy inverse, tout comme d’autres avant moi.
Veuillez choisir soit l’option #1 (faites-le vous-même), soit l’option #2 (engagez quelqu’un pour le faire) ; et veuillez abandonner votre approche actuelle de l’option #3 (intimider, harceler et insulter l’équipe Meta). Si vous souhaitez choisir l’option #3, allez poster sur nos forums Unix et Linux et vous pourrez m’intimider là-bas si vous le souhaitez, autant que vous le voudrez
Vous avez rédigé ce pavé en réponse sans jamais aborder le sujet d’origine, dans un effort vain pour jouer les chevaliers blancs de quelque chose qui n’est même pas attaqué. Vous m’avez même qualifié de « harceleur » (lol ?) parce que j’ai répondu à des non-sens hors sujet d’un type qui m’a assailli d’arguments ad hominem sur mon intelligence et a fait de ce fil son tribune pour Nginx (commentaires qui ont été convenientement supprimés pour enterrer les preuves de la nature toxique que ce forum engendre envers les nouveaux utilisateurs). Votre premier message n’était guère différent, car il répondait à ma question sans vraiment y répondre. Vous faites partie du problème.
Vous continuez de parler d’obligation, et pourtant, vous persistez à répondre à mes fils juste pour être conflictuel (comme Stephen l’avait fait). Je ne savais pas qu’il existait une règle m’interdisant de demander de l’aide pour une configuration d’hébergement populaire (W3Techs a été cité plus tôt et indique une part de marché de 67 % pour Apache). Vous auriez pu simplement laisser mes fils sans réponse si vous n’approuviez pas, mais vous avez choisi d’être belliqueux et de détourner la conversation.
Vous déformez intentionnellement mes propos parce que je ne me conforme pas au statu quo consistant à accepter un tutoriel obsolète puis à ne plus jamais revenir — un facteur expliquant pourquoi pratiquement tous les fils concernant cette configuration restent sans solution (c’est-à-dire le harcèlement de types comme vous). Pensez-vous vraiment que je n’ai pas fait mes devoirs avant de poster ? J’ai accepté ce que je savais venir, mais j’espérais que d’autres qui pourraient se trouver dans ma situation (comme EricGT) pourraient offrir quelque chose de valeur avant que cela ne soit écrasé à mort par des « réponses » pompeuses.
Je travaille dans le développement de jeux depuis 16 ans et je n’ai jamais connu un tel niveau dément d’amateurisme et de mesquinerie que celui que j’ai vécu ici en seulement cinq courts jours. C’est du niveau de Reddit, d’une corniche absolue ; une blague totale.
De plus, c’est la preuve par l’exemple. Incroyable.
Je ne vois pas pourquoi la configuration SSL aurait un lien avec les applications derrière le proxy , tant que le modèle SSL est désactivé dans le fichier app.yml ? Nginx, Apache, HAProxy ou Traefik, ils partagent tous le même concept de snippet, de bloc de serveur ou de hôte virtuel où l’on active simplement SSL, on indique l’emplacement des certificats sur l’hôte et quelques paramètres SSL : ici, attention aux dragons peut-être ?
Je pense que la solution que vous cherchez n’est pas liée à Discourse mais plutôt à Apache, et je crois qu’une configuration SSL Apache fonctionnant « out of the box » avec un hôte virtuel fonctionnera parfaitement avec Discourse, comme cela a été le cas avec d’autres proxies inversés, mais je peux être un peu optimiste .
Cependant, je me souviens avoir rencontré un problème avec les chiffrements peut-être ; assurez-vous de copier/coller avec soin (la ligne est très longue) ceux utilisés dans le conteneur Docker.
Concernant cette pente glissante, je pense que c’est un peu comme skier hors des pistes : c’est génial, mais très mal vu par le secours en montagne. Et j’avoue que la perception change radicalement quand on tombe dans un ravin tout en apprenant à skier, qu’on soit un skieur accompli ou non.
S’il vous plaît, professionnel ou non, soyez bienveillant envers le
, tant que le modèle SSL est désactivé dans le fichier app.yml ? Nginx, Apache, HAProxy ou Traefik, ils partagent tous le même concept de snippet, de bloc de serveur ou de hôte virtuel où l’on active simplement SSL, on indique l’emplacement des certificats sur l’hôte et quelques paramètres SSL : ici, attention aux dragons peut-être ?
.