Wie man den docker debug-Befehl zur Fehlerbehebung in Containern und Images verwendet

Einführung

In diesem Lab untersuchen wir, wie man Docker-Container und -Images effektiv mit dem Befehl docker debug und anderen verwandten Techniken debuggt. Wir beginnen mit der Herausforderung, schlanke Container ohne Shell zu debuggen, und zeigen, wie man Befehle direkt in ihrer Umgebung ausführt.

Anschließend lernen wir, wie man ein schlankes Image direkt debuggt, bevor es überhaupt als Container ausgeführt wird. Wir behandeln auch, wie man Dateien in einem laufenden Container für Debugging-Zwecke modifiziert und wie man die Debug-Toolbox mit den Befehlen install und uninstall verwaltet. Abschließend vertiefen wir unser Verständnis von Container-Entrypoints durch die Verwendung des Befehls entrypoint.

Skills Graph

Debugging eines schlanken Containers ohne Shell

In diesem Schritt lernen wir, wie man einen schlanken Container debuggt, der keine installierte Shell besitzt. Schlanke Container werden oft verwendet, um die Image-Größe und Angriffsfläche zu reduzieren, können jedoch schwer zu debuggen sein, wenn Probleme auftreten.

Zuerst starten wir einen einfachen schlanken Container, der eine Nachricht ausgibt und dann beendet. Wir verwenden das alpine-Image, eine sehr kleine Linux-Distribution.

docker run alpine echo "Hello from Alpine!"

Sie sollten die Ausgabe Hello from Alpine! in Ihrem Terminal sehen. Dies bestätigt, dass der Container erfolgreich ausgeführt wurde.

Nun versuchen wir, einen Befehl innerhalb dieses Containers mit docker exec auszuführen. Wir probieren /bin/sh aus, eine gängige Shell.

docker run -d --name slim-container alpine sleep 3600
docker exec -it slim-container /bin/sh

Wahrscheinlich erscheint eine Fehlermeldung, dass /bin/sh nicht gefunden wurde. Das liegt daran, dass das alpine-Image in seiner Standardkonfiguration keine Shell wie bash oder sh enthält. Dies ist typisch für schlanke Container.

Um einen Container ohne Shell zu debuggen, können wir den Befehl docker exec verwenden, um einen spezifischen Befehl in der Container-Umgebung auszuführen. Da jedoch keine Shell vorhanden ist, müssen wir den Befehl direkt ausführen.

Versuchen wir, die Dateien im Root-Verzeichnis des Containers aufzulisten. Der Befehl ls ist normalerweise auch in minimalen Umgebungen verfügbar.

docker exec -it slim-container ls /

Sie sollten eine Liste von Verzeichnissen und Dateien im Root des Container-Dateisystems sehen, wie bin, etc, lib usw. Dies zeigt, dass wir Befehle auch ohne Shell direkt im Container ausführen können.

Abschließend bereinigen wir den erstellten Container.

docker stop slim-container
docker rm slim-container

Dieser Schritt hat gezeigt, wie man mit einem schlanken Container ohne Shell interagiert, indem man Befehle direkt mit docker exec ausführt. In den nächsten Schritten werden wir weitere Debugging-Techniken untersuchen.

Direktes Debugging eines schlanken Images

Im vorherigen Schritt haben wir gelernt, wie man mit einem laufenden schlanken Container interagiert. Manchmal muss man jedoch den Inhalt eines schlanken Images untersuchen, bevor man es als Container ausführt, oder wenn der Container nicht startet. In diesem Schritt untersuchen wir, wie man ein schlankes Image direkt debuggt.

Docker bietet mit dem docker run-Befehl die Möglichkeit, den standardmäßigen Entrypoint und Befehl eines Images zu überschreiben. Dadurch können wir einen anderen Befehl in einem temporären Container ausführen, der aus dem Image erstellt wird, was uns ermöglicht, dessen Inhalt zu inspizieren.

