Temporäre Shell-Container für Wartung und Diagnose

1. Das Konzept: Werkzeuge nur für die Dauer der Aufgabe

Das Grundprinzip temporärer Shell-Container ist einfach: Jedes Werkzeug, das für eine Diagnose- oder Wartungsaufgabe benötigt wird, wird in einem Container mitgebracht, der nach Abschluss der Aufgabe spurlos verschwindet. Kein apt-get install curl auf dem Produktionsserver, kein pip install, keine Back-Door-Tools die aus "wir haben sie mal gebraucht" dauerhaft installiert blieben. Der Server selbst hat am Ende der Wartungsaufgabe exakt denselben Zustand wie davor.

Das ist keine theoretische Idealvorstellung, sondern ein praktikabler Workflow: docker run --rm -it --network container:myapp nicolaka/netshoot startet in Sekunden ein Tool-Image mit hunderten von Netzwerk-Diagnose-Werkzeugen im Netzwerk-Namespace des laufenden Containers. Nach dem Beenden der Shell ist der temporäre Shell-Container vollständig entfernt. Für den Operator fühlt es sich wie eine erweiterte Shell im Container an, ohne dass der Hauptcontainer selbst berührt wird.

Für regelmäßige Wartungsaufgaben können temporäre Shell-Container als Shell-Funktionen oder Makefile-Targets definiert werden. Statt sich den komplexen docker run-Befehl zu merken, ruft man make db-shell oder ./bin/db-shell auf, das intern einen temporären Shell-Container mit allen nötigen Parametern startet. Das senkt die Hürde und macht den Workflow für das gesamte Team reproduzierbar.

2. Grundmuster: docker run --rm interaktiv

Das --rm-Flag ist das wichtigste Flag für temporäre Shell-Container: Es sorgt dafür, dass der Container nach dem Beenden automatisch gelöscht wird. Ohne --rm sammeln sich gestoppte Container-Instanzen an, die Speicherplatz belegen und in docker ps -a als unübersichtliche Liste erscheinen. Mit -it wird ein interaktives Terminal bereitgestellt – ohne dieses Flag würde die Shell sofort beendet, weil keine Eingabe möglich ist.

Die Auswahl des richtigen Base-Images für temporäre Shell-Container bestimmt, welche Tools verfügbar sind. Für allgemeine Diagnose-Aufgaben reicht alpine:latest mit anschließendem apk add. Das hat den Nachteil, dass der apk add-Schritt jedes Mal ausgeführt wird. Besser ist ein vorbereitetes Diagnose-Image, das alle benötigten Tools bereits enthält. nicolaka/netshoot ist das de-facto-Standardimage für Netzwerk-Diagnose in Container-Umgebungen und enthält über 100 Netzwerk-Tools.

# Temporary shell container patterns — all containers auto-remove on exit

# Basic interactive shell in alpine (with package install on demand)
docker run --rm -it alpine:latest sh

# Network diagnostic shell in the same network as the app stack
docker run --rm -it \
  --network myproject_default \
  nicolaka/netshoot

# Attach to the exact network namespace of a running container
# Sees same network interfaces, routing table, open ports as the target container
docker run --rm -it \
  --network container:myapp \
  nicolaka/netshoot

# Quick HTTP test to internal service (no curl on production host needed)
docker run --rm \
  --network myproject_default \
  curlimages/curl:latest \
  curl -sv http://php-fpm:9000/status

# Temporary DNS resolution test
docker run --rm \
  --network myproject_default \
  alpine:latest \
  sh -c "nslookup mysql && nslookup redis"

# One-shot command with --rm — runs command, removes container, returns output
docker run --rm \
  --network container:myapp \
  busybox \
  sh -c "netstat -tlnp"

3. Netzwerk-Diagnose im Container-Stack

