Un administrateur de Discourse auto-hébergé depuis 10 ans demande : pourquoi pas de nettoyage du lanceur dans le cadre de la reconstruction ?

Installation
1

Salut à tous. Je m’appelle Lee, et j’héberge Discourse moi-même de manière intermittente depuis 2013. Je me souviens avoir dû me débattre avec rbenv pour commencer. Je me souviens avoir dû compiler nginx avec Phusion Passenger pour que les choses fonctionnent. Je me souviens avoir discuté avec @sam il y a probablement dix ans que passer à Docker revenait à capituler devant la faiblesse des développeurs qui disent « ça marche sur ma machine et avec mon cauchemar de dotfiles » (et j’avais complètement tort !). Je me souviens de la première fois où j’ai entendu l’expression « bike-shedding ». Pour citer l’homme, je me souviens de tout.

Après plusieurs années d’absence, j’ai eu l’occasion de revenir à l’auto-hébergement de Discourse pour remplacer les commentaires natifs de Wordpress sur un site météo de la région de Houston qui reçoit généralement environ 10 000 pages vues par jour, mais qui peut atteindre environ 2 millions de pages vues par jour pour environ 1 million de visiteurs uniques pendant les ouragans. Nous avons lutté pendant des années avec les commentaires natifs de Wordpress, mais depuis mercredi dernier, nous sommes en ligne avec Discourse auto-hébergé. (Et sur Graviton3, rien de moins ! Sérieusement, ça fonctionne et c’est génial.)

Voici le point que j’essaie d’aborder : nous sommes en 2025, et en tant qu’auto-hébergeur, je dois toujours gérer manuellement mon espace d’images Docker. Je vous présente une histoire sur /dev/root, racontée en extraits de code, après moins d’une semaine en production :

[11:49:56] 0 ✓ (1.8ms)
root@discourse:/var/discourse # df -h
Filesystem     Size  Used Avail Use% Mounted on
/dev/root       30G   21G  9.6G  69% /
tmpfs          7.7G     0  7.7G   0% /dev/shm
tmpfs          3.1G  1.1M  3.1G   1% /run
tmpfs          5.0M     0  5.0M   0% /run/lock
efivarfs       128K  3.6K  125K   3% /sys/firmware/efi/efivars
/dev/nvme1n1p16 891M  109M  720M  14% /boot
/dev/nvme1n1p15  98M  6.4M   92M   7% /boot/efi
/dev/nvme0n1    32G  346M   30G   2% /var/discourse
tmpfs          1.6G   12K  1.6G   1% /run/user/1001
overlay         30G   21G  9.6G  69% /var/lib/docker/overlay2/5a649418bbfc064f488e895572eec1ace487a3eaa324fe1d8e3b395e6c5e3645/merged

[11:49:59] 0 ✓ (4.8ms)
root@discourse:/var/discourse # ./launcher cleanup
WARNING! This will remove all stopped containers.
Are you sure you want to continue? [y/N] y
Total reclaimed space: 0B
WARNING! This will remove all images without at least one container associated to them.
Are you sure you want to continue? [y/N] y
Deleted Images:
untagged: discourse/base@sha256:3696bdf18652b5455bd33795ec3b8e0f201c17a04f0e0126fc0317ed821373cd
....

[une TRÈS longue série de lignes supprimées]

....
Total reclaimed space: 12.43GB

[11:50:34] 0 ✓ (27.8s)
root@discourse:/var/discourse # df -h
Filesystem     Size  Used Avail Use% Mounted on
/dev/root       30G  6.9G   24G  23% /
tmpfs          7.7G     0  7.7G   0% /dev/shm
tmpfs          3.1G  1.1M  3.1G   1% /run
tmpfs          5.0M     0  5.0M   0% /run/lock
efivarfs       128K  3.6K  125K   3% /sys/firmware/efi/efivars
/dev/nvme1n1p16 891M  109M  720M  14% /boot
/dev/nvme1n1p15  98M  6.4M   92M   7% /boot/efi
/dev/nvme0n1    32G  346M   30G   2% /var/discourse
tmpfs          1.6G   12K  1.6G   1% /run/user/1001
overlay         30G  6.9G   24G  23% /var/lib/docker/overlay2/5a649418bbfc064f488e895572eec1ace487a3eaa324fe1d8e3b395e6c5e3645/merged

