Multisite vs plusieurs conteneurs

Quelqu’un connaît-il les avantages et les inconvénients d’une installation multisite par rapport à plusieurs conteneurs ?

J’ai actuellement trois instances de Discourse dans des conteneurs séparés, et j’envisage de migrer deux, peut-être trois autres forums vers Discourse. Ils seront hébergés sur le même serveur (64 Go de RAM, avec des SSD), donc je me demande quelle serait la meilleure approche.

Je préférerais qu’ils soient aussi indépendants que possible, afin que chacun puisse être mis à jour, sauvegardé et restauré individuellement, et qu’un problème sur l’un n’affecte pas les autres.

Que me conseillez-vous ? Y a-t-il des avantages ou des inconvénients à surveiller ?

Avec un multisite, vous ne pourrez pas effectuer de mises à jour individuelles, ni segmenter les plugins utilisés. Tout cela est défini par le multisite racine. Les paramètres, les thèmes et les sauvegardes peuvent toutefois être gérés séparément.

Généralement, vous aurez également besoin d’un proxy devant pour gérer les certificats SSL.

En fait, j’ai trouvé un moyen d’obtenir des certificats Let’s Encrypt pour plusieurs domaines sans rediriger vers le domaine principal. Setup Multisite Configuration with Let's Encrypt and no Reverse Proxy

@AstonJ, seriez-vous intéressé(e) pour tester mon tutoriel ? Je suis à 90 % sûr que cela fonctionne, mais je n’ai pas testé depuis quelques semaines et je ne suis pas entièrement certain que les instructions soient claires pour quelqu’un d’autre que moi.

Si vous souhaitez que tous les sites aient les mêmes plugins et soient mis à jour simultanément, le multisite est idéal.

Je pourrais simplement désactiver les plugins inutilisés via le ACP (et je pense qu’il n’y en a qu’un dont l’un des forums n’aura pas besoin), donc je suppose que cela dépend des avantages à utiliser multisite ? Spécifiquement, la performance et/ou la stabilité ?

Je crois avoir lu @Blake poster une fois qu’il est fou de ne pas faire tourner PG dans son propre conteneur (est-ce différent de multisite ?), c’est pourquoi j’ai réfléchi à faire cela. D’ailleurs, ne me citez pas sur ce que Blake a dit, j’aurais pu rêver tout cela :rofl:

J’utilise HAProxy qui gère nos certificats SSL, donc je ‘pense’ que cela devrait aller.

Je pense que cela dépendra des avantages, Jay - s’il n’y a pas beaucoup de différence, cela ne me dérange pas de continuer comme je l’ai fait, car cela est devenu relativement facile à configurer et à gérer, mais s’il y a de grands avantages à passer à multisite, je serais definitely intéressé :sunglasses:

L’autre avantage est que vous n’exécutez qu’une copie supplémentaire de Rails et Nginx, donc la RAM supplémentaire requise est bien moindre. Vous avez beaucoup de RAM, cependant, alors opter pour ce qui fonctionne déjà commence à sembler être la meilleure idée.

Salut. Est-il possible de combiner les utilisateurs de plusieurs sites afin qu’un utilisateur puisse être enregistré sur tous les sites en même temps en s’enregistrant sur l’un des sites (comme dans Magento). Ou une super variante d’utilisation de Discourse, similaire à la fédération. Afin que les alertes fonctionnent de manière synchrone et que l’utilisateur du site n° 1 puisse recevoir des alertes du site n° 2 ? Il en va de même pour le chat.
J’ai 4 communautés de la même grande direction, mais avec des sujets différents, et j’aimerais que ces communautés soient étroitement intégrées les unes aux autres

Vous pouvez faire d’un site le serveur d’authentification de connexion discourse et faire en sorte que tous les autres s’authentifient auprès de lui.

J’essaie de déterminer si j’ai besoin d’une configuration multi-site, de plusieurs conteneurs ou d’autre chose.

J’ai actuellement 3 communautés indépendantes, deux d’entre elles similaires (toutes deux sur le sport universitaire mais pour deux écoles distinctes) et la troisième sur la cuisine et la pâtisserie.

