10-jähriger selbst gehosteter Discourse-Administrator fragt: Warum nicht Launcher-Bereinigung als Teil des Rebuilds?

Installation
1

Hallo zusammen. Mein Name ist Lee und ich hoste Discourse seit 2013 mal mehr, mal weniger selbst. Ich erinnere mich, dass ich mich mit rbenv herumschlagen musste, um überhaupt anzufangen. Ich erinnere mich, dass ich nginx mit Phusion Passenger kompilieren musste, damit die Dinge laufen. Ich erinnere mich, dass ich vor wahrscheinlich zehn verdammten Jahren mit @sam darüber gestritten habe, dass der Wechsel zu Docker eine Kapitulation vor der Schwäche von Entwicklern ist, bei denen es “bei mir zu Hause funktioniert, mit meinen Dotfiles und meinem Albtraum” (und ich hatte verdammt nochmal Unrecht!). Ich erinnere mich an das erste Mal, als ich den Ausdruck “bike-shedding” hörte. Um den Mann zu zitieren, ich erinnere mich an alles.

Nachdem ich mehrere Jahre weg war, hatte ich Gelegenheit, mich wieder mit dem Self-Hosting von Discourse zu beschäftigen, als Ersatz für native Wordpress-Kommentare auf einer Wetterseite im Raum Houston, die normalerweise etwa 10.000 PV/Tag hat, aber während Hurrikans möglicherweise etwa 2 Millionen PV/Tag mit bis zu 1 Million eindeutigen Besuchern erreicht. Wir hatten jahrelang Probleme mit den nativen Kommentaren von WordPress, aber seit letztem Mittwoch sind wir mit selbst gehostetem Discourse live. (Und das nicht weniger auf Graviton3! Ernsthaft, es funktioniert einfach und es ist großartig.)

Hier ist der Punkt, auf den ich hinauswill: Es ist 2025, und als Self-Hoster habe ich immer noch damit zu kämpfen, meinen Docker-Image-Speicher manuell zu verwalten. Ich präsentiere eine Geschichte über /dev/root, erzählt in Code-Snippets, nach weniger als einer Woche in Produktion:

[11:49:56] 0 ✓ (1.8ms)
root@discourse:/var/discourse # df -h
Filesystem       Größe  Benutzt Verf. Verw% Eingehängt auf
/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
WARNUNG! Dies entfernt alle gestoppten Container.
Sind Sie sicher, dass Sie fortfahren möchten? [j/N] j
Gesamter freigegebener Speicherplatz: 0B
WARNUNG! Dies entfernt alle Images, denen kein Container zugeordnet ist.
Sind Sie sicher, dass Sie fortfahren möchten? [j/N] j
Gelöschte Images:
untagged: discourse/base@sha256:3696bdf18652b5455bd33795ec3b8e0f201c17a04f0e0126fc0317ed821373cd
....

[eine verdammt viele Zeilen geschwärzt]

....
Gesamter freigegebener Speicherplatz: 12.43GB

[11:50:34] 0 ✓ (27.8s)
root@discourse:/var/discourse # df -h
Filesystem       Größe  Benutzt Verf. Verw% Eingehängt auf
/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 #

Ich liebe euch. Ich liebe Discourse. Ich bin dem Produkt treu und beabsichtige, es mehr oder weniger für immer zu nutzen.

Aber, äh… einfach, warum. Warum ist es 2025 und ich muss mich persönlich, ganz allein, immer noch mit launcher cleanup herumschlagen? Warum ist die Image-Verwaltung keine inhärente Funktion von launcher?

Nochmal, ich liebe euch. Ich habe Discourse für SCW gewählt, weil ich an das glaube, was ihr aufgebaut habt, und ich liebe es, es zu benutzen. Aber so… das ist die Hälfte meines armen AMI-Boot-Volumes, das mit nutzlosem Zeug belegt ist, das – zumindest wenn ich die technische Seite der Dinge verstehe – automatisch verwaltet werden könnte.