Netzwerk-Probleme in Docker Compose-Stacks sind häufig schwer zu diagnostizieren, weil Container in isolierten Netzwerken laufen und Host-Tools diese Netzwerke nicht direkt sehen. Ein temporärer Shell-Container im selben Docker-Netzwerk kann direkt auf die Service-Namen des Stacks zugreifen und DNS-Auflösung, TCP-Verbindungen und HTTP-Endpunkte testen. Das ersetzt das Raten, ob ein Service intern erreichbar ist, durch konkrete Messungen.

Mit --network container:CONTAINER_NAME übernimmt der temporäre Shell-Container vollständig den Netzwerk-Namespace des Zielcontainers. Er sieht dieselben Netzwerkinterfaces, dieselbe Routing-Tabelle, dieselben offenen Ports und kann Verbindungen aus derselben Perspektive aufbauen, die der Zielcontainer hätte. Das ist entscheidend für Diagnosen, die von der Perspektive des Containers abhängen – etwa die Frage, ob eine ausgehende Verbindung zu einem externen API-Endpunkt aus dem Container heraus erreichbar ist.

Für Latenz- und Bandbreiten-Messungen zwischen Containern bietet iperf3 im temporären Shell-Container präzise Messungen. Paket-Captures mit tcpdump im Netzwerk-Namespace des Zielcontainers zeigen exakt welche Pakete den Container erreichen – ohne tcpdump dauerhaft im Hauptcontainer-Image haben zu müssen. Diese Diagnose-Tiefe war vor temporären Shell-Containern nur durch Tool-Installation auf dem Host erreichbar.

4. Namespace-Sharing: Prozesse und Netzwerk anderer Container sehen

Linux-Namespaces sind die technische Grundlage der Container-Isolation. Docker erlaubt es, temporäre Shell-Container so zu starten, dass sie spezifische Namespaces eines anderen Containers teilen. Das ermöglicht tiefe Diagnose-Einblicke ohne den Hauptcontainer zu modifizieren. Der Netzwerk-Namespace-Share wurde bereits beschrieben. Mit --pid container:CONTAINER_NAME sieht der temporäre Shell-Container alle Prozesse des Zielcontainers und kann strace, lsof oder perf darauf anwenden.

Das IPC-Namespace-Sharing mit --ipc container:CONTAINER_NAME erlaubt Zugriff auf Shared-Memory-Segmente des Zielcontainers. Das ist für Diagnosen relevant, wenn ein Prozess über Shared Memory kommuniziert und diese Kommunikation beobachtet werden soll. In der Praxis ist Netzwerk- und PID-Namespace-Sharing die häufigste Kombination für Container-Diagnose.

Es ist wichtig zu verstehen, dass Namespace-Sharing keine Privilegien gibt, die der Zielcontainer nicht hat. Wenn der Hauptcontainer als nicht-root-Benutzer läuft und keine privilegierten Capabilities hat, kann der temporäre Shell-Container im PID-Namespace dieser Prozesse keine privilegierten Operationen ausführen. Für tiefere System-Level-Diagnosen, die privilegierte Capabilities erfordern, muss der temporäre Shell-Container mit --privileged gestartet werden – was auf Produktionssystemen nur in echten Notfällen und mit bewusstem Risikomanagement erfolgen sollte.

5. Die richtigen Diagnose-Images für jeden Zweck

Die Wahl des Diagnose-Images ist entscheidend für den Nutzen des temporären Shell-Containers. Ein zu minimales Image hat die benötigten Tools nicht. Ein zu großes Image dauert zu lang beim Pull. Die Lösung ist eine Sammlung von spezialisierten Diagnose-Images, die für verschiedene Aufgaben vorgehalten werden:

Für Netzwerk-Diagnose ist nicolaka/netshoot (etwa 400 MB) das umfassendste Image – es enthält unter anderem curl, wget, dig, nmap, tcpdump, iperf3, ngrep, ss, ip und viele weitere Tools. Für einfache Tests reicht curlimages/curl (unter 10 MB). Für DNS-spezifische Diagnose bietet alpine/bind-tools dig, nslookup und host. Für MySQL-Diagnose ist der offizielle mysql-Client-Container ideal, für PostgreSQL postgres mit nur dem Client-Binary. Für generelle UNIX-Diagnose ist busybox mit unter 5 MB oft ausreichend.