Verwenden wir erneut das alpine-Image. Wir wissen, dass es sich um ein schlankes Image handelt und standardmäßig keine Shell enthält. Mit docker run können wir direkt einen Befehl wie ls / auf dem Image ausführen.

docker run --rm alpine ls /

Das Flag --rm stellt sicher, dass der temporäre Container nach Abschluss des Befehls automatisch entfernt wird. Sie sollten dieselbe Ausgabe sehen wie beim Ausführen von ls / auf dem laufenden Container im vorherigen Schritt. Dies bestätigt, dass wir das Dateisystem des Images direkt inspizieren können.

Lassen Sie uns nun prüfen, ob ein bestimmter Befehl im Image vorhanden ist. Beispielsweise überprüfen wir das Vorhandensein des ping-Befehls.

docker run --rm alpine which ping

Wahrscheinlich erscheint eine Fehlermeldung wie which: not found. Dies zeigt, dass der ping-Befehl im standardmäßigen alpine-Image nicht vorhanden ist. Dies ist ein weiteres Merkmal schlanker Images – sie enthalten oft nur die absolut notwendigen Tools.

Versuchen wir einen Befehl, von dem wir wissen, dass er existiert, wie cat.

docker run --rm alpine which cat

Diesmal sollte die Ausgabe /bin/cat erscheinen, was bestätigt, dass der cat-Befehl im Image verfügbar ist.

Diese Technik mit docker run --rm <image> <command> ist sehr nützlich, um schnell den Inhalt eines Images zu überprüfen, das Vorhandensein bestimmter Dateien oder Befehle zu verifizieren und die Struktur des Images zu verstehen, ohne einen langlebigen Container starten oder ein neues Image bauen zu müssen.

Dateien in einem laufenden Container modifizieren

In diesem Schritt lernen wir, wie man Dateien in einem laufenden Container verändert. Dies kann für Debugging-Zwecke nützlich sein, etwa um Konfigurationsdateien anzupassen oder temporäre Skripte zu einem bereits laufenden Container hinzuzufügen.

Wir beginnen mit der Ausführung eines einfachen Containers basierend auf dem ubuntu-Image, das umfangreicher ist als alpine und eine Shell sowie gängige Utilities enthält.

docker run -d --name my-ubuntu ubuntu sleep 3600

Dieser Befehl startet einen Ubuntu-Container im Detached-Modus (-d) und hält ihn mit dem Befehl sleep 3600 für eine Stunde aktiv. Wir haben den Container zur einfachen Referenz my-ubuntu genannt.

Nun verwenden wir docker exec, um eine Shell innerhalb des laufenden Containers zu öffnen.

docker exec -it my-ubuntu /bin/bash

Sie sollten sich nun in der Bash-Shell des my-ubuntu-Containers befinden. Die Eingabeaufforderung zeigt an, dass Sie im Container sind.

Innerhalb des Containers erstellen wir eine neue Datei im Verzeichnis /tmp.

echo "This is a test file." > /tmp/test_file.txt

Überprüfen wir nun, ob die Datei erstellt wurde und den korrekten Inhalt hat.

cat /tmp/test_file.txt

Die Ausgabe sollte This is a test file. lauten. Dies bestätigt, dass wir erfolgreich eine Datei im laufenden Container erstellen und beschreiben konnten.

Um die Shell des Containers zu verlassen, geben Sie einfach exit ein.

exit

Sie befinden sich nun wieder im Terminal Ihrer LabEx-VM.

Mit dem Befehl docker cp können wir Dateien auch in einen laufenden Container kopieren und daraus extrahieren. Erstellen wir zunächst eine Datei auf unserer LabEx-VM und kopieren sie in den Container.

Erstellen Sie eine Datei namens local_file.txt in Ihrem ~/project-Verzeichnis.

echo "This file is from the host." > ~/project/local_file.txt

Kopieren Sie diese Datei nun in das /tmp-Verzeichnis des my-ubuntu-Containers.

docker cp ~/project/local_file.txt my-ubuntu:/tmp/

