Je souhaiterais modifier mon app.yml afin de pouvoir lancer un autre Discourse (conteneur séparé, base de données séparée, tout ce qu’on peut imaginer ! pour la portabilité) sur la même machine (derrière nginx).
Ainsi, ma première configuration ressemble à ceci (les parties importantes) :
.. et cela fonctionne très bien : l’instance est en ligne et tout est parfait. Maintenant, je souhaite héberger un autre Discourse, pour lequel j’ai défini les volumes partagés comme suit dans un autre app.yml :
Dans cette deuxième configuration, y a-t-il des pièges ? Je l’exécute sur une machine de production, alors je voulais vérifier que cet app.yml est correct.
@Stephen : nginx n’est qu’un proxy inverse vers la première instance de Discourse. Rien de compliqué. En fait, la configuration suit celle que j’ai appliquée sur meta.discourse pour installer nginx comme serveur frontal.
AUCUN autre service ne s’exécute sur cette machine. En fait, comme il s’agit d’un serveur de production, j’ai tout configuré dans un dossier d’hôte entièrement séparé : discourse_site02. Est-ce que cela a du sens ?
Voyez-vous un problème avec le fichier app.yml que j’ai décrit ? Ou pensez-vous qu’il y a une erreur dans ma configuration ?
Y a-t-il une raison pour laquelle vous n’utilisez pas une installation multisite à deux conteneurs alors ? Je ne pense pas que vous perdiez beaucoup en portabilité ici ; le moyen le plus rapide de déplacer des instances entre les serveurs consiste à migrer une sauvegarde.
Si vous deviez déplacer une instance, vous lanceriez simplement un nouveau serveur, marqueriez l’ancienne instance en lecture seule, redirigeriez le DNS et restaureriez la sauvegarde. Avec un service DNS à faible TTL comme Cloudflare, un petit site peut être migré en quelques minutes. Les utilisateurs connaîtraient une brève période d’accès en lecture seule, sans perte de contenu.
Il est beaucoup plus efficace de répartir les ressources de cette manière : vous n’aurez pas à faire fonctionner deux serveurs de base de données et deux serveurs web dans des conteneurs séparés, ce qui élimine totalement le besoin d’un proxy inverse nginx.
@Stephen : oui, j’ai bien vu le lien que vous avez partagé, mais pour simplifier la configuration (nous sommes une petite équipe avec peu d’expérience), je préfère procéder comme je l’ai décrit, ce qui aboutit à deux bases de données et deux serveurs web, etc. En fait, c’est exactement la configuration que je privilégie.
Outre les inefficacités que vous avez soulignées, y a-t-il d’autres pièges à éviter ?
Les deux fichiers app.yml que j’ai montrés sont-ils corrects ?
Merci pour votre temps et pour ce logiciel formidable
@Stephen : je me demandais simplement, penses-tu que ma configuration semble correcte pour une mise en place à 2 conteneurs ?
Comme je l’ai dit, je ne cherche pas à économiser des ressources ou à être efficace je veux juste savoir si c’est acceptable de fonctionner ainsi, en supposant qu’il n’y ait pas de pièges qui me prendront au dépourvu plus tard.
je veux juste savoir si c’est acceptable de fonctionner ainsi, en supposant qu’il n’y ait pas de pièges qui me prendront au dépourvu plus tard.