Pour autant que je puisse en juger, ce guide consiste en beaucoup de mots autour de :
- une sauvegarde
- la création d’une nouvelle instance Discourse complètement nouvelle, avec plus de mots mais les mêmes résultats que l’exécution simple de
discourse_setup 2container - une restauration
Pourquoi ne pas simplement déplacer ou copier /var/discourse/shared/standalone/{postgres,redis}* vers /var/discourse/shared/data après un arrêt propre et avant de démarrer deux nouveaux conteneurs à partir de fichiers containers/*.yml distincts ? Une sauvegarde/restauration semble être une méthode très lourde pour déplacer toutes ces données, ajoutant inutilement des heures au processus. Est-ce que je manque quelque chose d’évident ici ?
Je viens de tester ce processus sur mon Discourse de test, et j’ai également séparé Redis tant que j’y étais, juste pour m’assurer de couvrir tous les aspects. Édito : J’ai déplacé la description vers un nouveau sujet :
Le site semble fonctionner correctement sans cycle de sauvegarde/restauration. Y a-t-il quelque chose de non évident que je devrais vérifier ?
J’ai effectué le même processus pour un Discourse relativement important et cela fonctionne bien. J’ai décidé qu’en production, je nommerais mon nouveau conteneur web_only app afin que mes doigts continuent naturellement à faire ce qu’il faut. Après avoir écrit les nouveaux fichiers container/*.yml, le temps d’arrêt pour toute la migration a été de 12 minutes, bien plus rapide que ce que cela aurait été avec un cycle de sauvegarde/restauration.