Il existe plusieurs astuces pour vous aider lors de la configuration d’un serveur de staging.
Qu’est-ce qu’un serveur de staging ?
Un serveur de staging est essentiellement un clone d’un site de production. Il réside également sur un serveur et fonctionne de manière identique. Il s’exécute dans un conteneur Docker, tout comme un site Discourse normal.
Il existe pour vous donner un endroit où essayer des choses risquées, ou pour tester des choses que vous ne pouvez pas facilement cacher à vos utilisateurs. Il est très utile pour tester des publicités en utilisant le lien Discourse Advertising Plugin (Ads), ou si vous voulez faire quelque chose de fantaisiste comme une importation ou une fusion de forum.
Ceci contraste avec un serveur de développement, qui s’exécute généralement dans un endroit facilement accessible (et isolé) afin qu’un développeur puisse modifier le code en toute sécurité.
De quoi ai-je besoin ?
-
Tout ce dont vous avez besoin pour une installation standard auto-hébergée
-
Si vous avez configuré des sauvegardes S3, votre vie sera beaucoup plus facile
- sinon, vous aurez besoin d’un moyen de déplacer de gros fichiers vers et depuis un serveur via SSH
Étapes
Configurez votre serveur comme vous le souhaitez
Généralement sur un serveur Ubuntu virtuel hébergé sur Digital Ocean, mais vous pouvez utiliser ce avec quoi vous êtes à l’aise.
Installez Discourse
Via ce guide (ou peut-être via dashboard.literatecomputing.com). Je recommande d’utiliser des identifiants d’e-mail “bidon” (vous n’avez pas besoin et ne voulez pas que l’e-mail fonctionne).
discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub
Confirmez que votre installation fonctionne :
Créez un compte administrateur (si nécessaire)
Créez-vous un compte administrateur depuis la ligne de commande. Cela évite d’avoir à vous authentifier par e-mail.
./launcher enter app
rake admin:create
Ce n’est pas strictement nécessaire, sauf pour tester l’installation, car vous pouvez restaurer à partir d’une sauvegarde depuis la ligne de commande.
Modifiez app.yml et ajoutez quelques ajustements
-
Vous pourriez vouloir faire une copie de l’app.yml original (j’appelle la mienne
app.vanilla.yml) à laquelle vous pourrez revenir si vous faites des erreurs. -
En bas de la section
env, ajoutez ces lignes :## Paramètres spécifiques au serveur de staging DISCOURSE_AUTOMATIC_BACKUPS_ENABLED: false DISCOURSE_LOGIN_REQUIRED: true DISCOURSE_DISABLE_EMAILS: 'yes' DISCOURSE_S3_DISABLE_CLEANUP: true DISCOURSE_ALLOW_RESTORE: true -
Si vous avez configuré des sauvegardes S3 (ou similaires), ajoutez-les également (avec vos paramètres du site principal)
## Configuration S3 DISCOURSE_S3_ACCESS_KEY_ID: 'votre_clé' DISCOURSE_S3_SECRET_ACCESS_KEY: 'votre_secret' DISCOURSE_BACKUP_LOCATION: 's3' DISCOURSE_S3_BACKUP_BUCKET: 'votre_emplacement_de_sauvegardes' DISCOURSE_S3_REGION: 'votre_région_s3' DISCOURSE_S3_DISABLE_CLEANUP: trueet si vous faites également des téléchargements S3 :
DISCOURSE_ENABLE_S3_UPLOADS: true DISCOURSE_S3_UPLOAD_BUCKET: 'votre_emplacement_de_téléchargements' -
Vous pourriez vouloir ajouter les mêmes plugins que ceux de votre site de production pendant que vous y êtes.
-
Effectuez une reconstruction
./launcher rebuild app
Gestion du serveur de staging
Vous avez maintenant un serveur de staging connecté à vos sauvegardes S3 (mais qui ne les écrasera pas), facile à restaurer, et qui ne peut en aucun cas envoyer d’e-mails à qui que ce soit. Parfait !
Vous pouvez restaurer une nouvelle sauvegarde sur le serveur de staging et vous amuser. Si vous n’aimez pas ce que vous avez, il vous suffit de le restaurer à nouveau.
L’arrêter ou l’allumer
Si vous laissez votre serveur de staging “allumé” pendant de longues périodes, vous risquez qu’il soit indexé par Google, et que vos utilisateurs s’y connectent accidentellement. Comme leurs identifiants sont un clone de votre site de production, c’est très possible.
Un moyen simple d’atténuer ces deux problèmes est simplement d’arrêter Discourse :
./launcher stop app
Et pour le rallumer afin de pouvoir l’utiliser :
./launcher restart app
Mises à jour
Vous devrez vous assurer de mettre à jour/reconstruire à la fois le serveur de staging et votre site de production en même temps si vous voulez vous assurer que les choses restent alignées du point de vue des plugins et du code. Il en va de même pour les modifications de app.yml.
Si vous n’utilisez pas S3, vous devrez déplacer manuellement les sauvegardes entre les serveurs. Et elles sont volumineuses !
Alimenter un serveur de test
Si vous voulez un serveur de staging, vous devriez le peupler avec vos données réelles de votre forum réel via une Restauration. Parfois, ce sont vos données spécifiques qui causent le problème, et tester votre forum avec un autre ensemble de données peut vous donner un faux sentiment de sécurité.
Si ce que vous voulez est un serveur de test pour voir à quoi ressemble Discourse, alors vous pourriez vouloir vérifier les choses avec de fausses données, et si c’est le cas, vous pouvez faire ceci :
./launcher enter app
ALLOW_DEV_POPULATE=1 bundle install
ALLOW_DEV_POPULATE=1 rake dev:populate
Cela alimentera votre forum avec de fausses données afin que vous puissiez voir à quoi ressemblent les choses avec les thèmes et plugins que vous souhaitez. Si vous n’avez pas encore lancé votre forum, cela vous donnera une idée de ce à quoi il est probable qu’il ressemble.
Gestion de l’authentification à deux facteurs
Bien que le nom d’utilisateur / mot de passe de votre compte principal fonctionne également très bien sur le site de staging, ce n’est pas aussi simple avec la 2FA. En cas de problème, désactivez la 2FA :
./launcher enter app
rake users:disable_2fa[<NOM_UTILISATEUR>]
, mais serait-ce une bonne occasion d’utiliser 