[11:55:28] 0 ✓ (3.3ms)
root@discourse:/var/discourse #

Je vous aime. J’aime Discourse. Je suis marié au produit et j’ai l’intention de continuer à l’utiliser plus ou moins pour toujours.

Mais, genre… juste, pourquoi. Pourquoi sommes-nous en 2025 et je dois encore, par ma propre faute, me débattre avec launcher cleanup ? Pourquoi la gestion des images n’est-elle pas une fonction inhérente de launcher ?

Encore une fois, je vous aime. J’ai choisi Discourse pour SCW parce que je crois en ce que vous avez construit et j’adore l’utiliser. Mais genre… c’est la moitié de mon pauvre volume de démarrage AMI qui est occupé par des trucs inutiles qui pourraient – du moins si je comprends la partie technique – être gérés automatiquement.

Je ne veux pas me plaindre – je fais juste un point après quelques années d’absence de la chaise d’administrateur. J’adore la détection de spam par IA et le triage par IA, surtout dans un forum météo où les publications politiquement chargées concernant le changement climatique (pour ou contre) sont une caractéristique régulière. Merci pour tout <3

7 « J'aime »
2

Ravi de vous revoir, Lee !

Il m’est arrivé la même chose sur mon site auto-hébergé cette semaine. Les sauvegardes échouaient et j’ai laissé cela de côté pendant une semaine environ car j’étais absent et je n’avais pas accès à mon ordinateur portable. Dès mon retour, j’ai lancé le nettoyage et récupéré beaucoup d’espace disque, et les sauvegardes ont pu reprendre.

4 « J'aime »
3

Bonjour, content de vous revoir par ici !

Une partie de la raison est que c’était « suffisamment bon » – nous ne l’utilisons pas en interne sur notre hébergement car nous faisons souvent pivoter les conteneurs et les images, donc notre cadence est très différente de ce à quoi ressemblerait un site auto-hébergé.

L’autre explication est qu’entre le lanceur et Docker, aucun système ne veut assumer l’entière responsabilité du calendrier de suppression des données – le calendrier de suppression des données utilisateur devrait être entièrement sous le contrôle de l’utilisateur.

J’ai rencontré quelques problèmes sur des sites auto-hébergés où le nettoyage nettoie également la nouvelle base Discourse que je devais construire, ce qui entraîne un terrible problème d’œuf et de poule. Le fait que cela ne soit pas remarqué parce que cela s’exécute automatiquement serait probablement un peu difficile à résoudre.

Une suggestion simple pourrait peut-être être de planifier via cronjob un docker system prune ou launcher clean à vos propres risques. Cela pourrait fonctionner ?

6 « J'aime »
4

Parce que parfois, il peut supprimer le seul conteneur fonctionnel que vous ayez.

Vous pourriez simplement l’exécuter à chaque fois avant de reconstruire, pendant que tous vos conteneurs fonctionnels sont encore en cours d’exécution.

1 « J'aime »
5

Bonne idée — parfois les réponses simples sont les meilleures. Merci, et je vais faire cela !

6

Comment puis-je/pouvons-nous répondre oui lors de l’exécution de ./launcer cleanup via cron ? Je veux dire que pour moi, les conteneurs ne sont pas un gros problème, mais les images orphelines le sont.

1 « J'aime »
7

Il n’y a aucune raison de le faire avec cron, vous ne créez de nouvelles images que lorsque vous en construisez une avec launcher. Vous n’avez besoin de le faire qu’avant ou après avoir construit une image.

Si vous souhaitez éviter les invites de launcher, vous pouvez le faire avec les commandes docker comme suggéré ci-dessus. En voici une (mais lisez la documentation pour savoir ce qu’elle fait afin de vous assurer que c’est ce que vous voulez) :

/usr/bin/docker image prune -a -f
1 « J'aime »
8

Il faut que je vérifie ça. Merci.

