Docker-Einführung, Teil 6 Docker-Clients, Konfiguration und wichtige Befehle

Docker-Nutzer dürften traditionell keine Berührungsängste mit Kommandozeilen haben. CLI-Befehle sind zur Konfiguration und Steuerung der schnellste Weg. Mit Kitematic steht für Einsteiger aber auch ein grafischer Client bereit, insbesondere zum Einrichten von Storage und Netzwerk-Funktionen.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Der grafische Client Kitematic ist im Umfeld von Docker für Windows entstanden und bisher auch nur für Windows und Mac OS offiziell verfügbar. Genau genommen ist Kitematic ein Open-Source-Projekt, das zur Vereinfachung und Rationalisierung von Docker auf einem Mac oder Windows-PC entwickelt wurde.

Auch die in Teil 5 gezeigte Docker-Installation unter Windows vor Version 10 basiert auf Kitematic, d. h. Kitematic ist nicht nur ein User-Interface zum Ausführen von Docker-Containern, sondern automatisiert auch den Installations- und Einrichtungsprozess, wenn Docker nicht unter Windows 10 auf Basis von Hyper-V bereitgestellt wird.

Dazu integriert sich Kitematic in Docker Machine, um eine VirtualBox-VM bereitzustellen und die Docker Engine lokal zu installieren. Unter Windows 10 (Docker CE für Windows) kann man Kitematic über das Systray nachträglich installieren und starten.

Die Kitematic-GUI zeigt auf dem Startbildschirm eine Art Kachel-Ansicht „aller“ momentan verfügbaren Images, d. h. der Filter-Selektor rechts oben steht per Default auf „All“. Hier kann der Nutzer jederzeit die Ansicht nach „Recommended“, „My Repos“ oder „My Images“ umschalten. Im Abschnitt links werden die aktuell laufenden Container angezeigt.

Der Nutzer kann hier bequem z. B. nach öffentlichen Images auf Docker Hub oder seinen eigenen, ggf. privaten Repositories suchen, wozu man das Filterfeld oben in der Mitte verwendet. Man kann die GUI aber auch zum Erstellen, Ausführen und Verwalten von Containern nutzen, indem man auf die jeweilige Kachel und dort auf „Create“ klickt. Dabei kann der Nutzer nach Belieben zwischen der Docker CLI und der GUI hin- und herwechseln.

Kitematic automatisiert außerdem erweiterte Funktionen wie das Verwalten von Ports/Networks und das Konfigurieren von Volumes. Zudem lässt sich das Tool nutzen, um Umgebungsvariablen, Stream-Protokolle und Single-Click-Terminals aus der GUI im gewünschten Docker-Container zu ändern. Wer jetzt auf den Geschmack gekommen ist, findet auf GitHub auch eine Kitematic-Version für Ubuntu. Statt einer aufwendigen Installation kann man recht einfach Ubuntu-Kitematic als Container bei Docker Hub beziehen und ausführen.

Der Aufruf ist zwar „quick and dirty“, sollte aber funktionieren. Doch zurück zur GUI. Einen Container aus dem Image-Repository zu starten ist einfach. Dazu genügt ein Klick auf die Schaltfläche „Create“ der jeweiligen Kachel. Mit den drei Punkten links davon sieht man auf einem Blick das gewählte Tag, den Netzwerkmodus (Default=Bridge) und hat die Möglichkeit, direkt zur Ansicht in Docker Hub zu wechseln.

Man kann aber auch bereits laufende (z. B. ohne Kitematic gestartete) Container einsehen und konfigurieren. Hierzu klickt man den gewünschten Container in der Container-Liste links an. Die Benutzeroberfläche zeigt dann im Hauptfenster das aktuelle Container-Log, im Bereich rechts oben die IP-Konfiguration samt Port-Mappings und rechts unten die verwendeten Volumes (hier nur /var/lib/sql). Für eine Datenbank besteht also Handlungsbedarf in Form der Bereitstellung persistenten Speichers.

Am oberen Rand des Dialoges finden sich Schaltflächen zum Stoppen (STOP), Neustarten (RESTART), Ausführen (EXEC) und zum Aufrufen der zugehörigen Seite auf Docker Hub (DOCS). Die korrespondierenden Docker-CLI-Kommandos sind „docker run“, „docker exec“, „drocker rm“, „docker kill“ oder „docker restart“.

Docker-Kommandos

Spätestens hier – vermutlich auch schon eher – sollte sich dem ambitionierten User die Frage stellen, worin der Unterschied zwischen „docker run“ und „docker exec“ besteht. Sowohl „docker run“ als auch „docker exec“ führen Befehle in einem Docker-Container aus. Der Run-Befehl wird verwendet, um einen Befehl in einem „neuen“ Container auszuführen.

Kleines Docker-Tutorial

Bildergalerie mit 7 Bildern

Existiert also noch kein Container, kann man mit „docker run“ einen neuen Container erstellen, starten und dann einen Prozess oder das gewünschte Default-Kommando ausführen; so ließe sich z. B. mysqld im Daemon-Modus starten oder ein spezielles Kommando in der Shell ausführen und den Container dann wieder beenden. Beim Run-Aufruf gibt man wie gesehen das Image an, aus dem der Container erstellt werden soll. Darüber hinaus gibt es optionale Argumente, wie z. B.