Ich will mich nicht beschweren – ich melde mich nur nach ein paar Jahren, in denen ich nicht mehr im Admin-Stuhl saß, wieder. Ich liebe die KI-Spam-Erkennung und die KI-Triage, besonders in einem Wetterforum, in dem politisch aufgeladene Beiträge bezüglich des Klimawandels (entweder dafür oder dagegen) regelmäßig vorkommen. Danke für alles <3

7 „Gefällt mir“
2

Schön, Sie wiederzusehen, Lee!

Mir ist diese Woche dasselbe auf meiner selbst gehosteten Website passiert. Backups schlugen fehl und ich ließ das etwa eine Woche lang laufen, weil ich unterwegs war und keinen Zugriff auf meinen Laptop hatte. Sobald ich zurück war, führte ich eine Bereinigung durch, gewann viel Speicherplatz zurück und die Backups konnten wieder ausgeführt werden.

4 „Gefällt mir“
3

Hallo, schön, Sie wieder hier zu sehen!

Ein Teil davon ist, dass es “gut genug” war - wir verwenden es nicht intern in unserem Hosting, da wir Container und Images häufig rotieren, sodass unser Rhythmus ganz anders ist als bei einer selbst gehosteten Website.

Die andere Erklärung ist, dass zwischen dem Launcher und Docker kein System die volle Verantwortung für den Zeitplan der Datenentfernung übernehmen möchte - der Zeitplan für das Löschen von Benutzerdaten sollte vollständig vom Benutzer gesteuert werden.

Ich bin auf einige Probleme bei selbst gehosteten Websites gestoßen, bei denen die Bereinigung auch die neue Discourse-Basis bereinigt, die ich zum Erstellen benötigte, was zu einem schrecklichen Henne-Ei-Problem führt. Wenn dies aufgrund der automatischen Ausführung nicht bemerkt würde, wäre es wahrscheinlich ein ziemliches Hindernis, das es herauszufinden gilt.

Ein einfacher Vorschlag hier wäre vielleicht, auf eigene Gefahr einen docker system prune oder launcher clean per Cronjob auszuführen. Könnte das funktionieren?

6 „Gefällt mir“
4

Weil es manchmal den einzigen funktionierenden Container löschen kann, den Sie haben.
Sie könnten ihn einfach jedes Mal ausführen, bevor Sie einen Rebuild ausführen, während alle Ihre funktionierenden Container noch laufen.

1 „Gefällt mir“
5

Guter Einwand – manchmal sind die einfachen Antworten die besten. Vielen Dank, und ich werde es so machen!

6

Wie kann ich/wir Ja sagen, wenn ich ./launcer cleanup über Cron ausführe? Ich meine, für mich sind Container kein großes Problem, aber verwaiste Images schon.

1 „Gefällt mir“
7

Es gibt keinen Grund, dies mit Cron zu tun. Sie erstellen neue Images nur, wenn Sie eines mit launcher erstellen. Sie müssen dies nur vor oder nach dem Erstellen eines Images tun.

Wenn Sie die Eingabeaufforderungen von Launcher vermeiden möchten, können Sie dies mit den oben vorgeschlagenen docker-Befehlen tun. Hier ist einer (aber rtfm, was er tut, um sicherzustellen, dass er das ist, was Sie wollen):

/usr/bin/docker image prune -a -f
1 „Gefällt mir“
8

Das muss ich mir ansehen. Danke.

Ich weiß nichts weiter, aber heute ist das Erstellen wieder fehlgeschlagen, weil ich weniger als 5 GB freien Speicherplatz hatte. Sicher, cleanup hat seine Arbeit gemacht, und das war nichts weiter als ein bisschen nervig. Und doch möchte ich solche Situationen nicht erleben.

Und hier zeigt sich, wie wenig ich verstehe, wie Docker funktioniert :joy: Wenn ich das richtig verstanden habe, waren diese Images, die zerstört wurden, weil sie von keinem Container verwendet wurden, gar keine Images im Sinne von Bildern, wie ich die ganze Zeit angenommen habe :face_with_peeking_eye: :rofl:

