J’ai remarqué qu’en passant en mode multi-conteneurs, la restauration de la base de données entraînait un temps d’arrêt inattendu du site (pendant le chargement de la sauvegarde dans la base de données) :
J’ai donc fait quelques recherches dans postgres.template.yml et constaté que app.yml ainsi que le chemin vers le conteneur autonome standalone et l’espace partagé sont codés en dur dans ce modèle.
Je ne suis absolument pas un expert de ces fichiers (pour l’instant), et comme le code contient principalement des “échos” informatifs, le contenu semble plus “informatif pour l’utilisateur” que problématique :
Exemples tirés du modèle
echo Exécutez : "./launcher stop app"
echo Exécutez : "sudo mv /var/discourse/shared/standalone/postgres_data /var/discourse/shared/standalone/postgres_data_old"
echo Exécutez : "./launcher rebuild app"
echo
echo Exécutez : "./launcher enter app"
echo Exécutez : "cd /shared/postgres_backup"
echo Exécutez : "sv stop unicorn"
echo Exécutez : "sudo -iu postgres dropdb discourse"
echo Exécutez : "sudo -iu postgres createdb discourse"
echo Exécutez : "sudo -iu postgres psql discourse < backup.db"
echo Exécutez : "exit"
echo Exécutez : "./launcher rebuild app"
exit 1
if [ "$PG_MAJOR_OLD" = "9.5" ]; then
echo 'Dans containers/app.yml : remplacez "templates/postgres.template.yml" par "templates/postgres.9.5.template.yml"'
echo
fi
etc.
Dans l’ensemble, tout semble “informatif et non problématique, je suppose”.
Ce n’est probablement pas important, mais comme les divers tutoriels sur le site mentionnent ce modèle ainsi que le renommage du conteneur de données en “data” et du conteneur web en “web-only”, par exemple, j’ai pensé qu’il valait la peine de le signaler.
À titre d’information uniquement, peut-être pour un examen plus approfondi dans un futur lointain …