Déplacez votre instance Discourse vers un autre serveur

[Discourse]

Ceci est un guide pour déplacer votre instance Discourse d’un serveur à un autre, y compris tous les paramètres et données. Ce guide s’applique aux instances Discourse auto-hébergées utilisant Docker.

Niveau d’utilisateur requis : Administrateur système

Cette procédure implique des changements de domaine et de DNS. Assurez-vous d’avoir accès aux serveurs source et de destination.

Ce guide vous explique le processus de migration de votre instance Discourse d’un serveur à un autre, en veillant à ce que vos données, paramètres et configurations soient préservés.

Avertissement ajouté par @pfaffman 2025-09-12T05:00:00Z.

Ces instructions ne fonctionnent pas bien maintenant car vous utilisez désormais https et Let’s Encrypt, ce qui nécessite que le nouveau serveur ait le DNS pointé vers lui afin qu’il puisse demander des clés. Ce que je recommande, c’est de suivre Déplacer un site Discourse vers un autre VPS avec rsync (en utilisant peut-être --exclude postgres* puis en sauvegardant et restaurant la base de données depuis la ligne de commande.) C’est astucieux car si vous savez comment faire, vous pouvez ajuster votre DNS local pour qu’il pointe vers le nouveau serveur afin de tester son fonctionnement pendant que le reste d’Internet voit toujours l’ancien site.

Sommaire

Vous effectuerez les étapes clés suivantes dans ce guide :

1. Sauvegardez votre instance Discourse actuelle (serveur source).
2. Transférez le fichier de sauvegarde vers votre instance Discourse cible (serveur de destination).
3. Restaurez la sauvegarde sur le serveur de destination.
4. Mettez à jour les paramètres DNS (si applicable).

Ajustement des paramètres DNS (si nécessaire)

Si vous utilisez le même domaine pour le nouveau serveur, réduisez le TTL (temps de vie) de votre entrée DNS à l’avance. Cela garantit un temps d’arrêt minimal pendant la propagation des enregistrements DNS mis à jour. Si vous utiliserez un nouveau domaine, cette étape peut être ignorée.

Connexion et préparation du serveur source

1. Connectez-vous à votre instance Discourse source avec un compte disposant des droits d’administrateur.
2. Assurez-vous que les serveurs source et de destination utilisent :
   • La même version de Discourse.
   • Le même ensemble de plugins.
3. Mettez à niveau la version de Discourse sur les deux serveurs en visitant /admin/upgrade.

Évitez de restaurer une sauvegarde plus récente sur une ancienne version de Discourse, ou des versions incompatibles de PostgreSQL, car cela pourrait entraîner des erreurs.

Création et téléchargement de la sauvegarde

1. Accédez à /admin/backups sur votre instance Discourse source.
2. Cliquez sur le bouton Backup (Sauvegarder) pour créer une sauvegarde :
   
   
3. Lorsque vous êtes invité, confirmez en cliquant sur Yes (Oui).
4. Une fois la sauvegarde terminée, allez dans l’onglet Backup files (Fichiers de sauvegarde), et localisez la sauvegarde nouvellement créée.
5. Cliquez sur Download (Télécharger) pour recevoir un e-mail avec un lien de téléchargement. Cliquez sur le lien dans l’e-mail pour enregistrer le fichier de sauvegarde localement.
   
   

Avant de continuer, examinez votre fichier app.yml pour vous assurer que tous les paramètres facultatifs, tels que les configurations CDN, les plugins installés ou la prise en charge HTTPS, sont cohérents entre les serveurs source et de destination.

Restauration de la sauvegarde sur le serveur de destination

Pour restaurer la sauvegarde via la ligne de commande, consultez la documentation pertinente.

1. Connectez-vous en tant qu’administrateur à votre instance Discourse de destination.
2. Accédez à /admin/backups/settings, et activez le paramètre allow restore (autoriser la restauration).
3. Allez à /admin/backups et cliquez sur l’onglet Backup files (Fichiers de sauvegarde). Téléchargez le fichier de sauvegarde que vous avez téléchargé précédemment en cliquant sur le bouton Upload (Téléverser) :
   
   
4. Une fois le téléchargement terminé, cliquez sur le menu ⋮ (plus d’options) à côté de la sauvegarde téléchargée, puis cliquez sur Restore (Restaurer) :
   
   
5. Confirmez en cliquant sur Yes (Oui) lorsque vous y êtes invité.

Le processus de restauration va commencer. Cela peut prendre un certain temps en fonction de la taille de votre base de données. Une fois le processus terminé, vous serez automatiquement déconnecté.

Finalisation et connexion

