C’est mieux que DigitalOcean et leurs semblables, donc oui, c’est une bonne chose.
C’était acceptable, mais j’ai aussi souligné les contraintes, les sites avaient un trafic et une activité très faibles. Si vous vous attendez à une activité significative sur ces sites, vous avez besoin de plus de ressources, l’utilisation des ressources de Discourse augmente à mesure que vous recevez plus d’activités.
Cela dépend vraiment si vous avez besoin d’isoler certains sites des autres ou non. Les hébergements commerciaux de Discourse ne sont généralement que de grands clusters multisites avec une sauce spéciale par-dessus pour s’adapter à leur système de facturation, etc.
Eh bien, à moins que vous n’ayez une configuration avancée en place, tous les sites partageront les identifiants du site parent. C’est-à-dire que sans configuration avancée en place, si le site parent est configuré pour noreply@example.com comme adresse e-mail de non-réponse. Elle sera également utilisée par tous les sites enfants. Vous aurez besoin d’une configuration supplémentaire si vous souhaitez des e-mails uniques par site.
Cela dépend largement de ce que vous qualifiez par « problèmes »
Un seul app.yml pour le multisite est faisable, mais je recommanderais de passer à une installation à 2 conteneurs (web et données séparés) pour un multisite.
Vous devrez persévérer à travers quelques défis, modifier les chemins dans les fichiers yml, puis les démarrer. Essentiellement, comme si /var/discourse-a avait sa propre configuration et /var/discourse-b la sienne.
Pour information, ce sont des concepts assez techniques. Vous avez vraiment besoin d’une certaine expérience avec Discourse et son fonctionnement interne pour pouvoir héberger un multisite. Si vous êtes nerveux à ce sujet, envisagez un hébergement géré pour Discourse ou demandez à quelqu’un de l’installer professionnellement pour vous. Cela réduira considérablement vos maux de tête avec le temps. Envisagez de publier dans Marketplace si vous avez un budget.
Oui, mais c’est pour cela que je disais que je pourrai toujours passer à un forfait supérieur avec plus de ressources avec le temps. Ce n’était jamais mon intention de rester sur ce… forfait… pendant longtemps. J’essaie juste d’éviter des coûts inutiles lorsque je teste les eaux, vous voyez ?
Pouvez-vous me donner quelques raisons pour lesquelles je voudrais les séparer, autres que les ressources du serveur ? Pour l’instant, je ne vois pas de bonne raison de les mettre sur des serveurs séparés, mais je suis toujours prêt à apprendre quelques perspectives différentes sur des choses que je ne connais pas encore.
C’est un point très intéressant, que je ne connaissais pas. Il semble donc que ce soit effectivement quelque chose qui a été fait et qui fonctionne. Bon à savoir.
Qu’entendez-vous par site parent ? Chaque installation ne serait-elle pas indépendante ? Lequel serait considéré comme parent ?
Je suis un peu confus, car lorsque je regarde le fichier app.yaml, il y a une partie dédiée à l’e-mail et aux identifiants Brevo. Vous avez dit que je pouvais opter pour des fichiers app.yaml individuels par communauté. Alors, cela ne signifierait-il pas que chaque communauté aurait ses propres identifiants Brevo, y compris l’e-mail de notification ?
Des choses qui m’empêcheront de faire des sauvegardes correctement, ou des e-mails de notification qui ne sont pas envoyés correctement, des choses comme ça. Encore une fois, en tant que non-expert, et toujours nouveau dans Discourse, il y a des choses que d’autres pourraient considérer comme un problème, mais que je ne vois pas encore.
Oui, c’est ce que je pensais. La seule chose partagée serait le serveur lui-même. Tout le reste fonctionnerait comme une installation séparée, d’où la question sur l’e-mail, ci-dessus.
Je pense que les étapes les plus difficiles pour moi ont déjà été franchies, à savoir plonger dans l’installation de Discourse il y a quelques mois. Je n’avais aucune connaissance à ce sujet. Je ne savais même pas ce que signifiait « docker ». À ce stade, j’ai une perspective beaucoup plus claire, tout en me considérant toujours comme un « utilisateur de base de Discourse » en ce qui concerne l’auto-hébergement. Et avec l’aide de cette communauté et de ChatGPT/Claude, j’ai pu en apprendre un peu plus et prendre des notes sur le fonctionnement et l’installation des choses. Je suis à l’aise avec les défis, et soyons honnêtes : il s’agit vraiment juste d’installer un logiciel. Ce n’est pas comme si je construisais une bombe nucléaire Si quelque chose ne va pas, tout supprimer, revenir à une seule installation par serveur. Tout va bien
Comme je l’ai mentionné, j’ai déjà ma propre communauté installée, donc je crois que la partie la plus difficile est déjà derrière moi. Je suis doué pour suivre les instructions et poser des questions, donc au fur et à mesure que j’essaie des choses, je peux toujours faire une pause et faire des recherches, prendre des notes, etc.
Mon objectif maintenant est davantage de comprendre la mécanique de tout cela, les avantages et les inconvénients, ce qui est possible et ce qui ne l’est pas, afin de pouvoir prendre de bonnes décisions que je ne regretterai pas plus tard et qui m’obligeront à passer trop de temps à réparer les choses, vous voyez ?
Donc, toutes ces informations que vous partagez aujourd’hui sont super précieuses, car elles me donnent une bonne idée de ce à quoi réfléchir. Surtout lorsque vous avez mentionné que l’hébergement géré proposé par l’équipe de Discourse est un multisite. Cela m’a vraiment fait voir que c’est possible. Cela demande peut-être quelques étapes supplémentaires, mais tout peut être fait.
Vous devrez d’abord décider si vous souhaitez un seul multisite ou un seul serveur hébergeant plusieurs sites autonomes. Je m’abstiendrai de répondre à tout ce que vous avez demandé ci-dessus avant que vous ne décidiez de l’un ou de l’autre. Il y a beaucoup à comprendre, le simple fait d’installer Discourse sur une VM ne vous rend pas automatiquement éligible aux tracas du multisite ; par exemple, il m’a fallu 3 ans pour perfectionner l’expérience d’installation multisite pour moi-même. Certes, la documentation n’était pas très claire sur beaucoup de choses et j’ai dû Figure That Out (FTFO) beaucoup de choses pour y arriver. Et j’utilise Discourse depuis 2016-2017 (presque 9-10 ans à ce stade).
Alors s’il vous plaît, prenez du recul, et réfléchissez à ce que vous essayez d’accomplir, puis nous pourrons nous concentrer sur la réalisation de cet objectif.
Encore une fois, gardez à l’esprit que l’installation de Discourse n’est pas le plus grand obstacle, il y a encore beaucoup à apprendre et même après 9 ans d’utilisation et de déploiement de Discourse, je me considère toujours en train d’apprendre de nouvelles choses chaque jour.
C’était toujours mon objectif. Je ne vois aucun avantage, pour ce que je construis, à avoir un seul multisite. Mon objectif est simplement de réduire les coûts en utilisant un seul serveur avec des installations indépendantes.
Et je comprends ce que vous voulez dire à propos de la complexité des choses. C’est pourquoi je disais que même si j’ai réussi à l’installer et que je peux maintenant comprendre certains concepts, je me considère comme un utilisateur de base en ce qui concerne l’installation.
Après avoir fait de la musique pendant près de 35 ans, j’apprends encore de nouvelles choses tous les jours, donc tout va bien. Je suis partant pour apprendre tous les jours, et je ne m’attends jamais à ne pas le faire C’est pourquoi je suis dans cette communauté. Pour apprendre de nouvelles choses avec vous tous.
Donc, si vous voulez simplement avoir plusieurs sites Discourse sur le même serveur, sans qu’ils partagent le code ou le conteneur, voici ce que vous pouvez essayer :
Lisez attentivement le fichier app.yml et comprenez la section des montages (mounts). Vous aurez besoin de montages différents et prévisibles pour chaque site. Au minimum, vous devrez modifier ces répertoires manuellement.
La seule fois où j’ai fait cela (et je pense que je l’ai fait de la manière la plus peu ergonomique) j’ai cloné le code de Discourse dans deux répertoires différents, ce qui n’est peut-être pas nécessaire, mais je n’ai pas essayé, donc je ne suis pas sûr.
Dans chaque répertoire, j’ai exécuté ./discourse-setup avec quelques indicateurs pour sauter la vérification de connectivité et la reconstruction. Cela m’a donné des fichiers app.yml de base. L’étape suivante a été de modifier manuellement les deux fichiers, j’ai changé les montages, commenté la section qui exposait les ports et ajouté le modèle web.socketed pour laisser mon nginx externe gérer le ssl et les transferts internes.
Ensuite, il suffisait d’exécuter ./launcher rebuild app dans chaque répertoire.
Honnêtement, je n’étais pas un grand fan de cette configuration, j’ai donc abandonné après quelques mois de tâtonnements. Mais cela montre que ce que vous essayez de faire est réalisable, il vous reste juste quelques ajustements à faire.
Vous voudrez peut-être également réduire le nombre de travailleurs (workers) afin que tous les sites aient une chance équitable d’utiliser les ressources, mais c’est une expérience de pensée pour lorsque vous aurez posé les bases initiales.
Merci pour les informations détaillées !
Je suis toujours en train de considérer la meilleure option et même si je finis par utiliser cette option, je dois encore régler certaines choses.
[quote=“itsbhanusharma, post:30, topic:392692”]section des montages
[/quote]
Vous voulez dire ça ? Parce que lorsque j’ai cherché le mot « mount » (montage), rien n’est apparu, mais j’ai supposé que cela était lié aux volumes ?
Si oui, est-ce là que je crée différents chemins comme
var/discourse/shared/website1
var/discourse/shared/website2
etc. ?
[quote=“itsbhanusharma, post:30, topic:392692”]J’ai cloné le code de discourse dans deux répertoires différents
[/quote]
Donc, en gros, vous avez effectué une installation normale dans l’un des chemins, par exemple :
var/discourse/shared/website1
puis copié ces fichiers dans
var/discourse/shared/website2
?
Si c’est le cas, pourquoi exécuter ./discourse-setup ? Cela n’écraserait-il pas les fichiers ?
Ne serait-il pas préférable de simplement effectuer des installations normales dans les deux chemins ? Comme deux installations complètement séparées ? Pour quelqu’un comme moi, surtout lorsque vous mentionnez les « drapeaux » (flags) et tout ça, ce sont plus de choses dont je devrais m’inquiéter, et peut-être qu’une installation normale serait meilleure, puis modifier manuellement les fichiers app.yaml sur chaque chemin ?
ÉDIT : Laissez tomber. J’ai fait quelques recherches et je comprends ce que vous entendez par « cloner » dans ce contexte. Vous avez cloné les fichiers du dépôt. Je pensais que vous disiez que vous aviez tout installé dans un seul « chemin » puis copié ces fichiers dans un autre « chemin ».
Avez-vous déjà une instance Discourse en cours d’exécution ? Vous êtes sur ce forum depuis un moment. Essayez-vous de faire fonctionner une deuxième instance sur un serveur qui en héberge déjà une ?
La meilleure façon d’apprendre est d’essayer. Configurez un VPS (Virtual Private Server) bon marché et essayez. Si vous n’exécutez pas déjà une instance, installez simplement une installation standard auto-hébergée prise en charge et familiarisez-vous avec son fonctionnement. Vous n’aurez aucun visiteur réel et aucune raison de devoir sauvegarder quoi que ce soit. Vous pouvez simplement supprimer l’installation et réessayer encore et encore jusqu’à ce que vous maîtrisiez la procédure. Si vous configurez deux ou même trois instances s’exécutant toutes sur un seul VPS et qu’elles reçoivent toutes (virtuellement) zéro trafic, je parierais que le VPS le moins cher disponible pourrait probablement les faire fonctionner.
Si vous y parvenez, publiez un tutoriel pour que le reste d’entre nous puisse apprendre !
Oui, j’en ai une. Je souhaite installer des instances supplémentaires.
Comme cette installation est encore nouvelle et qu’aucun utilisateur ne s’est inscrit, il n’y a pas de problème à ce sujet. Je vais d’abord la sauvegarder et tout essayer sur ce serveur. Il n’y a pas encore de risque réel.
Je le ferai certainement. J’espère que cela pourra aider les autres.
@itsbhanusharma Je posais quelques questions supplémentaires à ChatGPT et à Claude, car je pensais vouloir renommer le chemin de l’instance actuelle de « discourse » au nom du site web comme « nom-du-site » et tous deux ont souligné quelques bonnes choses. L’une d’elles est que, puisque chaque installation nécessite 2 Go de RAM, si j’en installe 5 au total, par exemple, j’aurais besoin de 10 Go, n’est-ce pas ?
Si tel est le cas, ce plan serait probablement meilleur :
Toujours un très bon prix pour 5 instances, au lieu de 5 x 5 = 25 .
Quelles sont vos réflexions concernant la nécessité d’avoir 2 Go par instance ? Est-ce exact dans ce scénario ? Pensez-vous que ce plan que j’ai partagé conviendrait ?
J’ai plusieurs cas de clients qui ont causé plus de tort que de bien à leurs sites de discussion parce qu’ils ont aveuglément suivi les conseils de ChatGPT.
C’est un peu plus nuancé et le genre de chose qui n’est pas aussi simple que de faire 2+2. Et c’est en grande partie la raison pour laquelle l’approche multisite est une meilleure idée.
Encore une fois, je dirais arrêtez, faites une pause, prenez un peu de recul et réfléchissez à vos besoins. Il existe de bonnes ressources disponibles ici sur meta et le seul bot d’IA auquel je ferais confiance pour des conseils sur Discourse est https://ask.discourse.org
Je suis d’accord, mais vérifiez les informations en lisant les sources que le bot fournit. De cette façon, vous vous assurerez également qu’il n’a pas inventé les liens (cela arrive !).
C’est un peu extrême… Personne ne suit aveuglément les conseils de ChatGPT (du moins, pas moi), c’est pour ça que j’ai cette conversation avec vous tous ici.
J’utilise ces outils comme des outils. Ils mentionnent des choses qui me permettent de voir d’autres points de vue, puis je fais des recherches en ligne, ou je pose des questions ici dans la communauté. En cours de route, ils me montrent également d’autres concepts qui ne sont pas strictement liés à Discourse, ce qui est également une bonne chose. Les outils ne valent que ce que vaut la personne qui les utilise.
Et j’ai fait beaucoup de choses en utilisant les conseils de ChatGPT et de Claude. Nous ne pouvons pas rejeter tout ce qu’ils disent… aveuglément
Pourriez-vous m’en dire un peu plus à ce sujet ? Si les informations de ChatGPT / Claude sont inexactes, peut-être pouvez-vous m’éclairer, ainsi que les autres qui liront ceci à l’avenir ?
Pas dans mon cas, pour plusieurs raisons (et à moins que je ne manque quelque chose, les voici) :
Je veux pouvoir apporter des modifications personnalisées, si nécessaire, à chaque instance, sans affecter les autres. Pas que je vais le faire, mais je veux savoir que je peux le faire si je le souhaite.
Dans un multisite, si le parent plante, ils plantent tous, n’est-ce pas ?
J’aime simplement avoir les choses indépendantes. L’idée que 4-5 instances soient toutes connectées à quelque chose qui peut tomber en panne à un moment donné me dérange.
Encore une fois, ma perspective sur le fonctionnement d’un multisite est peut-être fausse, mais d’après ce que je comprends, cela ne semble pas être une bonne solution pour moi.
Pour le moment, mes besoins sont :
Construire toutes les communautés dont j’ai besoin
Dépenser le moins d’argent possible, car je ne sais pas si ces décisions de construire ces communautés sont bonnes à long terme ou non (j’ai déjà vécu cela, plus que je ne l’aimerais, en dépensant trop d’argent pour des “expériences”).
Je ne connaissais pas cet outil, alors merci de l’avoir partagé. Je l’ai mis en favori.
Je dois dire, cependant, que nous ne devrions pas aveuglément (désolé, j’ai dû le refaire haha) rejeter tout ce que disent ChatGPT ou Claude, même si le bot d’IA de Discourse est plus compétent, ce que je crois qu’il est avec autant de contenu disponible sur le sujet. J’utilise aussi ChatGPT et Claude, car parfois certaines choses ne sont pas seulement liées à Discourse et j’aime toujours en apprendre un peu plus sur d’autres choses.
Quoi qu’il en soit, j’apprécie vos commentaires et votre temps. Cela m’a déjà beaucoup aidé.
D’après ce que je comprends, vous êtes en train de trop réfléchir à votre configuration.
Fondamentalement, vous ne devriez pas poursuivre les 1000 idées brillantes de nouvelle communauté que vous avez toutes en même temps en lançant autant d’instances de Discourse (et par extension de tout autre logiciel) que possible.
La construction de communauté est un processus itératif et nécessite de la concentration. Si vous divisez votre attention entre plus d’une communauté à la fois, vous vous retrouverez avec plus de choses à gérer que vous ne pouvez en gérer.
Mes suggestions étaient une matière à réflexion, car comme je l’ai mentionné plus tôt, lorsque j’ai fait ces expériences, ce n’était que cela, un groupe d’amis faisant des choses parce qu’ils le pouvaient.
Il y a une (ou deux) raison(s) pour lesquelles ce ne sont pas des pratiques courantes ? Celles-ci entraînent une surcharge de maintenance et de gestion importante qui causera beaucoup de maux de tête et de nuits blanches plus tard, vous êtes prévenu.
Compte tenu de vos objectifs, je conclurai par cette déclaration : ce que vous essayez d’accomplir n’est pas impossible, mais aujourd’hui n’est pas le jour pour réaliser tout ce qui est possible. Concentrez-vous sur ce que vous avez sous la main, construisez votre première communauté, le reste pourra suivre le moment venu.
Quant à l’apprentissage par l’expérimentation, si la réduction des coûts est votre objectif principal, le multisite est la voie à suivre, avec tous les compromis qu’il présente.
Je comprends ce que vous voulez dire, et croyez-moi, si je devais créer toutes les communautés dont j’ai besoin pour tout ce dans quoi je suis impliqué, nous ne parlerions pas de 4 ou 5, mais plutôt de 15.
J’ai réussi à en identifier 3 qui semblent vraiment importantes et qui devraient être créées maintenant. À ce stade, les 3 ont besoin de leur propre espace pour offrir aux utilisateurs un lieu où discuter de leurs expériences avec les produits et services que je possède ou que je suis en train de créer.
Comme je l’ai dit, un multisite où tout dépend les uns des autres, ne me semble pas être la bonne solution et, pour être honnête, les maux de tête et les nuits blanches que vous mentionnez sont probablement plus susceptibles d’exister dans ce cas (du moins pour moi et mon expérience dans d’autres domaines où les choses dépendaient les unes des autres), dans une configuration multisite. Je ne sais pas… c’est un de ces cas où mon instinct me dit « ne le fais pas » et je lui fais confiance. Peut-être que j’ai tort et que je le prouverai avec le temps, mais je fais confiance à mon instinct d’abord.
Quoi qu’il en soit, merci encore pour votre temps et votre aide. J’apprécie
C’est un sujet opportun pour moi car je suis en train d’ajuster ma propre configuration pour gagner du temps et de l’argent. J’ai trois petits sites privés qui reçoivent très peu de trafic, mais ils sont tous importants pour moi. Je veux aussi pouvoir créer plus de sites pour tester de nouvelles idées. Le multisite m’intéressera donc.
Cela dit, je viens de migrer l’un de mes sites de DigitalOcean à Hetzner, et j’ai été surpris par les économies réalisées. C’est seulement 3,49 /mois pour leur plus petite offre cx23, ce qui est à peu près idéal pour un seul petit site. Je payais 15,60 chez DigitalOcean pour une configuration similaire.
Après avoir lu ceci et d’autres sujets connexes, mon principal point de blocage avec le multisite est que je veux utiliser l’envoi d’e-mails en livraison directe pour tous mes sites, en utilisant le nom de domaine du site comme nom de domaine de l’e-mail afin qu’il soit facilement reconnu et approuvé par les membres du site. Les instructions pour configurer cela ne semblent pas très simples.
Donc, pour l’instant, je conclus qu’il serait peut-être préférable pour moi de m’en tenir aux sites autonomes et de tous les migrer vers Hetzner. J’économiserai de l’argent, mais pas tant de temps étant donné le temps passé à attendre (littéralement “à faire tourner les pouces”) lors de la configuration de sites autonomes.
Vous pouvez le faire, mais seulement s’ils utilisent tous les mêmes identifiants smtp.
Puisque votre nouveau hébergement Hetzner est tellement moins cher, vous serez quand même gagnant avec trois sites plutôt qu’un seul au tarif précédent.
Je ne recommanderais pas le multisite avec seulement 1 Go de RAM, et il est plus difficile de le configurer, bien que le nouveau paramètre d’environnement des alias de nom d’hôte résolve l’un des plus gros problèmes.
Le cx23 dispose de 4 Go de RAM. Je déplace mes deux autres sites vers leurs serveurs cx23 séparés, nous verrons donc comment cela se passe, mais j’ai le sentiment que tout ira bien.
Je suis confus par cela car mail-receiver ne concerne que la réception d’e-mails et il n’y a pas d’identifiants smtp.
Parlez-vous des e-mails entrants ou sortants ? Pour les e-mails sortants, chaque site n’a-t-il pas ses propres identifiants smtp configurés dans app.yml ?
Non. Le récepteur de courrier est séparé. Si vous utilisez le multisite, il n’y a qu’un seul fichier YML et c’est là que les informations d’identification d’envoi SMTP sont définies. Si vous utilisez le récepteur de courrier, vous avez un problème différent, car vous avez besoin d’un récepteur de courrier pour chaque site (du moins, c’est la seule solution que j’ai trouvée).
Si quelque chose ne va pas, tout supprimer, revenir à une seule installation par serveur. Tout va bien 