J’aimerais que tout cela soit sur le même serveur (en raison des limitations d’adresses IP de mon FAI), mais à des URL distinctes, un peu comme ceci :

foo.bar.com/team1
foo.bar.com/team2
foo.bar.com/cooking

team1.bar.com redirigeant vers foo.bar.com/team1, etc., ou vers des serveurs virtuels séparés, serait également acceptable. (Je sais qu’Apache peut faire cela, donc je suppose que nginx le peut aussi, soit directement, soit avec un serveur proxy devant.)

Idéalement, foo.bar.com lui-même servirait de passerelle vers ces communautés indépendantes, expliquant ce qu’elles sont et comment y accéder. Certaines catégories de chaque communauté pourraient être lisibles publiquement et accessibles par les robots d’exploration du Web afin qu’elles apparaissent dans les recherches Web.

S’agit-il d’une configuration multi-site, d’une configuration multi-conteneurs ou de quelque chose d’entièrement différent ?

Existe-t-il des pièges connus dans la conception de plugins lors de l’exécution de Multisite ?

Il semble que mon Chatbot ne prenne pas en charge Multisite (c’est donc un problème connu), mais j’aimerais comprendre pourquoi : il fonctionne bien sur l’installation standard.

Plus précisément, il semble y avoir des problèmes avec la tâche de configuration de la base de données et potentiellement ce travail.

Je voulais faire le point sur ma situation.

Après quelques recherches, j’ai décidé d’avoir une configuration multisite (un seul conteneur à ce stade) avec un site nginx ‘externe’ pour expliquer la configuration et diriger les gens et le trafic vers les différents sites Discourse. De cette façon, je pourrais rendre les deux sites ouverts en lecture seule (et aux robots d’indexation) sans que les personnes de la liste1 aient à gérer le contenu de la liste2. Je devrai peut-être jouer avec robots.txt pour satisfaire les robots d’indexation.

Les exemples de configuration multisite ont été instructifs, mais je n’ai pas réussi à le faire fonctionner avec une socket Unix (erreur de passerelle), j’ai donc fini par les rediriger vers un autre port et rediriger ce port vers 443 à l’intérieur du conteneur.

Dans mon fichier app.yml, j’ai activé le modèle SSL mais pas celui de letsencrypt.

J’ai réussi à faire fonctionner le site de test, je cherche maintenant les problèmes qui pourraient survenir lors de la conversion du site de production, espérons-le plus tard ce mois-ci ou le mois prochain.

Je m’occupe du problème de certificat côté serveur externe, mais j’ai rencontré le problème ‘non sécurisé’ que j’ai résolu en exigeant https dans le conteneur. J’ai une tâche que j’exécuterai via cron pour copier le dernier certificat et la dernière clé dans le répertoire /shared/ssl du conteneur (sous forme de ssl.crt et ssl.key). Je ne suis pas sûr si je devrai forcer un rechargement de nginx à l’intérieur du conteneur pour m’assurer qu’un nouveau certificat est chargé lorsqu’il change (en juillet, je pense).

J’ai rencontré une autre particularité de Discourse :

Dans le fichier du conteneur /etc/nginx/conf.d/discourse.conf, il y a ce fragment de code (nom de domaine modifié) :

if ($http_host != 'site1.my.domain') {
   rewrite (.*) https://site1.my.domain$1 permanent
}

Cela provoquait la redirection de site2.my.domain vers site1.my.domain, j’ai donc dû le commenter.

NOTE : Reconstruire le conteneur nécessite de refaire cette modification, y a-t-il un moyen de l’éviter ?

Et cela a conduit à une particularité du navigateur, car Firefox avait alors signalé cette redirection comme permanente, j’ai donc dû supprimer le cache du navigateur. (Cela m’a pris beaucoup trop de temps à comprendre !)

J’ai trouvé une autre chose étrange.

Sur mon site de test, le paramètre pour exiger https n’était coché pour aucun des sites. Sur mon site de production, ce paramètre n’est même pas présent dans le fichier de configuration. Je suppose que cela a quelque chose à voir avec les différences entre les deux sites.