D’accord. Cela a du sens. Et je pense que Mailgun me conviendrait.
Je comprendrai tout cela mieux si et quand je commencerai à configurer un multisite !
3 « J'aime »
J’interviens car je suis dans une situation similaire à celle de @alltiagocom — j’ai installé Discourse sur un petit serveur Hetzner pour ma communauté principale, mais j’ai pensé, en arrière-plan, à migrer quelques autres groupes Facebook vers Discourse une fois que j’aurai maîtrisé les choses.
Je connais le « multisite Wordpress », mais j’ai compris que le multisite Discourse est plus complexe. Je me demandais ce qui serait le moins problématique : gérer deux sites autonomes (ou plus) ou un multisite.
Des éclaircissements à ce sujet ?
Multisite représenterait certainement moins de frais de maintenance, donc moins de maux de tête, mais votre expérience peut varier (YMMV).
1 « J'aime »
Pour les novices de Discourse, je recommande de n’exécuter que deux sites.
J’ai créé un sujet sur la façon d’exécuter multi-site sans proxy inverse, mais il est obsolète maintenant.
Je pense que tout ce qui doit changer est
peut être remplacé par le nouveau
DISCOURSE_HOSTNAME_ALIASES: domain.com,other.domain.com
2 « J'aime »
Mon grain de sel, après avoir passé toute la journée à travailler là-dessus avec l’aide de mes vieilles notes, de ChatGPT, de Claude, du bot IA de Discourse, et de quelques sujets partagés ici (et après avoir pris des notes et encore des notes sur tout le processus).
Tout semblait fonctionner parfaitement jusqu’à ce que j’arrive au point où je devais ajouter le proxy inverse. Ma première instance, qui fonctionnait bien, ne fonctionnait plus. J’ai posé quelques questions supplémentaires au bot IA de Discourse, mais comme c’est mon premier jour, il a cessé de fonctionner. C’est une limitation pour les nouveaux utilisateurs du bot. Claude, qui était super utile, s’est également arrêté, car je suis sur la version gratuite. ChatGPT est le moins fiable de tous, donc toutes les réponses de sa part sont toujours reçues par moi avec ÉNORMÉMENT d’hésitation…
Ensuite, je suis revenu sur le forum et j’ai commencé à lire quelques sujets à ce sujet, certains écrits par @pfaffman. Ce fut la goutte d’eau qui a fait déborder le vase. Trop complexe, trop de termes techniques pour que je puisse même comprendre quoi demander.
Résumé : ma première instance fonctionnait, je vais donc la rétablir à son état antérieur (modifier le fichier app.yml pour revenir à ce qu’il était avant les changements. Je suis en train de reconstruire pendant que j’écris.
Honnêtement, malgré toute la complexité, même si cela me permettrait d’ajouter plus de communautés après avoir surmonté le premier grand obstacle, je ne pense pas que l’économie de 4 par mois pour une communauté supplémentaire va être la fin du monde. Comme je sais déjà comment configurer un serveur chez Hetzner puis installer Discourse, je vais m'en tenir à 2 communautés pour l'instant, payer 8 pour les deux, et passer à autre chose. Étant donné que je payais 12 $ pour un seul droplet chez Digital Ocean il y a quelques mois, je peux faire l’effort de payer le même montant pour 3 communautés si je le souhaite.
Néanmoins, je trouve toujours ces aventures intéressantes, car j’apprends quelque chose de nouveau en cours de route, et au final, au moins je peux dire pourquoi je ne veux pas le faire, plutôt que de simplement dire « Je ne le ferai pas, parce que je ne sais pas si je peux le faire ».
J’apprécie le temps et l’aide que vous avez tous partagés ici, et j’espère que ce sujet aidera les autres qui veulent réaliser ce que j’essayais de faire.
Terminé !
8 « J'aime »
C’est exactement pour cela que j’ai dit que vous deviez repenser votre stratégie. Bien que ce que vous essayiez d’accomplir n’était pas impossible, car cela a déjà été fait, cela nécessite une compréhension significative de Discourse pour être bien fait.
Je vous recommanderais de continuer à expérimenter pendant votre temps libre si vous souhaitez en apprendre davantage sur le fonctionnement de Discourse, c’est ainsi que la plupart d’entre nous ici l’ont appris.
9 « J'aime »
Il m’a fallu beaucoup plus de temps que je ne veux l’admettre pour (principalement) le comprendre !
6 « J'aime »
6 messages ont été déplacés vers un nouveau sujet : Conteneurs d’applications multiples pour un seul site Discourse
Je documente une installation Discourse multisite prise en charge sous forme de guide d’exécution pas à pas (command-by-command runbook).
J’ai précédemment expérimenté avec une approche de « multiples installations autonomes sur un seul serveur », mais cette configuration n’est pas prise en charge. Ce billet se concentre uniquement sur l’architecture multisite prise en charge, réécrite dans un format linéaire pour ceux qui préfèrent des étapes explicites.
Ce que c’est (pris en charge)
- Un conteneur d’application Discourse (
app) - Multisite activé via
multisite.yml - Postgres + Redis partagés (gérés par Discourse)
- Connectivité via sockets Unix (aucun réseau Docker requis)
- Plusieurs noms d’hôte acheminés vers des sites distincts en interne
Ce que ce n’est pas
- Plusieurs conteneurs Discourse indépendants derrière HAProxy
- Reconstructions progressives en vidant les nœuds d’application
- Informations d’identification SMTP par site (SMTP est partagé)
Notes opérationnelles (pour que les attentes soient correctes)
Reconstructions / temps d’arrêt
En multisite, il n’y a qu’un seul conteneur d’application, donc ./launcher rebuild app redémarrera le seul nœud. Cela signifie qu’un court temps d’arrêt pour tous les sites est attendu.
Certificats / validation d’hôte
Ajoutez tous les noms d’hôte à DISCOURSE_HOSTNAME_ALIASES afin que Let’s Encrypt + la validation d’hôte fonctionnent de manière fiable.
Sauvegardes / migration ultérieure
Chaque site effectue sa propre sauvegarde dans /admin/backups. La restauration d’une sauvegarde de site sur une installation autonome ultérieure est la voie de migration normale.
Guide d'exécution complet du multisite pris en charge (commande par commande)
0) Prérequis de l’hôte
| Étape | Commande |
|---|---|
| Mise à jour du système | apt-get update && apt-get upgrade -y |
| Installation des dépendances | apt-get install -y git curl sudo |
1) Installer Discourse Docker
| Étape | Commande |
|---|---|
| Cloner le dépôt | git clone https://github.com/discourse/discourse_docker.git /var/discourse |
| Entrer dans le répertoire | cd /var/discourse |
2) Installer le premier site (site unique d’abord)
| Étape | Commande |
|---|---|
| Exécuter la configuration | ./discourse-setup |
Ceci crée /var/discourse/containers/app.yml et démarre le premier nom d’hôte (par exemple, forum1.example.com).
3) Activer le multisite
| Étape | Commande |
|---|---|
| Créer le répertoire de configuration | mkdir -p /var/discourse/config |
| Modifier le fichier multisite | nano /var/discourse/config/multisite.yml |
Exemple de multisite.yml :
forum1:
host_names:
- forum1.example.com
forum2:
host_names:
- forum2.example.com
4) Modifier app.yml pour activer le multisite + les alias de nom d’hôte
| Étape | Commande |
|---|---|
| Modifier app.yml | nano /var/discourse/containers/app.yml |
Ajouter :
DISCOURSE_MULTISITE: trueDISCOURSE_HOSTNAME_ALIASES: forum1.example.com,forum2.example.com
5) Reconstruire
| Étape | Commande |
|---|---|
| Reconstruire | ./launcher rebuild app |
6) Migrer les bases de données multisite
| Étape | Commande |
|---|---|
| Entrer dans le conteneur | ./launcher enter app |
| Exécuter la migration multisite | rails multisite:migrate |
| Quitter | exit |
| Étape | Commande |
|---|---|
| Redémarrer | ./launcher restart app |
7) Vérifier
Visiter :
https://forum1.example.comhttps://forum2.example.com
Chaque site a son propre administrateur, utilisateurs, téléchargements et sauvegardes.
8) Sauvegardes / migration ultérieure
Administrateur par site :
/admin/backups
Restaurez cette sauvegarde sur une installation autonome ultérieure si vous souhaitez séparer le site sur son propre serveur.
Si quelque chose ci-dessus entre en conflit avec les meilleures pratiques actuelles, je serai ravi de mettre à jour ce guide d’exécution - l’intention est de fournir une liste de contrôle linéaire du multisite pris en charge qui réduit les essais et erreurs.
2 « J'aime »
Wow ! C’est le guide clair dont j’avais besoin pour y voir clair dans le monde trouble du multisite !! Cela semble en fait très faisable et beaucoup plus simple que je ne l’avais imaginé.
C’est un peu dommage que cela ne puisse être fait que dans un seul conteneur, mais je comprends intuitivement pourquoi c’est nécessaire. Par conséquent, cela conviendrait mieux à plusieurs forums auto-hébergés plus petits et plus calmes.
Votre réponse mérite certainement son propre sujet (wiki), et d’être bien signalée.
2 « J'aime »
Peut-être quelque chose pour moi 
1 « J'aime »
Ceci est-il également applicable lorsque Discourse fonctionne déjà en tant que « monosites » et que l’on souhaite le convertir en multisites ?
Merci beaucoup pour le travail !
1 « J'aime »
Merci ! Ceci est toujours conforme à la pratique multisite prise en charge actuelle - rien ici n’entre en conflit avec le fonctionnement actuel de Discourse multisite.
Oui, les mêmes étapes s’appliquent lors de la conversion d’une installation monosite existante en multisite : un monosite est effectivement un multisite avec un seul site par défaut. Vous pouvez activer DISCOURSE_MULTISITE, ajouter multisite.yml (y compris le site existant), reconstruire une fois, et exécuter rails multisite:migrate sur place.
S’il y a quelque chose ici qui ne reflète plus les meilleures pratiques, je suis très heureux de mettre à jour le guide d’exploitation - l’objectif est une liste de contrôle linéaire et prise en charge qui évite les essais et erreurs.
3 « J'aime »