Debugging Docker

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.

---

Container läuft noch

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.

Logs anschauen

• siehe auch hier

Per docker logs myContainer kann man sich die Logs des Container anschauen - das funktioniert auch mit nicht mehr laufenden Containern (siehe docker ps -a).

Befehle im Container

Per docker exec -it myRunningContainer bash kann man sich eine Shell im Container ergattern und ein wenig rumschnüffeln.

Installation von Tools

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.

Konfiguration anschauen

Mitdocker inspect myContainer erhält man Informationen über den Container - das funktioniert auch mit nicht mehr laufenden Containern (siehe docker ps -a).

docker events

Per

docker events

erhält man auf der Konsole zusätzliche Informationen wie diese:

137 pfh@workbench ~ % docker events                                                                                                                                     :(
2016-09-12T13:25:39.211049880+02:00 container create 55260...
	(image=mobi3006/glassfish:3.1.2.2, name=nostalgic_bohr)
2016-09-12T13:25:39.212171664+02:00 container attach 55260...
	(image=mobi3006/glassfish:3.1.2.2, name=nostalgic_bohr)
2016-09-12T13:25:39.230392314+02:00 network connect fdd42...
	(container=55260..., name=bridge, type=bridge)
2016-09-12T13:25:39.233426688+02:00 volume mount ffadc...
	(container=55260..., destination=/mnt/containerContributions/artifacts, driver=local, propagation=, read/write=true)
2016-09-12T13:25:39.233447617+02:00 volume mount e3ebb...
	(container=55260..., destination=/mnt/containerContributions/config, driver=local, propagation=, read/write=true)
2016-09-12T13:25:39.378383107+02:00 container start 55260...
	(image=mobi3006/glassfish:3.1.2.2, name=nostalgic_bohr)
2016-09-12T13:25:39.379673101+02:00 container resize 5526...
	(height=35, image=mobi3006/glassfish:3.1.2.2, name=nostalgic_bohr, width=171)
2016-09-12T13:25:39.416374044+02:00 container die 55260...
	(exitCode=99, image=mobi3006/glassfish:3.1.2.2, name=nostalgic_bohr)
2016-09-12T13:25:39.526018442+02:00 network disconnect fdd42...
	(container=55260..., name=bridge, type=bridge)
2016-09-12T13:25:39.550278951+02:00 volume unmount ffadc...
	(container=55260..., driver=local)
2016-09-12T13:25:39.550304339+02:00 volume unmount e3ebb...
	(container=55260..., driver=local)

Am besten führt man diesen Befehl in einem anderen Konsolenfenster aus, damit sich die Informationen nicht so mitten rein mischen.

---

Container stirbt beim Start

Wenn ein Docker Container schon beim Start stirbt, dann ist die Fehlersuche schwieriger.

Logs anschauen

... funktioniert auch bei beendeten Containern - siehe oben

Konfiguration anschauen

... funktioniert auch bei beendeten Containern - siehe oben

Shellzugriff durch Einschränkung der Initialisierungsroutine

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:

docker run -t -it panubo/vsftpd /bin/bash

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.