In Docker Compose und Container-Orchestrierungen wie Swarm oder Kubernetes sind Healthchecks essenziell, um die Stabilität und Ausfallsicherheit von Services sicherzustellen. Dabei unterscheidet man zwischen Readiness und Liveness, um festzustellen, ob ein Container bereit für Traffic ist oder ob er neu gestartet werden muss.
1. Grundlagen von Healthchecks
Ein Healthcheck prüft regelmäßig, ob ein Container korrekt funktioniert. Docker bietet dafür die HEALTHCHECK-Instruktion im Dockerfile und die healthcheck-Sektion in Compose-Dateien.
services:
web:
image: myapp:latest
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
interval: 30s
timeout: 10s
retries: 3
test: Befehl, der den Gesundheitszustand prüft.interval: Zeit zwischen zwei Checks.timeout: Maximale Dauer eines Checks.retries: Anzahl der fehlgeschlagenen Checks, bevor der Container als ungesund gilt.
2. Liveness vs. Readiness
Diese beiden Healthcheck-Arten erfüllen unterschiedliche Aufgaben:
Liveness
Ein Liveness-Check prüft, ob ein Container noch läuft und funktionsfähig ist. Scheitert dieser, wird der Container automatisch neu gestartet.
services:
api:
image: myapi:latest
healthcheck:
test: ["CMD-SHELL", "pg_isready -U admin"]
interval: 30s
timeout: 5s
retries: 3
- Hilft, Crashloops zu erkennen und Container automatisch zu recovern.
- Wichtig für langfristige Stabilität und Self-Healing-Mechanismen.
Readiness
Ein Readiness-Check prüft, ob ein Container bereit ist, Traffic zu empfangen. Fehlschläge verhindern, dass der Container in Load-Balancing-Pools aufgenommen wird, lösen aber keinen Neustart aus.
services:
web:
image: myweb:latest
healthcheck:
test: ["CMD-SHELL", "curl -f http://localhost:8080/ready || exit 1"]
interval: 15s
timeout: 5s
retries: 2
- Verhindert, dass Benutzer oder andere Services auf nicht bereite Container zugreifen.
- Besonders relevant beim Hochfahren komplexer Services mit Abhängigkeiten.
3. Healthcheck Design in Compose
Beim Entwurf von Healthchecks sollten folgende Punkte berücksichtigt werden:
- Kurze Checks (<10s), um Blockaden zu vermeiden.
- Intervalle und Retries so setzen, dass temporäre Latenzen toleriert werden.
- Trennung von Liveness und Readiness, wenn Startzeiten variieren oder Init-Prozesse lange dauern.
- Verwendung von
CMD-SHELLfür komplexe Prüfungen oder Pipe-Operationen.
Beispiel Multi-Service
services:
db:
image: postgres:15
healthcheck:
test: ["CMD-SHELL", "pg_isready -U admin"]
interval: 30s
retries: 5
api:
image: myapi:latest
depends_on:
db:
condition: service_healthy
healthcheck:
test: ["CMD-SHELL", "curl -f http://localhost:5000/health || exit 1"]
interval: 20s
retries: 3
- Hier wartet die API auf die gesunde DB bevor sie als bereit gilt.
- Verhindert Startprobleme und Race Conditions zwischen Services.
4. Kombination mit Restart Policies
Healthchecks werden besonders wirksam, wenn sie mit Restart Policies kombiniert werden.
services:
worker:
image: jobrunner:latest
deploy:
restart_policy:
condition: on-failure
healthcheck:
test: ["CMD-SHELL", "check-jobs.sh"]
interval: 30s
retries: 3
- Fehlgeschlagene Liveness-Checks führen so automatisch zu einem Neustart.
- Readiness-Checks verhindern lediglich die Aufnahme in Load-Balancer.
5. Monitoring und Debugging
Zur Beobachtung und Analyse von Healthchecks:
docker pszeigthealthy/unhealthyStatus.docker inspect <container>liefert detaillierte Healthcheck-Ergebnisse.- Logs für fehlerhafte Checks prüfen, z. B.
docker logs <container>. - Bei komplexen Multi-Service-Stacks sollten Healthchecks auf Abhängigkeiten achten.
6. Best Practices
- Für jeden Service eigene Healthchecks definieren, keine globalen Checks.
- Liveness prüft intern, Readiness prüft extern zugängliche Endpunkte.
- Vermeiden von zu kurzen Intervallen, um unnötige Neustarts zu verhindern.
- Healthchecks als Teil der CI/CD-Pipeline testen.
- Dokumentation der Check-Logik, um Team-Konsistenz zu sichern.
7. Troubleshooting
Typische Probleme:
- Container wird ständig als ungesund markiert: Prüfen ob Timeout oder Test-Befehl korrekt ist.
- Readiness falsch implementiert: Container nimmt Traffic zu früh an.
- Liveness zu aggressiv: Container wird unnötig neu gestartet.
- Abhängigkeiten zwischen Services nicht berücksichtigt:
depends_on: condition: service_healthynutzen.
8. Zusammenfassung
Die richtige Trennung von Liveness und Readiness in Docker Compose ermöglicht stabile, ausfallsichere Deployments. Liveness sorgt für Self-Healing, Readiness für kontrollierte Traffic-Aufnahme. Mit abgestimmten Intervallen, Retries und Restart-Policies lassen sich Container-Stacks zuverlässig betreiben und Probleme frühzeitig erkennen.
Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab/GNS3
Ich biete professionelle Unterstützung im Bereich Netzwerkkonfiguration und Network Automation für private Anforderungen, Studienprojekte, Lernlabore, kleine Unternehmen sowie technische Projekte. Ich unterstütze Sie bei der Konfiguration von Routern und Switches, der Erstellung praxisnaher Topologien in Cisco Packet Tracer, dem Aufbau und Troubleshooting von GNS3- und EVE-NG-Labs sowie bei der Automatisierung von Netzwerkaufgaben mit Netmiko, Paramiko, NAPALM und Ansible. Kontaktieren Sie mich jetzt – klicken Sie hier.
Meine Leistungen umfassen:
-
Professionelle Konfiguration von Routern und Switches
-
Einrichtung von VLANs, Trunks, Routing, DHCP, NAT, ACLs und weiteren Netzwerkfunktionen
-
Erstellung von Topologien und Simulationen in Cisco Packet Tracer
-
Aufbau, Analyse und Fehlerbehebung von Netzwerk-Labs in GNS3 und EVE-NG
-
Automatisierung von Netzwerkkonfigurationen mit Python, Netmiko, Paramiko, NAPALM und Ansible
-
Erstellung von Skripten für wiederkehrende Netzwerkaufgaben
-
Dokumentation der Konfigurationen und Bereitstellung nachvollziehbarer Lösungswege
-
Konfigurations-Backups, Optimierung bestehender Setups und technisches Troubleshooting
Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.