Die Syntax für docker cp lautet: docker cp <Quellpfad> <Container-Name>:<Zielpfad> oder docker cp <Container-Name>:<Quellpfad> <Zielpfad>.

Verifizieren wir, ob die Datei in den Container kopiert wurde. Öffnen Sie erneut die Shell des Containers.

docker exec -it my-ubuntu /bin/bash

Prüfen Sie im Container, ob local_file.txt in /tmp vorhanden ist.

ls /tmp/

Sie sollten local_file.txt zusammen mit test_file.txt aufgelistet sehen.

Sehen wir uns nun den Inhalt von local_file.txt im Container an.

cat /tmp/local_file.txt

Die Ausgabe sollte This file is from the host. lauten.

Verlassen Sie die Shell des Containers erneut.

exit

Abschließend bereinigen wir den Container.

docker stop my-ubuntu
docker rm my-ubuntu

Dieser Schritt hat gezeigt, wie man Dateien in einem laufenden Container mit docker exec und Standard-Linux-Befehlen modifiziert sowie wie man Dateien zwischen Host und Container mit docker cp austauscht.

Debugging-Toolbox mit install und uninstall verwalten

In diesem Schritt untersuchen wir, wie man Debugging-Tools in einem laufenden Container hinzufügt und entfernt. Obwohl es generell empfohlen wird, Produktions-Container-Images minimal zu halten, benötigt man manchmal temporäre Tools für Debugging-Zwecke.

Wir verwenden erneut das ubuntu-Image, da es einen Paketmanager (apt) besitzt, der die Softwareinstallation vereinfacht.

Zuerst starten wir einen neuen Ubuntu-Container im Detached-Modus.

docker run -d --name debug-ubuntu ubuntu sleep 3600

Nun öffnen wir eine Shell innerhalb des Containers.

docker exec -it debug-ubuntu /bin/bash

Innerhalb des Containers versuchen wir, einen nicht standardmäßig installierten Befehl wie ping zu verwenden.

ping google.com

Wahrscheinlich erscheint ein "command not found"-Fehler.

Um ping und andere Netzwerk-Tools zu installieren, können wir den apt-Paketmanager nutzen. Zuerst aktualisieren wir die Paketliste.

apt update

Dieser Befehl lädt die neuesten Informationen über verfügbare Pakete aus den Repositories.

Nun installieren wir das Paket iputils-ping, das den ping-Befehl bereitstellt.

apt install -y iputils-ping

Das Flag -y bestätigt die Installation automatisch ohne Nachfrage.

Nach Abschluss der Installation sollte der ping-Befehl verfügbar sein.

ping -c 4 google.com

Die Ausgabe des ping-Befehls zeigt, dass er nun im Container funktioniert.

Nach Abschluss des Debuggings sollten Sie alle installierten Tools entfernen, um den Container sauber zu halten und seine Größe zu reduzieren (auch wenn Modifikationen an laufenden Containern für Produktionsumgebungen generell nicht empfohlen werden).

Um das iputils-ping-Paket zu entfernen, verwenden wir apt remove.

apt remove -y iputils-ping

Wir können überprüfen, ob ping nicht mehr verfügbar ist.

ping google.com

Der "command not found"-Fehler sollte wieder erscheinen.

Verlassen Sie die Container-Shell.

exit

Abschließend bereinigen wir den Container.

docker stop debug-ubuntu
docker rm debug-ubuntu

Dieser Schritt zeigte, wie man Debugging-Tools temporär in einem laufenden Container installiert und deinstalliert. Diese Technik ist wertvoll für die Fehlerbehebung in Containern, in denen notwendige Tools nicht im Basis-Image enthalten sind.

Container-Entrypoints mit dem entrypoint-Befehl verstehen

In diesem Schritt lernen wir die ENTRYPOINT-Anweisung in einer Dockerfile kennen und wie sie die Ausführung eines Containers beeinflusst. Der ENTRYPOINT definiert den Befehl, der beim Start eines Containers ausgeführt wird. Er wird häufig verwendet, um das Hauptprogramm des Containers festzulegen.