# Reference card: right diagnostic image for the right task

# Network: comprehensive toolset (curl, dig, tcpdump, nmap, iperf3...)
docker run --rm -it --network container:myapp nicolaka/netshoot

# HTTP test only — minimal image (< 10 MB)
docker run --rm --network myproject_default curlimages/curl curl -sv http://app:8080/health

# DNS diagnosis
docker run --rm --network myproject_default alpine/bind-tools dig mysql A

# MySQL client shell (no mysql client on host required)
docker run --rm -it \
  --network myproject_default \
  mysql:8.4 \
  mysql -h mysql -u root -prootpass appdb

# Redis CLI
docker run --rm -it \
  --network myproject_default \
  redis:7-alpine \
  redis-cli -h redis

# PostgreSQL client
docker run --rm -it \
  --network myproject_default \
  postgres:16-alpine \
  psql -h postgres -U appuser appdb

# Certificate inspection — no openssl on host needed
docker run --rm alpine/openssl s_client -connect mironsoft.de:443 -showcerts </dev/null 2>&1 \
  | openssl x509 -noout -dates

# File operations and shell utilities — minimal 5 MB image
docker run --rm -it --network myproject_default busybox sh

6. Datenbankzugriff über temporäre Client-Container

Der häufigste Anwendungsfall für temporäre Shell-Container in produktiven Umgebungen ist der Datenbankzugriff für Diagnose und Wartung. Statt einen MySQL-Client auf dem Produktionsserver zu installieren, startet man einen temporären Shell-Container mit dem entsprechenden Datenbankbild und verbindet sich von dort zum Datenbankcontainer. Das bedeutet: Kein Datenbankport muss nach außen freigegeben sein, alle Zugangsdaten bleiben im Container-Netzwerk, und der Client ist nach der Sitzung verschwunden.

Für Datenbankdumps ist das Muster besonders elegant: docker run --rm --network myproject_default -v /backup:/backup mysql:8.4 mysqldump -h mysql -u root -prootpass appdb | gzip > /backup/appdb-$(date +%Y%m%d).sql.gz. Das Dump-Tool läuft im temporären Shell-Container, hat direkten Zugriff auf die Datenbank über das interne Netzwerk und schreibt den Dump in ein Volume, das auf dem Host gemountet ist. Nach Abschluss ist der Container weg, der Dump ist auf dem Host.

Für Migrations-Diagnosen, bei denen der genaue SQL-Zustand nach einer fehlgeschlagenen Migration untersucht werden muss, ist der direkte Datenbankzugriff über temporäre Shell-Container das schnellste Werkzeug. Ein interaktiver MySQL-Client im Container, der auf die Produktionsdatenbank zeigt, erlaubt ad-hoc-Queries ohne die Anwendungslogik zu umgehen. Das ist mächtiger als ORM-basierte Diagnose und schneller als das Schreiben eines Diagnosescripts.

7. Dateisystem-Diagnose ohne exec in den Hauptcontainer

Ein häufiges Missverständnis: docker exec -it container_name sh ist nicht immer verfügbar oder wünschenswert. Minimal-Images ohne Shell-Binary – wie scratch-basierte oder distroless-Images – erlauben kein docker exec. Und in Produktionsumgebungen möchte man den Hauptcontainer nicht durch eine Shell-Session belasten, die versehentlich Dateien verändert. Temporäre Shell-Container mit geteilten Volumes bieten eine sicherere Alternative.

Mit --volumes-from CONTAINER_NAME übernimmt der temporäre Shell-Container alle Volumes des Zielcontainers und kann deren Inhalt lesen – und schreiben, was mit Bedacht einzusetzen ist. Für reine Diagnose sollte :ro für read-only genutzt werden: -v myapp_data:/data:ro. Das erlaubt es, den Dateisystem-Zustand des Zielcontainers zu inspizieren, ohne versehentliche Änderungen zu riskieren.