Der Befehl erstellt einen Container mit dem Namen „ubuntu_bash“ und startet darin eine Bash-Sitzung. Die Liste möglicher CLI-Argumente für docker run ist lang. Hier sorgt -t (--tty) für das Zuweisen einer Pseudo-TTY und -i (--interactive) steht für den interaktiven-Modus, während –rm dafür sorgt, dass der Container entsorgt wird, wenn der User die Bash beendet.

Der Befehl „docker exec“ hingegen kommt zum Einsatz, wenn man (sozusagen von außen) einen Befehl in einem vorhandenen Container ausführen möchten. Die allgemeine Syntax ist ...

Auch docker exec bietet eine Reihe von Optionen und Argumenten. So könnte man wieder eine interaktive Bash-Shell in einem bestehenden Container mit dem Namen ubuntu_bash starten:

Genauso gibt es Unterschiede zwischen „docker rm“, „docker stop“ und „docker kill“. Mit allen lässt sich ein laufender Container stoppen. Mit „docker stop“ versucht Docker, den Prozess im Container auf die korrekte Weise zu stoppen. Es sendet also erst SIGTERM und dann SIGKILL nach Ablauf einer bestimmten Frist, während „docker kill“ den laufenden Container (bzw. dessen Hauptprozess via SIGKILL) direkt abwürgt.

Allerdings behält „docker stop“ den Container in der via „ps -a“ erreichbaren Listenansicht, was dem Nutzer die Möglichkeit gibt, den Status in einem neuen Image speichern zu können. Hingegen entfernt „docker rm“ den Container aus der Liste, wodurch der Container seinen Status (also die geschichteten Dateisysteme „oberhalb“ des Image-Dateisystem) verliert. Übrigens kann ein laufender Container deshalb nicht mit „docker rm“ entfernt werden, es sei denn, er wird mit -f aufgerufen. In diesem Fall wird SIGKILL direkt gesendet.

Doch zurück zur Kitematic-UI. Diese hilft vor allem beim Einrichten von Netzwerk- und Storage-Funktionen; beides Themen die noch einer umfassenden Betrachtung in künftigen Teilen dieser Workshop-Serie bedürfen. Für den Anfang sollen ein paar grundlegende Handreichungen genügen, die sich mit Kitematic sehr einfach umsetzen lassen.

Für das Einrichten von Portmappings klickt man z. B. bei laufendem Container rechts oben auf „Settings“ und dann auf den Tab „Hostname / Ports“. Hier lässt sich z. B. auf einfache Weise eine Zuordnung von Docker-Ports (z. B. 3306) auf Host-Posts (z. B. ebenfalls 3306, Default ist 32768 und Folgende) einrichten. Um den Ziel-Port auf dem Docker-Host einzugeben oder einzutragen, klickt man einfach in das Feld rechts neben dem Hostnamen und anschließen auf „Save“.

Dass der Container Ports des Hosts überhaupt erreichen kann setzt voraus, dass der Container über eine Netzwerk-Anbindung verfügt, die per Default den Bridge-Treiber verwendet – sich also im Bridge-Modus befindet. Die Einstellung findet man im Tab „Network“. Seit der Docker-Version 1.9 stellen Netzwerke die beste und effizienteste Methode dar, um Verbindungen und den Traffic zwischen Containern zu verwalten.

Vor Docker 1.9 gab es das Konzept der „Links“ – heute ein Legacy-Feature, dem wir uns in einem künftigen Teil zuwenden. Per Default erstellt Docker heute eine Bridge, sodass jeder Container im Netzwerk mit jedem anderen Container kommunizieren kann. Das Gerät heißt „docker0“.

Um die Gegenseite der Bridge „im“ Container so zu betrachten, erstellen wir zwei neue interaktive Ubuntu-Container mit Bash …

... und schauen (in einer neuen Terminal-Sitzung auf dem Host) mit …

… jeweils „in“ den laufenden Container quasi hinein, um an die gewünschten Metadaten zu kommen.

Der erste Container hat die IP 172.17.0.2 erhalten, als Gateway fungiert die Host-Bridge auf 172.17.0.1. Der zweite Container erhält dann 172.17.0.3. Mehr zu Container-Netzwerken mit Docker in einem künftigen Beitrag.

Auch die Storage-Einstellungen lassen sich mit Kitematic zumindest sehr komfortabel einsehen. Hierzu wechselt man bei laufenden Container zum Tab „Volumes“. Um ein neues persistentes Volume in einen neu zu erstellenden Container einzuhängen (z. B. ein Ordner auf dem Host), startet man den betreffenden Container mit der Option –v <Pfad>., z. B.

Jetzt könnte man annehmen, dass dies bei Docker-für-Windows fehlschlägt, weil der Docker-Host ja eine VM ist. Dem ist natürlich nicht so. Die Implementation maskiert die virtuelle Maschine wie in Teil 1 erwähnt komplett, d. h. ein Drive-Map zielt natürlich immer auf den Windows-Host als Quasi-Container-Host.

Lediglich bei der Pfad-Notation muss man sich an Windows-Gepflogenheiten halten. Dies wird allerdings erst nach dem Aktivieren der Laufwerkfreigaben für Docker funktionieren. Dazu klickt man im Docker-Systray auf „Settings“ und aktiviert dann im Reiter „Shared Drives“ die gewünschten Laufwerke.

Kleines Docker-Tutorial

Bildergalerie mit 7 Bildern

(ID:45492764)