1. Connectez-vous à votre instance Discourse de destination avec vos identifiants d’administrateur.
2. Si le site a été sauvegardé en utilisant HTTPS, assurez-vous que HTTPS est activé sur le nouveau serveur. Si ce n’est pas correctement configuré, utilisez la console Rails pour désactiver temporairement le paramètre « force https » (forcer https).
3. Réactivez toutes les configurations facultatives en modifiant le fichier app.yml et en reconstruisant votre instance. Cela peut inclure :
   • Activation du support CDN.
   • Installation de plugins supplémentaires.
   • Configuration des paramètres HTTPS.

Problèmes courants et solutions

Le fichier de sauvegarde ne se restaure pas

• Vérifiez que les versions de Discourse et de PostgreSQL correspondent entre les serveurs source et de destination.

Impossible de se connecter après la restauration (avec HTTPS activé)

• Utilisez la console Rails pour désactiver temporairement force_https en exécutant :

  SiteSetting.force_https = false
  

[bayardo.rivas]

Ce guide est-il toujours valide 11 ans plus tard ?

Je fais fonctionner mon Discourse sur Ubuntu et je souhaite mettre à niveau le système d’exploitation de 20.04 LTS vers 24.04 LTS avec le moins de temps d’arrêt possible. Il est sur AWS.

[merefield (Robert)]

@bayardo.rivas

toujours valable 11 ans plus tard ?

C’est un peu pessimiste

@Discourse

Dernière modification par @SaraDev 2024-11-21T00:47:52Z

[Jagster (Jakke Flemming)]

Ou est-ce… réaliste ? C’est-à-dire à cause de ce genre de choses :

@Discourse

Vérifiez que les versions de Discourse et PostgreSQL correspondent entre les serveurs source et destination.

[bayardo.rivas]

Il me semble légitime de s’inquiéter et de demander si cela correspond à la documentation. J’ai récemment mis à niveau mon forum Discourse et j’ai rencontré des problèmes qui ont fait planter le système, alors que je ne faisais qu’une mise à niveau d’une version à la dernière. Il s’agissait apparemment de nouveaux plugins qui font maintenant partie du système de base de Discourse.

Je pense que passer à une instance différente avec un système d’exploitation plus récent est un changement majeur. Si je dois essayer cette approche, j’aimerais avoir autant de retours que possible.

J’apprécie tout commentaire utile. Merci.

[merefield (Robert)]

Ce guide sort un peu du cadre de ce changement spécifique.

[bayardo.rivas]

Merci pour vos commentaires.

[Gunnar (Gunnar Helliesen)]

Si vous êtes toujours sur Ubuntu 20.04, utilisez-vous Docker et aufs ?

Si c’est le cas, vous devriez lire ceci avant de continuer :

Docker Upgrade Removed AUFS Storage Driver, Killed Discourse

I run a Discourse forum installation on Ubuntu 20.04.6 LTS. The Docker image uses AUFS for storage. Today, I installed upgrades via sudo apt upgrade. Now the Discourse forum is no longer accessible, and it appears to be because a Docker upgrade removed the AUFS storage driver. I see plenty of guides to configuring Docker to use Overlay2 instead, but I don’t see any guidance on how to migrate my existing Discourse installation to use Overlay2, especially now that I can’t start Docker to mount m…

[pfaffman (Jay Pfaffman)]

Je crois bien, bien que je n’aie pas regardé de très près. Non. Le nouveau site échouera à obtenir des clés de let’s encrypt si le DNS ne pointe pas vers lui. Vous devrez donc sauvegarder, transférer la sauvegarde, basculer le DNS vers le nouveau serveur, puis reconstruire.

Si vous souhaitez minimiser les interruptions de service, je vous recommande Déplacer un site Discourse vers un autre VPS avec rsync. Cela copie vos clés SSL afin que le nouveau serveur soit prêt lorsque vous effectuerez la reconstruction.

À moins que vous n’ayez déjà mis à niveau vers Postgres 15 (et peut-être même dans ce cas), ce que je recommande (ce que je fais) est --exclude postgres*, reconstruire, puis sauvegarder le site principal et restaurer cette sauvegarde sur le nouveau serveur. Une fois celle-ci restaurée, basculez le DNS. Les instructions rsync vous demandent d’arrêter la base de données afin que vous puissiez copier les fichiers bruts de la base de données. Il y a des cas où cela ne fonctionnera pas très bien, donc la plupart du temps je fais une sauvegarde de la base de données uniquement et je la restaure.

EDIT : J’ai ajouté cela à l’OP.

@Discourse

Avertissement ajouté par @pfaffman 2025-09-12T05:00:00Z.

