N'oubliez pas d'exécuter docker remove app lors de la réinstallation de discourse

Soutien
1

J’utilise Discourse depuis plusieurs années maintenant. Je mets en place une nouvelle instance tous les 6 mois. Ma configuration inclut Docker et un proxy basé sur Nginx, donc elle est peut-être un peu non standard. Pour cette raison, je n’utilise pas discourse-setup.

Tous les 6 mois, lorsque je répète ce processus, après avoir recloné une copie fraîche de Discourse depuis son git et exécuté ./launcher bootstrap app, le conteneur ne démarre pas. Le journal indique :

anacron: Can't chdir to /var/spool/anacron: No such file or directory
run-parts: /etc/runit/1.d/anacron exited with return code 1
run-parts: executing /etc/runit/1.d/00-ensure-links
run-parts: executing /etc/runit/1.d/00-fix-var-logs
run-parts: executing /etc/runit/1.d/01-cleanup-web-pids
run-parts: executing /etc/runit/1.d/anacron
anacron: Can't chdir to /var/spool/anacron: No such file or directory

ad infinitum.

Je fais ensuite un certain nombre d’étapes pour re-bootstrap, redémarrer, supprimer des plugins, les rajouter, etc., jusqu’à ce que cela fonctionne enfin, sans jamais savoir ce qui a finalement fonctionné. 6 mois plus tard, la même chose se reproduit. Je travaille juste pour le corriger, et il n’est pas clair quelle étape parmi les nombreuses que je prends a finalement fonctionné.

Cette fois, cependant, je pense avoir enfin trouvé le problème, et c’est ceci : apparemment, ./launcher start app redémarre d’anciennes instances de conteneurs appelées app, même lorsque Discourse a été recloné et re-bootstrapé.

L’étape manquante est docker remove app. En résumé :

./launcher stop app
docker remove app
... maintenant recloner, rebootstrap et launcher start app fonctionne

Mon erreur a été de m’attendre à ce qu’après avoir exécuté ./launcher bootstrap app, le prochain ./launcher start app démarre la nouvelle image de conteneur, mais ce ne semble pas être le cas. Naturellement, les choses tournent mal avec l’ancienne, car le chemin /var/discourse/shared a été réinitialisé.

Je laisse cela ici au cas où d’autres rechercheraient les mêmes messages d’erreur de journal.

En tant qu’amélioration possible, il serait bien que le conteneur détecte que son répertoire /var/discourse/shared a changé.

2 « J'aime »
2

Si vous voulez exécuter bootstrap, la « méthode discourse » est :

./launcher bootstrap app
./launcher destroy app
./launcher start app

Mais si vous n’avez qu’un seul conteneur, il n’y a aucune raison de ne pas simplement faire :

./launcher rebuild app

comme le disent pratiquement tous les exemples. Cela arrête le conteneur en cours d’exécution, crée un nouveau conteneur et le démarre. Si le bootstrap échoue pour une raison quelconque, vous pouvez (généralement) redémarrer l’ancien avec ./launcher start app (comme vous l’avez décrit).

3

Je pense que je vois le problème, et il est lié à la confusion habituelle entre « instance de conteneur » et « image de conteneur ».

Si vous regardez 10. Maintenance post-installation, par exemple, il est indiqué :

Usage: launcher COMMAND CONFIG [--skip-prereqs] [--docker-args STRING]
Commands:
    start:      Démarrer/initialiser un conteneur
    stop:       Arrêter un conteneur en cours d'exécution
    restart:    Redémarrer un conteneur
    destroy:    Arrêter et supprimer un conteneur
    enter:      Utiliser nsenter pour obtenir un shell dans un conteneur
    logs:       Afficher les logs Docker pour un conteneur
    bootstrap:  Initialiser un conteneur pour la configuration à partir d'un modèle
    rebuild:    Reconstruire un conteneur (détruire l'ancien, initialiser, démarrer le nouveau)
    cleanup:    Supprimer tous les conteneurs arrêtés depuis plus de 24 heures

Dans la plupart des utilisations du mot « conteneur » dans cette aide, il fait référence à une instance de conteneur. Sauf dans bootstrap, où il fait référence à une image. (./launcher bootstrap utilise docker commit pour créer une nouvelle image à partir de laquelle des instances de conteneurs ultérieures peuvent être lancées.) Je pense que c’était inattendu (et j’ai naïvement supposé que cela affecterait également l’instance app actuelle.)

Dans rebuild, le mot conteneur fait référence à la fois aux images de conteneurs et aux instances, car il implique un ensemble d’opérations qui affectent à la fois les instances de conteneurs et les images de conteneurs.

Et il n’est pas clair à quoi il fait référence dans cleanup : seules les instances seront-elles supprimées, ou l’image initialisée également ?

1 « J'aime »