Debugging Docker
Last updated
Was this helpful?
Last updated
Was this helpful?
Docker ist eine feine Sache, doch die Fehlersuche gestaltet sich hin und wieder zum Albtraum, da der Container zunächst mal irgendwie nicht greifbar ist - insbesondere nicht, wenn er nicht mehr läuft. Die Fehlersuche hat mich anfangs vor ein ziemliches Problem gestellt und dazu bewogen, die Docker-Konzepte zunächst mal ansatzweise zu verstehen. Nichtsdestotrotz stand ich auch danach erst mal wie der Ochs vorm Berg.
Wenn ein Docker Container nicht schon beim Start stirbt oder gleich nach dem Start beendet wird (weil nur ein paar Befehle ausgefĂźrt werden), dann ist die Fehlersuche schon mal einfacher.
Per docker logs myContainer kann man sich die Logs des Container anschauen - das funktioniert auch mit nicht mehr laufenden Containern (siehe docker ps -a).
Per docker exec -it myRunningContainer bash kann man sich eine Shell im Container ergattern und ein wenig rumschnĂźffeln.
Problematisch finde ich, daĂ in den meisten Images nicht mal die einfachsten Tools (z. B. less) verfĂźgbar sind (natĂźrlich nicht, denn die Images sind i. a. minimal). Die Nutzung von Analyse-Tools ist somit erst gar nicht mĂśglich.
Allerdings lassen sich diese Tools on-the-fly nachinstallieren. Hierzu Ăśffnet man eine Konsole im Container (docker exec -it myRunningContainer bash) und installiert die Software (z. B. apt-get install telnet) mit dem jeweiligen Paketmanager.
Mitdocker inspect myContainer erhält man Informationen ßber den Container - das funktioniert auch mit nicht mehr laufenden Containern (siehe docker ps -a).
Per
erhält man auf der Konsole zusätzliche Informationen wie diese:
Am besten fĂźhrt man diesen Befehl in einem anderen Konsolenfenster aus, damit sich die Informationen nicht so mitten rein mischen.
Wenn ein Docker Container schon beim Start stirbt, dann ist die Fehlersuche schwieriger.
... funktioniert auch bei beendeten Containern - siehe oben
... funktioniert auch bei beendeten Containern - siehe oben
Wenn der Container schon beim Starten abraucht, so kann am Entrypoint des Images liegen, der fßr die Initialisierung des Containers zuständig ist. Hier wird ein Container des Images panubo/vsftpd gestartet, ohne den Entrypoint des Images auszufßhren:
Auf diese Weise erhält man eine Konsole auf dem Container und kann das Entrypoint-Script evtl. manuell ausfßhren und so den Fehler reproduzieren.