Ces instructions ne fonctionnent plus très bien car vous utilisez maintenant https et let’s encrypt, qui nécessitent que le nouveau serveur ait le DNS pointant vers lui afin qu’il puisse demander des clés. Ce que je recommande est de suivre Déplacer un site Discourse vers un autre VPS avec rsync (peut-être en utilisant --exclude postgres* puis en sauvegardant et en restaurant la base de données depuis la ligne de commande.) C’est astucieux car si vous savez comment faire, vous pouvez modifier votre DNS local pour qu’il pointe vers le nouveau serveur afin que vous puissiez tester qu’il fonctionne pendant que le reste d’Internet voit toujours l’ancien site.

[nathank (Nathan Kershaw)]

Merci Jay ! Je me suis demandé pourquoi j’avais eu un peu de mal avec tout le truc URL / DNS / LetsEncrypt dans le passé (récent) en essayant de suivre les instructions dans le OP.

J’ai fini par y arriver en utilisant un sous-domaine pour le nouveau site, en m’assurant que mon site restauré sur le nouveau serveur fonctionnait, puis en effectuant un rapide changement DNS / URL. Mais tout cela était un peu bancal / douloureux (surtout le jeu du taupe-et-marteau de remap après !).

Je comprends maintenant pourquoi j’ai dû faire tout cela. Et c’est bien de savoir que rsync peut contourner certains points douloureux.

Je pense que des instructions claires ici aideraient vraiment les autres, car c’est un peu déroutant pour le moment - et je ne suis pas sûr de la meilleure façon de le faire à l’avenir. Votre avertissement pourrait-il être intégré à l’ensemble du OP en tant que réécriture (peut-être par @SaraDev ?).

[pfaffman (Jay Pfaffman)]

@nathank

Je me suis demandé pourquoi j’étais un peu bloqué sur la question des URL / DNS / LetsEncrypt dans le passé (récent) en essayant de suivre les instructions de l’OP.

C’est pourquoi j’ai suggéré de ne pas suivre ces instructions.

@nathank

Je pense que des instructions claires ici aideraient vraiment les autres, car c’est un peu déroutant pour le moment.

Je pense qu’ignorer ou supprimer ces instructions et suivre le sujet rsync que j’ai lié aiderait les gens.

Est-ce que je rate quelque chose ?

[Ethsim2 (Ethan)]

Je partage ici un cas particulier de migration auquel je me suis heurté, au cas où cela aiderait quelqu’un d’autre.

J’ai rencontré un cas limite avec Let’s Encrypt/SSL en déplaçant une instance Discourse autonome vers un nouveau VPS, j’ai donc rédigé le diagnostic exact et les étapes de récupération, au cas où ils seraient utiles à d’autres personnes suivant ce guide.

Dans mon cas, nginx à l’intérieur de app ne démarrait pas car les deux fichiers .cer dans /var/discourse/shared/standalone/ssl/ étaient devenus des fichiers de zéro octet :

PEM_read_bio_X509_AUX() failed

La reconstruction a tenté de nouveau l’émission du certificat, et après plusieurs tentatives, j’ai atteint la limite de taux de certificats de Let’s Encrypt. Copier les fichiers de certificat encore valides depuis l’ancien serveur seul n’était pas suffisant, car le démarrage de app les remplaçait à nouveau par des fichiers de zéro octet.

Ce qui a finalement résolu le problème, c’est d’arrêter app et de copier à la fois le répertoire fonctionnel /var/discourse/shared/standalone/ssl/ et l’état correspondant /var/discourse/shared/standalone/letsencrypt/ depuis l’ancien serveur, puis de redémarrer le conteneur.

J’ai documenté la séquence complète ici :

server_migration_diagnosing_standard_ssl.md

Il s’agit de notes de diagnostic/récupération issues de cette migration particulière, et non d’un remplacement de la documentation officielle sur la migration ou HTTPS.

Il existe également un ancien sujet Meta couvrant le mode de défaillance lié aux fichiers .cer vides :

Let's Encrypt : fichiers *.cer vides

Je ne parviens pas à me connecter à une nouvelle installation standard de 30 minutes (discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub). AWS Lightsail, 2 Go de mémoire, Ubuntu 18.04 LTS x64 avec le port :443 ouvert. Le problème est que les fichiers *.cer de Let’s Encrypt sont vides. Pourquoi ? Journaux nginx root:/var/log/nginx# ls -ltrh -rw-r–r-- 1 www-data www-data 0 Dec 6 05:45 error.letsencrypt.log -rw-r–r-- 1 www-data www-data 0 Dec 6 05:45 access.letsencr…