Je ne sais rien d’autre, mais aujourd’hui, encore une fois, la reconstruction a échoué parce qu’il me restait moins de 5 Go d’espace libre. Bien sûr, cleanup a fait le travail, et ce n’était rien d’autre qu’un peu ennuyeux. Et pourtant, j’aimerais ne pas voir de telles situations.

Et voici à quel point je comprends peu comment fonctionne Docker :joy: Si j’ai bien compris, ces images, qui ont été détruites parce qu’elles n’étaient utilisées par aucun conteneur, n’étaient pas des images au sens de photos comme je l’ai toujours pensé :face_with_peeking_eye: :rofl:

2 « J'aime »
9

La réponse directe est que vous pourriez echo y | launcher cleanup pour envoyer « y » tôt.

La réponse indirecte est que le nettoyage réel du lanceur (après est équivalent à ces deux commandes :

docker container prune --force --filter until=24h
docker image prune --all --force --filter until=24h

et l’invite à laquelle je pense que vous faites référence concerne la suppression des anciens répertoires de données postgres :

rm -rf /var/discourse/shared/standalone/postgres_data_old*

Vous pourriez abandonner la dépendance vis-à-vis du lanceur et utiliser ces commandes directement.

2 « J'aime »
10

En fait, je fais référence aux questions que j’ai obtenues en exécutant ./launcher cleanup. D’abord, il supprime tous les conteneurs arrêtés. Ensuite, il propose de supprimer toutes les images qui ne sont utilisées par aucun conteneur — et c’est cette partie qui me libère de l’espace, près de 40 Go la dernière fois.

C’est pourquoi j’étais assez confus, car je ne comprenais pas pourquoi j’avais autant d’images orphelines (jpg, png, etc.). Mais nous parlons ici d’images totalement différentes, n’est-ce pas ?

Oui, je reconstruis au moins deux fois par semaine. Ou très récemment, lorsque je chassais un plugin malveillant, j’ai effectué au moins une douzaine de reconstructions.

Est-ce qu’il crée une nouvelle image à chaque fois, je ne sais pas.

11

Chaque reconstruction est une nouvelle image - elles s’accumuleraient donc si elles n’étaient pas nettoyées.

Le lanceur ne demande actuellement de nettoyer que lors de l’exécution d’autres commandes lorsque l’espace disque est faible.

1 « J'aime »
12

Ce qui peut être un inconvénient si vous l’exécutez avec un script ; le script restera bloqué en attente d’une réponse (je suppose que c’est pourquoi on utilise yes pour le rediriger). Je fais juste un nettoyage si le disque a moins de 10 Go d’espace libre.

1 « J'aime »
13

Voici peut-être une solution de contournement potentielle qui pourrait fonctionner pour moi. Je la mentionne ici au cas où elle serait utile à d’autres.

J’envisage d’ajouter un paramètre data-root à /etc/docker/daemon.json, pour voir si cela force Docker à placer ses images — les images de Discourse, dans ce cas, puisque rien d’autre n’est hébergé sur la machine — dans un emplacement moins critique qui ne fera pas exploser mon volume de démarrage.

En cherchant sur meta des fils de discussion passés à ce sujet, j’obtiens quelques résultats qui ne m’apprennent pas grand-chose, et avant de faire effondrer mon instance Discourse de production en un tas fumant et enflammé, je voulais demander si c’est viable :slight_smile:

14

J’ai adopté une approche différente et monté un système de fichiers séparé sur /var/lib/docker

Dans mon cas, pour des raisons très spécifiques au site, j’ai choisi des systèmes de fichiers séparés pour chacun de /var/discourse/shared, /var/discourse/shared/data, /var/discourse/shared/app/uploads/default/original, et /var/lib/docker — mais si vous voulez simplement que /var/discourse soit un système de fichiers séparé, vous pourriez probablement créer le répertoire /var/discourse/share/docker et le monter en tant que bind-mount sur /var/lib/docker (en faisant évidemment cela avec un système au repos et en déplaçant les fichiers si nécessaire).

4 « J'aime »
15

C’est une idée encore meilleure que de tripoter les entrailles de Docker. Merci !!

1 « J'aime »
16

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.