Bonjour,
nous utilisons actuellement la version 2.6.0.beta1 et souhaitons passer à la dernière version stable. Comme la version 2.6.0 est ancienne, y a-t-il des choses dont nous devrions nous inquiéter ? Bien sûr, nous ferons une sauvegarde d’abord, mais peut-être avez-vous quelques conseils 
Il y a peu de chances que le système d’exploitation de votre VM soit pris en charge. Je vous recommande de déplacer un site Discourse vers un autre VPS avec rsync, en omettant les fichiers de base de données, de construire le nouveau conteneur, puis de restaurer une sauvegarde du site existant.
En fait, je vous recommanderais probablement d’exécuter une nouvelle commande discourse-setup plutôt que d’utiliser votre fichier app.yml existant et de copier les paramètres SMTP et autres. Il y a eu quelques changements là aussi.
En faisant semblant une minute que vous effectuez des mises à niveau du système d’exploitation sur la VM pour la mettre à jour, il y a également eu au moins deux mises à niveau de postgres depuis lors. Essayer de mettre à niveau sur place ne se passera pas bien. Si vous essayez et que cela échoue, je ne dirai pas « je vous l’avais bien dit », mais je ne dirai rien d’autre non plus.
Merci beaucoup pour votre réponse. Comme nous devons également passer à un nouveau serveur, le plan initial était de migrer l’ancien discourse vers le nouveau serveur, puis de procéder à la mise à jour.
Recommanderiez-vous toujours d’installer un nouveau discourse ?
Le passage au nouveau serveur est beaucoup plus sûr car vous n’avez pas besoin de modifier l’ancien serveur tant que le nouveau ne fonctionne pas !
Ce que je ferais, c’est suivre le guide rsync, en excluant postgres_*. Ensuite, je renommerais app.yml et exécuterais ./discourse-setup --skip-connection-test (car le DNS ne pointera pas encore vers le nouveau serveur). Puis je restaurerais la sauvegarde. Vous pouvez (généralement) tester que le nouveau serveur fonctionne en modifiant votre DNS local pour qu’il pointe vers celui-ci, mais dans le pire des cas, vous changez simplement le DNS et si c’est un désastre, vous remettez le DNS en place. (Si c’est Digital Ocean ou autre chose avec une IP flottante qui peut pointer vers plusieurs VM, vous pouvez simplement les rediriger et ne pas vous soucier du DNS.)
Je l’ai fait une dizaine de fois ces derniers mois. Si vous préférez ne pas le faire vous-même, je suis disponible.
Salut Jay,
Je t’ai contacté par message privé.
OK, c’est quelque chose que je me suis toujours demandé. Pas besoin de domaine de staging ? Rien n’est réécrit (deux fois) parce que le domaine change (deux fois) ?
Si vous copiez les répertoires ssl et let’s encrypt, vous avez les certificats pour le nom d’hôte existant. Le serveur est prêt à servir ce domaine, mais le DNS n’y pointe pas, donc il ne le peut pas.
Je copie généralement les fichiers yml existants, mais pour ce très vieux site, en obtenir un nouveau n’est pas une mauvaise idée, et dans ce cas, je pense avoir appris qu’il y avait eu des modifications étranges qu’il serait bon de laisser derrière moi.
MAIS, si vous êtes malin, vous pouvez tromper votre navigateur pour qu’il y aille et constatez que tout va bien, puis vous pouvez changer le DNS pour que tout le monde le voie. (et espérez vous souvenir de désactiver cette astuce dans votre navigateur afin de ne pas être très confus dans le futur.)