Für Log-Analyse ist dieses Muster besonders nützlich: Ein temporärer Shell-Container mit grep, awk, jq und less mountet das Log-Volume des Produktionscontainers und erlaubt Analyse ohne den Produktionscontainer zu belasten. Das ist effizienter als das Kopieren von Logs auf den Host und ermöglicht Realtime-Analyse mit tail -f.

8. Temporäre Container vs. Tool-Installation auf dem Host

Die Alternative zu temporären Shell-Containern ist die klassische Herangehensweise: Tools auf dem Host oder im Container installieren, wenn sie gebraucht werden. Das klingt einfacher, hat aber erhebliche Nachteile, die sich über Zeit akkumulieren.

Das entscheidende Argument für temporäre Shell-Container ist nicht Bequemlichkeit, sondern Korrektheit: Ein Netzwerk-Diagnose-Tool auf dem Host sieht das Host-Netzwerk, nicht das Container-Netzwerk. Eine Verbindung, die vom Host zum MySQL-Container über Port-Mapping funktioniert, sagt nichts darüber aus, ob Container intern über Service-Namen kommunizieren können. Nur ein temporärer Shell-Container im richtigen Netzwerk liefert die korrekte Perspektive.

9. Sicherheit: Was temporäre Container dürfen und nicht dürfen

Temporäre Shell-Container sind kein Freifahrtschein für unbeschränkten Produktionszugriff. Die Capability-Anforderungen sollten minimal sein – kein --privileged für normale Diagnose-Aufgaben, kein uneingeschränkter Netzwerk-Zugriff auf alle Container. Das Prinzip der minimalen Rechte gilt auch für Diagnose-Container. Ein Container für DNS-Diagnose braucht keinen Write-Zugriff auf Volumes, ein Container für Log-Analyse braucht keinen Netzwerk-Zugriff.

In automatisierten Umgebungen sollte der Zugriff auf temporäre Shell-Container protokolliert werden. Wer hat wann welchen Befehl in welchem Container ausgeführt? Für Compliance-Anforderungen kann ein Audit-Log über einen Audit-Daemon (auditd) auf dem Host alle docker run-Befehle mitschneiden. In Kubernetes-Umgebungen bieten kubectl debug-Sessions mit Ephemeral Containers das äquivalente Muster für temporäre Diagnose-Container mit integrierter RBAC-Kontrolle.

Ein kritischer Punkt: Temporäre Shell-Container die mit --volume /:/host den gesamten Host-Dateisystembaum mounten, sind keine temporären Container mehr – sie haben Root-Zugriff auf den Host. Ebenso problematisch: docker run --rm -it --pid host ... gibt Zugriff auf alle Prozesse des Hosts. Diese Optionen sollten auf Produktionssystemen nur in echten Notfällen und mit expliziter Genehmigung verwendet werden, und der Vorgang sollte protokolliert werden.

10. Zusammenfassung

Temporäre Shell-Container mit docker run --rm sind das moderne Werkzeug für Container-Diagnose und Wartung. Sie bringen Diagnose-Tools in der richtigen Netzwerk-Perspektive mit, hinterlassen keine Rückstände und sind durch ihre Container-Umgebung präziser als Host-Tools. Namespace-Sharing ermöglicht Einblicke in laufende Container ohne deren Code oder Image zu modifizieren. Spezialisierte Diagnose-Images wie nicolaka/netshoot stellen alle Werkzeuge bereit, die für Netzwerk-, Prozess- und Dateisystem-Diagnose benötigt werden.

Die Investition in Wrapper-Scripts und Makefile-Targets für häufige Shell-Container-Aufgaben macht dieses Muster für das gesamte Team zugänglich. Das Sicherheitsprinzip der minimalen Rechte gilt auch für Diagnose-Container: --privileged nur im echten Notfall, read-only Volume-Mounts für Log-Analyse, Protokollierung aller Diagnose-Sessions in regulierten Umgebungen. Mit diesen Leitlinien sind temporäre Shell-Container eine sicherere und mächtigere Alternative zur klassischen Tool-Installation auf dem Server.

11. FAQ: Temporäre Shell-Container