J’essaie de migrer Discourse d’un hébergement personnel vers un serveur Amazon LightSail. J’ai parcouru le forum et lu tous les articles concernant la migration de serveurs et la configuration de Discourse :
Exporter une sauvegarde depuis l’instance Discourse existante (actuellement, la sauvegarde est configurée pour être enregistrée sur S3, mais je comprends qu’il faudra procéder à une sauvegarde manuelle des fichiers)
Importer la sauvegarde dans le nouveau Discourse (manuellement, car il ne pourra pas la récupérer depuis S3, à ma connaissance)
Je suis un peu bloqué sur la manière d’exécuter l’étape 1, étant donné certaines contraintes : je dispose d’un seul nom de domaine que je souhaite conserver pour le nouveau serveur, et je ne veux aucune interruption de service (mon objectif est de terminer la configuration du nouveau serveur, restaurer la sauvegarde, puis enfin modifier l’entrée DNS pour qu’elle pointe vers le nouveau serveur, évitant ainsi toute interruption puisque les deux serveurs fonctionneront simultanément).
Tel que je le comprends, lors de la configuration du nouveau serveur Discourse, je peux copier le fichier app.yml depuis le serveur existant vers le nouveau, puis exécuter discourse-setup. Le problème que je vois ici est que cela utilisera le même nom de domaine que le serveur existant (ce que je souhaite), mais je prévois deux problèmes que j’essaie de résoudre :
Let’s Encrypt ne générera pas de certificat SSL pour le nouveau serveur, car le nom de domaine pointe toujours vers l’ancien serveur.
Sans certificat SSL (la configuration de l’ancien serveur est définie pour n’utiliser que SSL, ce qui sera conservé dans app.yml), le serveur ne démarrera pas.
J’ai essayé de me connecter au serveur Discourse en utilisant une redirection de nom de domaine, mais si l’URL saisie ne correspond pas à la configuration de app.yml, soit NGINX, soit Discourse ne fonctionnera pas, et vous obtiendrez une erreur dans le navigateur lors de la tentative de connexion. Sans interface web, je ne peux pas lancer le processus de restauration.
Comment puis-je donc terminer la configuration du nouveau serveur Discourse en utilisant le app.yml du serveur existant, puis restaurer la sauvegarde avant de basculer le DNS ? Ou existe-t-il une méthode différente et plus simple pour y parvenir ?
Si vous n’utilisez pas le même bucket S3, il existe un paramètre caché qui force le téléchargement des fichiers S3 lors de la sauvegarde. Vous pouvez consulter le fichier de paramètres pour trouver son nom et le définir depuis la console Rails. Un sujet en discute, mais il est peut-être plus simple d’examiner le fichier settings.yml.
Vous n’avez pas besoin d’exécuter discourse-setup ; il suffit de copier app.yml et de reconstruire.
Vous pouvez utiliser rsync pour transférer les certificats Let’s Encrypt. En fait, vous pouvez copier l’intégralité du répertoire /var/discourse (en excluant éventuellement certains journaux et éléments similaires).
L’objectif idéal est de procéder à une « migration telle quelle » (lift and shift), mais ce n’est pas possible avec Amazon Lightsail car on ne peut pas importer une image existante. Donc oui, cela impliquerait d’utiliser exactement le même bucket S3.
Il semble que votre approche soit la plus proche d’une migration telle quelle. Si je comprends bien ce que vous dites, je peux simplement archiver et compresser (tar/gz) tout le dossier /var/discourse du serveur d’origine, le décompresser sur le nouveau serveur, lancer discourse start, puis simplement rediriger le DNS vers le serveur bee. Est-ce tout ? Dois-je reconstruire Discourse sur le nouveau serveur ? Qu’en est-il de Nginx, de Docker et des autres dépendances situées en dehors de ce dossier ?
Merci. Apparemment, le déplacement « lift n shift » n’était pas aussi propre que je le pensais. Il y a quelques vérifications à effectuer avant et après pour garantir une opération de déplacement fluide (Postgres a été mis à niveau de la version 12.0 vers la 13.0, ce qui m’a appris quelques leçons sur le processus de déplacement). Voici un guide étape par étape pour référence future, à l’intention de ceux qui tentent de migrer vers un serveur Amazon LightSail (1 Go de RAM) :
Serveur d’origine
Créer une sauvegarde vers S3
cd /var/discourse
./launcher rebuild # obtenir la dernière version pour faciliter la transition
./launcher cleanup # nettoyer pour supprimer les anciennes données et réduire la taille du paquet
./launcher stop app # ne pas le faire provoque une erreur lors de la reconstruction ultérieure avec Postgres
tar -zcvf /var/discourse discourse.tar.gz
Nouveau serveur Amazon LightSail
Installer l’image Ubuntu 20.20 depuis Amazon (1 Go de RAM)
Créer un swap de 2 Go # ne pas le faire peut entraîner un échec de la reconstruction
Configurer vm.overcommit_memory=1 # ne pas le faire peut provoquer un échec avec Postgres lors de la reconstruction
Transférer discourse.tar.gz via FTPS depuis le serveur d’origine
tar -zxvf discourse.tar.gz -C /
cd /var/discourse
Définir UNICORN_WORKERS dans app.yml à 2 # augmenter cette valeur au-delà de 2 avec 1 Go de RAM risque de provoquer des échanges et un ralentissement dû à une activité disque excessive
./launcher rebuild
Modifier le DNS pour qu’il pointe vers le nouveau serveur Amazon
Existe-t-il un moyen plus simple de migrer des serveurs (lift n shift) sans passer par le processus d’installation de Discourse ?
Voulez-vous dire sans exécuter discourse-setup ou voulez-vous dire sans construire le conteneur nécessaire pour exécuter Discourse ? Si vous parlez de ce dernier, c’est possible en poussant l’ancienne image vers un dépôt que le nouveau serveur pourrait utiliser, mais ce n’est pas quelque chose qu’un novice pourrait facilement gérer.
Votre processus a été compliqué par la mise à niveau vers PG13. Il aurait peut-être été un peu plus simple de construire une nouvelle image à partir de zéro sur le nouveau serveur et de restaurer la sauvegarde depuis l’ancien, mais vous auriez encore quelques détails délicats à régler pour obtenir les certificats Let’s Encrypt sur le nouveau serveur.
Oui, c’est la seule chose qui m’empêchait d’exécuter ./discourse-setup sur le nouveau serveur, puis de restaurer à partir de l’image S3 (et comment procéder sans accès à la console d’administration web, puisque le DNS pointerait encore vers l’ancien serveur et, à ma connaissance, Discourse ne répond pas à une adresse IP dans le navigateur). Comme j’avais un système en production et que je devais basculer le DNS instantanément de l’ancien vers le nouveau système, l’absence de certificats Let’s Encrypt était le seul obstacle pour moi.
S’il existe un moyen de transférer les certificats de l’ancien système vers le nouveau, d’exécuter ./discourse-setup sans aucune erreur liée à Let’s Encrypt et de restaurer à partir de la sauvegarde S3 sans passer par la console web, ce serait une méthode plus simple pour procéder.
Si vous copiez les fichiers yml à l’intérieur de containers, vous n’avez pas besoin de discourse-setup (il peut ajuster les paramètres de mémoire s’ils diffèrent sur le nouveau serveur, mais vous pouvez le faire ensuite). Il vous suffit d’exécuter ./launcher rebuild app.
D’accord, je crois comprendre ce que vous voulez dire, mais pour être certain, laissez-moi reformuler ma compréhension.
Sur le serveur d’origine, la sauvegarde de Discourse vers S3 (qui inclut les paramètres et le contenu du site) était configurée.
En copiant les fichiers yml depuis le dossier containers, toute la configuration du serveur d’origine sera transférée vers le nouveau serveur. Ainsi, sur le nouveau serveur, je n’aurai plus besoin d’exécuter discourse-setup ; il suffira d’exécuter ./launcher rebuild app pour utiliser la configuration du serveur d’origine afin de télécharger la dernière image et de configurer Discourse.
Il reste maintenant deux points à régler :
Comment transférer les certificats Let’s Encrypt (puisque le DNS pointe toujours vers le serveur d’origine, il n’est pas possible de les recréer, et je suppose que cela doit être fait avant d’exécuter ./launcher rebuild app) ?
Comment restaurer Discourse (paramètres + contenu) à partir de la sauvegarde S3 après la reconstruction ? Étant donné que le DNS pointe toujours vers le serveur d’origine, existe-t-il un moyen d’accéder à l’interface d’administration web de Discourse via une adresse IP ou localhost, ou la sauvegarde S3 peut-elle être restaurée directement via la console ?
Merci pour les étapes détaillées, j’ai juste eu à faire quelque chose de similaire, en déménageant vers un nouvel hôte.
Comme le site fonctionnait, je n’ai pas aimé passer par les sauvegardes, j’ai donc suivi les étapes ici.
Cela a presque fonctionné, mais la reconstruction sur le nouvel hôte a échoué.
Il s’est avéré que le mappage UID/GID n’était pas entièrement le même sur les deux hôtes, de sorte que lors du démarrage, Postgres échouerait en raison d’une propriété incorrecte du dossier de données.
Il y a un détail supplémentaire pour le scénario de ce post, c’est que le conteneur n’est pas construit, donc ./launcher enter app ne fonctionne pas à ce stade. Comme la reconstruction prendrait beaucoup de temps, j’ai pu utiliser docker ps pour obtenir le nom du conteneur en cours de construction, puis entrer dans le conteneur :
La reconstruction échoue ensuite (ou vous ne pouvez pas l’arrêter avec CTRL+C). Une fois qu’elle s’est arrêtée, exécutez-la simplement à nouveau, et les permissions sont corrigées :
.