J’ai appris quelque chose qui pourrait aider d’autres personnes.
Contexte : Comme détaillé ailleurs, mon installation Discourse était hébergée sur un VPS dont le disque était trop petit pour terminer une mise à niveau. Au début, j’ai cliqué sur « Mettre à niveau » dans le panneau de configuration d’administration. La mise à niveau a échoué et l’interface graphique n’a plus jamais fonctionné. Après cela, je me suis connecté à la console de mon VPS et j’ai exécuté la célèbre commande ./launcher rebuild app. Celle-ci ne s’est pas non plus terminée : j’avais décidément manqué d’espace disque. Pour obtenir plus d’espace et rester dans mon budget, j’ai décidé de déplacer toute mon installation vers un nouveau VPS auprès d’une autre société d’hébergement. Sauvegarder les précieuses données du site était une priorité absolue.
Échecs : Les deux méthodes les plus évidentes pour effectuer une sauvegarde n’ont pas fonctionné :
Ma tentative initiale de mise à niveau a cassé l’interface graphique Web, il n’y avait donc aucun moyen d’accéder au panneau de configuration d’administration et d’en lancer une sauvegarde ; et
Essayer d’entrer dans le conteneur Docker et d’y exécuter des commandes shell n’a pas non plus fonctionné. La commande recommandée pour cela est /var/discourse/launcher enter app. Mais, du moins dans mon cas, le script launcher tentait de reconstruire l’application avant de me laisser y entrer, et les reconstructions échouaient systématiquement, donc cette commande ne m’a même jamais donné un conteneur, encore moins un shell à l’intérieur.
Succès : J’étais sur le point d’abandonner quand j’ai eu une agréable surprise. En travaillant sur la ligne de commande de ma petite VM, j’ai tapé docker ps et j’ai appris qu’il y avait un conteneur actif nommé app. Et Docker a un moyen direct d’entrer dans un conteneur en cours d’exécution : la commande est docker exec -it app bash.
À l’intérieur du conteneur, j’ai pu progresser : j’ai émis la commande discourse backup, j’ai attendu quelques minutes, puis j’ai copié le fichier <backup>.tar.gz dans un nouvel emplacement sûr. Avec une sauvegarde actuelle en main, il a été possible de terminer la migration de mon installation vers son nouveau domicile. (Il existe d’autres fils de discussion sur ces forums expliquant comment faire cela.)
Le point clé ici est que la commande docker ci-dessus pour entrer dans le conteneur a fonctionné, même lorsque la commande spécifique à Discourse ./launcher n’a pas fonctionné.
Merci aux inventeurs et aux mainteneurs de ce excellent produit.
Pendant les jours où j’essayais de faire fonctionner ma configuration d’origine, j’ai pensé avoir fait tout ce qui était possible pour récupérer de l’espace, y compris certainement ./launcher cleanup, mais aussi beaucoup plus… suppression des anciens noyaux, nettoyage du cache apt, abandon des logiciels non essentiels, etc., etc.
Après m’être engagé à déplacer tout mon site et avoir consacré beaucoup de temps au processus, je me suis demandé si j’aurais pu faire plus… mais à ce moment-là, j’avais perdu l’envie d’approfondir. (cf. « sophisme des coûts irrécupérables ».) Pour être précis, le VPS que je suis sur le point d’abandonner avait une taille de disque nominale de 25G. Environ 19G de cela était dédié au répertoire /var/lib/docker/overlay2. Et les seuls conteneurs docker que j’utilisais étaient Discourse et son récepteur de courrier associé. L’expérience suggère que Discourse, aussi puissant soit-il, devrait pouvoir fonctionner avec beaucoup moins de 19G sur le disque. Mais les recherches sur Internet semblaient indiquer que faire des modifications à l’intérieur du répertoire overlay2 était dangereux, donc je me suis senti bloqué à ce moment-là.
Dans ma nouvelle configuration, le répertoire /var/lib/docker/overlay2 occupe 13G. Toujours énorme.
J’ai choisi Discourse pour gérer les forums sur mon site de loisirs à petite échelle dans l’espoir que cela « fonctionnerait tout simplement » - c’est-à-dire que ce serait super simple à administrer sans avoir à apprendre un tas de nouvelles choses. Cela semble être en grande partie correct, si l’on dispose de ressources suffisantes (excessives ?).
Mon nouveau plan est d’espérer aveuglément que le répertoire overlay2 ne grossira pas avec le temps et n’inondera pas le disque de 50G de mon nouveau VPS. Si vous (ou quelqu’un d’autre) savez comment maîtriser la taille du duo dynamique docker et Discourse, j’aimerais beaucoup le savoir. Ce serait une belle conclusion au reste de l’apprentissage que j’ai fait ces derniers jours. Merci encore.
Ravi que vous ayez pu vous sauver vous-même. J’administre deux petits forums, l’un sur le stockage 20G et l’autre sur le 25G. Je dois parfois consacrer beaucoup de temps et d’ingéniosité pour que cela fonctionne. Mais j’ai aussi l’impression de continuer à utiliser (et à publier sur) le même ensemble de tactiques. Voir ci-dessous.
Le développement de Discourse est optimisé pour des choses autres que fonctionner sur du matériel à coût minimal - bien qu’il parvienne tout juste à continuer à fonctionner pour moi dans mon environnement contraint. Puissent les choses continuer ainsi.
La clé pour travailler dans des configurations de stockage limitées est de mesurer ce qui se passe - trop souvent, je vois des gens deviner ce qui pourrait se passer. Mon approche commencera toujours par
Pour en savoir plus, vous pouvez peut-être rechercher mes publications sur prune et journalctl et kernel.