Docker auf Debian 13 richtig betreiben – 15 Dinge, die Administratoren wissen sollten
Debian 13 „Trixie“ ist aktuell die stabile Debian-Hauptversion; seit Juli 2026 ist 13.6 verfügbar. Für Docker-Administratoren ist das ein guter Zeitpunkt, die eigene Installation einmal sauber zu überprüfen. Dieser Guide zeigt nicht nur die Installation, sondern die Punkte, die im Alltag wirklich über Stabilität, Wartbarkeit und Sicherheit entscheiden.
Docker CE oder Debian-Paket?
Auf Debian gibt es mehrere Wege zu Docker. Für eine langfristig planbare Umgebung sollte man sich bewusst für eine Paketquelle entscheiden und nicht versehentlich Komponenten aus unterschiedlichen Quellen mischen. Wer Docker aus dem offiziellen Docker-Repository bezieht, sollte auch Compose und Buildx aus demselben Ökosystem halten.
docker compose ist heute der richtige Weg
Compose V2 ist als Docker-CLI-Plugin integriert. Die moderne Schreibweise lautet `docker compose`. Docker dokumentiert für Debian die Installation des Compose-Plugins über das Docker-Repository. Ein vorhandenes `docker-compose` sollte vor einer Migration identifiziert werden, statt blind entfernt zu werden.
Docker-Daten liegen nicht dort, wo viele denken
Container, Images, Netzwerke und Volumes werden standardmäßig unter `/var/lib/docker` verwaltet. Das Verzeichnis sollte nicht einfach aufräumt oder gelöscht werden. Wer das Datenverzeichnis verlagern möchte, sollte dies über die Docker-Konfiguration und mit einem klaren Migrationsplan tun.
Volumes sind Daten – behandeln Sie sie wie Daten
Ein Container ist austauschbar, ein Volume häufig nicht. Datenbanken, Nextcloud, GitLab oder andere zustandsbehaftete Dienste sollten ihre persistenten Daten in Volumes oder bewusst eingebundenen Verzeichnissen halten. Vor Upgrades sollte geprüft werden, welche Volumes wirklich kritisch sind.
Logging: der unterschätzte Speicherfresser
Docker kann Container-Logs lokal sammeln. Ohne Rotation kann eine einzelne Anwendung über Monate riesige Logdateien erzeugen. In produktiven Umgebungen sollte die Logstrategie bewusst festgelegt werden: Rotation, Journald, zentraler Logserver oder ein anderer Collector.
Restart Policies sind kein Monitoring
`restart: unless-stopped` oder `always` kann einen abgestürzten Container neu starten. Es erkennt aber nicht, ob die Anwendung im Container wirklich funktioniert. Ein Webserver kann beispielsweise erreichbar sein, während die dahinterliegende Datenbank tot ist. Healthchecks und externes Monitoring ergänzen Restart Policies.
Healthchecks richtig einsetzen
Ein Healthcheck sollte einen echten Dienstzustand prüfen. `curl localhost` kann sinnvoll sein, wenn damit tatsächlich die Anwendung getestet wird. Für Datenbanken sollte der Check die Datenbankverbindung prüfen. Ein grüner Containerstatus allein ist kein Beweis für einen funktionierenden Dienst.
Docker-Netzwerke verstehen
Compose erzeugt typischerweise eigene Bridge-Netzwerke. Container sprechen darin über Servicenamen miteinander. Das ist stabiler als hart codierte IP-Adressen. Reverse Proxies sollten nur die Ports veröffentlichen, die wirklich aus dem Host-Netz erreichbar sein müssen.
Ports sparsam veröffentlichen
`ports:` macht einen Container-Port auf dem Host erreichbar. Für interne Kommunikation ist das meist unnötig. Wenn beispielsweise ein Webproxy und eine Datenbank im selben Compose-Netzwerk laufen, muss die Datenbank nicht zusätzlich auf `3306` oder `5432` am Host veröffentlicht werden.
Updates: nicht einfach alles automatisch austauschen
Container-Images können sich ändern. Ein blindes `pull` und `up` kann eine Anwendung nach einem Imagewechsel beschädigen. Für produktive Dienste empfiehlt sich ein kontrollierter Ablauf: Backup, Pull, Konfigurationsprüfung, Update, Smoke-Test und bei Bedarf Rollback.
docker system prune – gefährlich bequem
`docker system prune` kann ungenutzte Ressourcen entfernen. Das ist nützlich, aber kein Routinebefehl, den man gedankenlos in einen Cronjob packen sollte. Vor jedem Cleanup muss klar sein, welche Images, Container und Volumes tatsächlich nicht mehr benötigt werden.
Datenbank-Backups gehören aus dem Container heraus
Ein Export einer MariaDB- oder PostgreSQL-Datenbank ist häufig sinnvoller als nur das Datenverzeichnis zu kopieren. Der Backup-Job sollte die Anwendung und die Datenbank so behandeln, dass ein konsistenter Dump entsteht. Zusätzlich sollte ein Restore getestet werden.
Secrets gehören nicht in Git
Passwörter in `compose.yml` oder `.env`-Dateien können schnell in Git-Repositories landen. Für kleine Umgebungen sollte mindestens die Zugriffsberechtigung restriktiv sein; bei höheren Anforderungen kommen Docker Secrets oder ein dedizierter Secret Manager in Betracht.
Sicherheitsupdates und Images auseinanderhalten
Ein aktuelles Debian-Hostsystem bedeutet nicht automatisch aktuelle Container. Umgekehrt kann ein Container ein eigenes Betriebssystem-Userspace enthalten. Host-Patching und Image-Lifecycle sind deshalb zwei getrennte Aufgaben.
Mein Betriebsmodell für kleine Docker-Server
Für kleine Server bevorzuge ich eine klare Struktur: `/opt/<dienst>` für Compose-Projekte, dokumentierte `.env`-Dateien, Backups außerhalb des Docker-Datenverzeichnisses, definierte Restart Policies, Healthchecks, kontrollierte Updates und externes Monitoring. Das ist langweilig – und genau deshalb robust.
Fazit
Docker wird nicht durch möglichst viele Tricks stabil. Stabil wird eine Installation durch klare Paketquellen, reproduzierbare Compose-Dateien, getrennte Daten, kontrollierte Updates, Backups, Restore-Tests und Monitoring.