fix(prod): verwaiste Docker-Schichten und unbegrenzte Container-Logs #99

Merged
Phil merged 1 commit from fix/plattenhygiene into main 2026-09-07 09:58:21 +00:00
Owner

Refs #85

Was aufgefallen ist

Nach den fünf Deploys von heute stand die Platte wieder bei 87 Prozent, also
unterhalb der eigenen Deploy-Sperre aus #94. Der nächste Deploy wäre abgebrochen.

Zwei Ursachen, die beide nicht sichtbar waren:

docker system df lügt. Es meldete 13 GB Images, während
/var/lib/docker/overlay2 50 GB belegte. Die Differenz sind verwaiste Schichten,
die docker builder prune nicht anfasst. docker system prune -f gab 23,95 GB
frei, von 87 auf 56 Prozent.

Container-Logs wuchsen unbegrenzt. 1,9 GB insgesamt, ein einzelner Container
713 MB.

Der Fix

Der Deploy räumt jetzt mit system prune statt nur builder prune auf. Bewusst
ohne -a: das würde auch Images löschen, an denen gestoppte Container
anderer Projekte auf diesem Host hängen.

daemon.json begrenzt Logs auf 3 × 50 MB. Das greift nur für neu erzeugte
Container; bestehende behalten ihre Einstellung bis zum nächsten up -d. Steht
so in docs/DEPLOYMENT.md.

Gemessen

  • docker system prune -f → 23,95 GB frei, Platte von 87 auf 56 Prozent
  • daemon.json aufgespielt, systemctl reload docker, 23 Container liefen durch
  • Alle 27 Seiten weiterhin 200

🤖 Generated with Claude Code

https://claude.ai/code/session_01VyiQJ8BM3hcqH3E3sPvg1N

Refs #85 ## Was aufgefallen ist Nach den fünf Deploys von heute stand die Platte wieder bei 87 Prozent, also unterhalb der eigenen Deploy-Sperre aus #94. Der nächste Deploy wäre abgebrochen. Zwei Ursachen, die beide nicht sichtbar waren: **`docker system df` lügt.** Es meldete 13 GB Images, während `/var/lib/docker/overlay2` 50 GB belegte. Die Differenz sind verwaiste Schichten, die `docker builder prune` nicht anfasst. `docker system prune -f` gab **23,95 GB** frei, von 87 auf 56 Prozent. **Container-Logs wuchsen unbegrenzt.** 1,9 GB insgesamt, ein einzelner Container 713 MB. ## Der Fix Der Deploy räumt jetzt mit `system prune` statt nur `builder prune` auf. Bewusst **ohne** `-a`: das würde auch Images löschen, an denen gestoppte Container anderer Projekte auf diesem Host hängen. `daemon.json` begrenzt Logs auf 3 × 50 MB. Das greift nur für neu erzeugte Container; bestehende behalten ihre Einstellung bis zum nächsten `up -d`. Steht so in `docs/DEPLOYMENT.md`. ## Gemessen - `docker system prune -f` → 23,95 GB frei, Platte von 87 auf 56 Prozent - `daemon.json` aufgespielt, `systemctl reload docker`, 23 Container liefen durch - Alle 27 Seiten weiterhin 200 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01VyiQJ8BM3hcqH3E3sPvg1N
Nach fuenf Deploys stand die Platte wieder bei 87 Prozent, also unterhalb der
eigenen Deploy-Sperre. Zwei Ursachen, die beide nicht sichtbar waren:

"docker system df" meldete 13 GB Images, waehrend /var/lib/docker/overlay2
50 GB belegte. Die Differenz sind verwaiste Schichten, die "builder prune"
nicht anfasst. "system prune -f" gab 23,95 GB frei, von 87 auf 56 Prozent. Der
Deploy raeumt jetzt so auf. Bewusst ohne -a: das wuerde auch Images loeschen,
an denen gestoppte Container anderer Projekte auf diesem Host haengen.

Container-Logs wuchsen unbegrenzt, 1,9 GB insgesamt, ein einzelner Container
713 MB. daemon.json begrenzt sie jetzt auf 3 mal 50 MB. Das greift nur fuer
neu erzeugte Container; bestehende behalten ihre Einstellung bis zum naechsten
up -d.

Refs #85

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VyiQJ8BM3hcqH3E3sPvg1N
Phil merged commit e178109372 into main 2026-09-07 09:58:21 +00:00
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Phil/philflow.io!99
No description provided.