Meilleure approche pour les instances de test et de production de Discourse

Soutien Installation
1

Bonjour,
Je suis sur le point de créer une instance Discourse sur un serveur cloud Digital Ocean, conformément au guide.

Pour commencer, nous utilisons Discourse dans une configuration légère/par défaut, en l’étendant progressivement. Pour nous familiariser, nous souhaitons utiliser l’instance de test occasionnellement.
Quelle approche est la plus judicieuse dans ce cas ?

  1. Le même serveur derrière un proxy inverse
  2. Multisite

comme résumé dans Sandbox and test discourse on host ?.

Je sais que la première option nécessite plus de RAM, comme indiqué dans Two standalone instances on one server? - #26 by schleifer, mais elle ne fonctionne que de manière occasionnelle.
Il existe d’autres sujets traitant de cette question :

  1. Multiple instances Discourse sur un seul serveur
  2. Exécuter d’autres sites web sur la même machine que Discourse
    mais il n’y a pas de comparaison avantages/inconvénients.

Un autre objectif de cet exercice est de se familiariser avec :

  1. les sauvegardes
  2. le déplacement
  3. la migration de contenu
  4. la migration des paramètres
  5. la migration de discussions individuelles

Un cas d’usage serait de discuter quelque chose sur l’instance de production, de déplacer le contenu du forum (l’intégralité de la base de données), de le tester sur l’instance de test, puis de ramener la discussion vers la prod. via l’export/import de discussions individuelles et la copie des paramètres modifiés, au cas où nous testerions et approuverions un plugin.

2

Le multisite n’est d’aucune utilité pour un serveur de test. Si vous effectuez une mise à jour pour vérifier s’il y a un plugin défectueux, les deux sites sont compromis.

Un même serveur derrière un proxy inverse est possible, mais cela pose de nombreux problèmes ; si cela ne vous dérange pas, l’une des solutions « plusieurs instances Discourse » pourrait vous convenir. La plus simple consiste à utiliser un serveur distinct et à faire en sorte qu’ils partagent tous les deux un bucket de sauvegarde S3, ce qui facilite la restauration des données du site de production vers le site de développement pour voir à quoi cela ressemble. Cela vous convaincra également que vous pouvez déployer un nouveau serveur à partir de la sauvegarde la plus récente.

3

C’est vraiment pas cher :slight_smile: mieux que la solution OD, comment pousser automatiquement les sauvegardes vers S3 depuis DO ?

Pourriez-vous me dire quels sont les tracas :upside_down_face:
comme nous adoptons une approche à faible coût (pour le tout début). Donc

est préférable d’éviter

4

Vous pourriez alors simplement faire en sorte que les deux conteneurs partagent le même volume de sauvegarde et éviter de chercher comment configurer les sauvegardes S3.

5

nginx proxy me dit quelque chose, je vais voir comment je m’en sors avec :yum:

6

La meilleure approche, à mon avis, est de minimiser les tracas et les complications. Il suffit de prendre deux droplets et de considérer que c’est réglé.

7

Je l’ai fait avec un seul, mais je n’ai pas pu envoyer l’e-mail de vérification, DigitalOcean + Siteground Email via le port 465 ne fonctionnera pas (2525 fonctionnera) :face_with_symbols_over_mouth:.
Maintenant, je repars de zéro en suivant le guide d’installation, y compris un compte Mailgun :face_vomiting:.