Erstellen wir eine einfache Dockerfile mit ENTRYPOINT. Legen Sie im Verzeichnis ~/project eine Datei namens Dockerfile mit folgendem Inhalt an:

FROM alpine
ENTRYPOINT ["echo", "Hello from the entrypoint!"]
CMD ["default", "command"]

Diese Dockerfile verwendet das alpine-Image als Basis. Der ENTRYPOINT ist auf ["echo", "Hello from the entrypoint!"] gesetzt. Der CMD ist auf ["default", "command"] festgelegt. Wenn sowohl ENTRYPOINT als auch CMD angegeben sind, werden die CMD-Argumente als Parameter an den ENTRYPOINT-Befehl übergeben.

Nun bauen wir ein Image aus dieser Dockerfile.

docker build -t my-entrypoint-image ~/project

Dieser Befehl erstellt ein Image namens my-entrypoint-image aus der Dockerfile im Verzeichnis ~/project.

Starten wir nun einen Container aus diesem Image ohne zusätzliche Befehle.

docker run my-entrypoint-image

Die Ausgabe sollte lauten: Hello from the entrypoint! default command. Dies zeigt, dass der ENTRYPOINT-Befehl (echo) ausgeführt wurde und die CMD-Argumente (default command) übergeben wurden.

Nun starten wir den Container mit einem anderen Befehl in der docker run-Zeile. Wenn Sie einen Befehl in der docker run-Zeile angeben, überschreibt dieser die CMD-Anweisung in der Dockerfile, aber der ENTRYPOINT wird weiterhin mit dem angegebenen Befehl als Argument ausgeführt.

docker run my-entrypoint-image "override command"

Die Ausgabe sollte lauten: Hello from the entrypoint! override command. Dies zeigt, dass der ENTRYPOINT weiterhin ausgeführt wurde, aber die Argumente aus dem docker run-Befehl (override command) die CMD-Argumente ersetzt haben.

Was, wenn Sie den ENTRYPOINT komplett ignorieren und einen anderen Befehl ausführen möchten? Sie können das Flag --entrypoint mit docker run verwenden.

docker run --entrypoint /bin/echo my-entrypoint-image "Running a different command"

Die Ausgabe sollte lauten: Running a different command. In diesem Fall hat das --entrypoint-Flag den in der Dockerfile angegebenen ENTRYPOINT überschrieben, und der angegebene Befehl (/bin/echo) wurde mit den Argumenten (Running a different command) ausgeführt.

Das Verständnis von ENTRYPOINT und CMD ist entscheidend für das Erstellen und Debuggen von Docker-Images. ENTRYPOINT definiert das Hauptprogramm, während CMD Standardargumente für dieses Programm bereitstellt oder einen Standardbefehl, falls kein ENTRYPOINT gesetzt ist.

Zusammenfassung

In diesem Lab haben wir gelernt, wie man Docker-Container und -Images mit dem docker debug-Befehl und verwandten Techniken debuggt. Wir begannen mit der Untersuchung, wie man einen schlanken Container ohne Shell debuggt, und zeigten, dass wir Befehle direkt in der Container-Umgebung mit docker exec ausführen können, selbst ohne eine traditionelle Shell wie bash oder sh. Dies ist eine entscheidende Technik für die Fehlerbehebung in minimalen Container-Images.

Obwohl der bereitgestellte Inhalt nur den ersten Schritt abdeckt, deutet die Gesamtstruktur des Labs darauf hin, dass die folgenden Schritte das direkte Debuggen schlanker Images, das Modifizieren von Dateien in laufenden Containern, das Verwalten der Debug-Toolbox mit Installations- und Deinstallationsbefehlen sowie das Verständnis von Container-Entrypoints mit dem entrypoint-Befehl behandeln würden. Diese Schritte würden unsere Fähigkeit weiter verbessern, Probleme in Dockerisierten Anwendungen und Images zu diagnostizieren und zu beheben.