2 „Gefällt mir“
9

Die direkte Antwort ist, dass Sie echo y | launcher cleanup verwenden könnten, um frühzeitig „y“ zu senden.

Die indirekte Antwort ist, dass die eigentliche Launcher-Bereinigung (nachdem sie äquivalent ist) diese beiden Befehle sind:

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

und die Aufforderung, auf die Sie sich wahrscheinlich beziehen, dient zum Entfernen alter PostgreSQL-Datenverzeichnisse:

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

Sie könnten die Abhängigkeit von Launcher fallen lassen und diese Befehle direkt verwenden.

2 „Gefällt mir“
10

Tatsächlich beziehe ich mich auf Fragen, die ich bei der Ausführung von ./launcher cleanup erhalten habe. Zuerst werden alle gestoppten Container entfernt. Dann wird angeboten, alle Images zu löschen, die nicht von mindestens einem Container verwendet werden – und dieser Teil ist es, der bei mir Platz schafft, letztes Mal fast 40 GB.

Deshalb war ich ziemlich verwirrt, weil ich nicht verstehen konnte, warum ich so viele verwaiste Images (jpg, png usw.) hatte. Aber wir sprechen hier über völlig unterschiedliche Images, oder?

Ja, ich baue mindestens zweimal pro Woche neu. Oder vor kurzem, als ich nach einem schlecht funktionierenden Plugin suchte, habe ich mindestens ein Dutzend Neuaufbauten durchgeführt.

Ob jedes Mal ein neues Image erstellt wird, weiß ich nicht.

11

Jeder Rebuild ist ein neues Image – sie würden sich also ansammeln, wenn sie nicht bereinigt würden.

Der Launcher fordert derzeit nur zur Bereinigung auf, wenn andere Befehle ausgeführt werden, sobald der Speicherplatz knapp wird.

1 „Gefällt mir“
12

Was ein Nachteil sein kann, wenn man ihn mit einem Skript ausführt; das Skript wird einfach warten, bis eine Antwort kommt (ich schätze, deshalb leitet man yes hinein). Ich mache einfach eine Bereinigung, wenn die Festplatte weniger als 10 GB freien Speicher hat.

1 „Gefällt mir“
13

Hier ist vielleicht eine mögliche Problemumgehung, die für mich funktionieren könnte. Ich bringe sie hier zur Sprache, falls sie für andere hilfreich ist.

Ich überlege, eine data-root-Einstellung zu /etc/docker/daemon.json hinzuzufügen, um zu sehen, ob dies Docker zwingt, seine Images – in diesem Fall die Images von Discourse, da sonst nichts auf der Box gehostet wird – an einem weniger kritischen Ort zu platzieren, der mein Boot-Volume nicht sprengt.

Die Suche auf Meta nach früheren Threads dazu liefert mir ein paar Ergebnisse, die mir nicht wirklich weiterhelfen, und bevor ich meine Produktions-Discourse-Instanz in einem brennenden, rauchenden Haufen zusammenbrechen lasse, wollte ich fragen, ob dies machbar ist :slight_smile:

14

Ich habe einen anderen Ansatz gewählt und ein separates Dateisystem auf /var/lib/docker gemountet.

In meinem Fall habe ich aus sehr standortspezifischen Gründen separate Dateisysteme für /var/discourse/shared, /var/discourse/shared/data, /var/discourse/shared/app/uploads/default/original und /var/lib/docker gewählt – aber wenn Sie nur /var/discourse als separates Dateisystem haben möchten, könnten Sie wahrscheinlich das Verzeichnis /var/discourse/share/docker erstellen und es auf /var/lib/docker binden (offensichtlich sollte dies mit einem ruhenden System geschehen und Dateien bei Bedarf verschoben werden).

4 „Gefällt mir“
15

Das ist eine noch bessere Idee, als an den Innereien von Docker herumzupfuschen. Danke!!

1 „Gefällt mir“
16

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