Dieses Kapitel vermittelt Grundkenntnisse über die Prinzipien von Dockeranwendungen, um zusätzliche Sicherheit im Umgang mit Docker als Übungswerkzeug in Modul 7 zu schaffen.
Dieses Kapitel soll zu einem besseren Verständnis von Docker als Übungswerkzeug beitragen. Die Inhalte sind nicht relevant für die Abschlussprüfung in Modul 7.
Häufig verwendete Begriffe im Umgang mit Docker sind ‘Image’, ‘Container’, ‘Dockerfile’ oder ‘Dockeranwendung’. Im folgenden wird kurz erkläutert, was diese Begriffe bedeuten.
Der Zweck von Docker ist es, spezifische Betriebsumgebungen für Software bereitzustellen, die sich von der Umgebung des sog. Hostsystems, auf dem Docker selbst läuft, unterscheiden. Das Hostsystem kann z.B. ein Server sein, auf dem ein Webportal läuft, aber auch unser eigener Notebook-Computer, den wir für das Modul 7 verwenden. Die für unsere Zwecke benötigte spezifische Betriebsumgebung läuft dann in einem vom Hostsystem weitestgehend isolierten Dockercontainer.
Zum Beispiel kann Docker auf einem Notebook mit Mac OS laufen. Für die Entwicklung einer Webanwendung, die am Ende auf einem Debian-Server laufen soll, wäre Debian-Linux die beste Entwicklungsumgebung. In diesem Fall können wir einen Dockercontainer mit Debian starten und die Anwedung unter den gleichen Bedingungen entwickeln und testen, die für den zukünftigen Produktivserver gelten.
Ein weiteres Beispiel ist die Nutzung von Anwendungen wie z.B. Jupyter Notebooks. Project Jupyter stellt eine Reihe von vorinstallierten und -konfigurierten Notebooks für verschiedene Zwecke bereit, die auf diese Weise schnell genutzt werden können, ohne erst die notwendigen Softwarepakete direkt auf dem Hostsystem einrichten zu müssen.
Die Sturm-Anwendung, die unser Hauptbeispiel für viele Webtechnologien in Modul 7 ist, läuft in einem Container, in dem eine Linux-Distribution, ein PHP-Interpreter, ein Webserver, und verschiedene zuätzliche Hilfspakete installiert sind. Das erspart es uns, all diese Software auf unserem Hostsystem zu installieren (sofern diese überhaupt für unser System verfügbar ist).
Eine Dockeranwendung (oder ‘Docker-App’) ist eine Softwareanwendung, die auf einem oder mehreren Dockercontainern läuft. Viele Dockeanwendungen verwenden nur einen Container, in dem alle erforderlichen Softwarepakete installiert sind, wie die Sturm-Anwendung oder die o.g. Jupyter Notebooks. In diesem Fall sind die Dockeranwendung und der Dockercontainer identisch.
Es ist jedoch auch möglich, eine Dockeranwendung zu erstellen, in dem unterschiedliche Softwarekomponenten in eigenen Containern laufen, die miteinander verbunden sind und Daten austauschen können. Das ist vor allem praktisch, um einzelne Komponenten wie z.B. Datenbanken, schnell und einfach auszutauschen. Dockeranwendungen, die auch mehreren Containern bestehen, können z.B. mit Docker Compose konfiguriert werden.
Die Sturm-Anwendung etwa hätte auch als Multi-Container-Anwendung erstellt werden können: PHP-Interpreter und Webserver hätten in jeweils eigenen Containern installiert werden können.
Um einen Dockercontainer starten zu können, benötigen wir zunächst ein sogenanntes Dockerimage, in dem die Software enthalten ist, die für den lauffähigen Container gebraucht wird. Solche Dockerimages werden von vielen Softwarefirmen und Entwickler:innen bereitgestellt und können aus sog. Container-Registries heruntergeladen werden.
Die wohl bekannteste Container-Registry, die als Standard von Docker verwendet wird, ist der von Microsoft betriebene Docker Hub. GitHub stellt unter https://ghcr.io ebenfalls eine Container-Registry für Nutzer:innen bereit. Darüber hinaus können über GitLab projektbezogene Registries eingerichtet werden, wie z.B. für die Sturm-Anwendung.
Damit Docker einen Container aus dem entsprechenden Image erzeugt, muss ein existierender Imagename an Docker übergeben werden. Beim Start der Sturm-Anwendung mit
docker run --name sturm-app -p 80:80 registry.gitlab.rlp.net/studiengang-digitale-methodik/modul-7/sturm-app-container
verwenden wir das Image registry.gitlab.rlp.net/studiengang-digitale-methodik/modul-7/sturm-app-container. Wie die meisten Imagenamen besteht auch dieser aus zwei Teilen, dem Namespace registry.gitlab.rlp.net/studiengang-digitale-methodik/modul-7 und dem eigentlichen Imagenamen sturm-app-container (sehr Grundlegende Images, wie z.B. Betriebssysteme, verwenden keinen Namespace als Namensteil, z.B. debian oder alpine).
Vorausgesetzt, wir haben uns vorher über Docker beim GitLab RLP angemeldet, fragt Docker beim erstmaligen Start der Sturm-Anwendung bei der Container-Registry des Projekts das Dockerimage an und lädt es auf unser Hostsystem herunter.
Sobald ein Dockerimage einmal auf ein Hostsystem heruntergeladen wurde, wird es bei erneutem Aufbau des Containers direkt von der lokalen Festplatte aus verwendet und die Downloadphase entfällt.
Dockerimages können sich in ihrer Dateigröße stark unterscheiden. Während das Image für die Sturm-Anwendung mit 27.7 MB noch relativ klein ist, können komplexere Images eine Größe von mehreren GB erreichen.
Bei Präsenzveranstaltungen für Modul 7 in der Akademie der Wissenschaften und der Literatur ist die Internetverbindung über das WLAN nur bedingt zum Download von von Dockerimages geeignet, gerade wenn eine Reihe von Nutzer:innen gleichzeitig Downloads starten.
Es empfiehlt sich daher, Dockerimages für Unterrichtseinheiten bereits vorher (wenn möglich, über eine leistungsstärkere Verbindung) herunterzuladen. Das geht mit
docker pull { Name des Dockerimage }
Danach steht das entsprechende Image lokal für spätere Nutzung zur Verfügung.
Auch wenn es bereits fertige Dockerimages für unterschiedlichste Anwendungszwecke gibt, werden wir in Projekten häufig Bedarf an noch spezielleren Containern haben, für die es keine passenden Images gibt.
Eigene Images können mit Hilfe von Dockerfiles erstellt werden. Dockerfiles sind Konfigurationsdateien für Dockerimages, mit denen man sich bedarfsgerechte Images erstellen kann. Diese können dann entweder nur lokal gespeichert und verwendet werden oder in einer ensprechenden Projekt-Container-Registry oder sogar für die breite Öffentlichkeit auf Docker Hub publiziert werden.
Ein recht ausführlich dokumentiertes Beispiel hierfür bietet das Dockerimage für die Sturm-Anwendung.
Dockercontainer werden oft als kurzlebig (’ephemeral’ im Englischen) bezeichnet, da die in ihnen enthaltenen Zustände nur solange bestehen, solange der Container erhalten bleibt. Sobald der Container einmal entfernt wird (z.B. mit docker remove bzw. Klick auf das Löschen-Icon in der Containerübersicht von Docker Desktop), gehen alle im Container generierten Daten unwiderbringlich verloren.
Um Daten unabhängig von der Existenz eines Dockercontainers persistent zu halten, können Verzeichnisse aus dem Hostsystem beim Start einer Dockeranwendung Verzeichnissen innerhalb eines Containers zugeordnet werden (sog. volumes). Daten, die von Prozessen innerhalb eines Containers geschrieben in ein solches Verzeichnis werden, befinden sich dann automatisch im entsprechend zugeordneten Hostverzeichnis und bleiben dort bestehen, wenn der Container entfernt wird.
Mehr Details zu Volumes findet sich in der offiziellen Docker-Dokumentation unter https://docs.docker.com/engine/storage/volumes/.
Viele Arbeitsschritte können über die grafische Oberfläche von Docker Desktop mit wenigen Mausklicks erledigt werden. Dennoch ist es nützlich, auch einige Kommandozeilenbefehle zu kennen, da Docker Desktop nicht in allen Anwendungsfällen zur Verfügung steht (etwa auf einem Remote-Server oder im Zusammenhang einer CI-Konfiguration). Eine Gesamtübersicht findet sich in der offiziellen CLI Reference, die für das Modul 7 relevanten Befehle werden im Folgenden noch einmal beschrieben.
Container als Hintergrundprozess ausführen
docker run --detach
oder
docker run -d
Befehle im Container ausführen:
docker exec { Container-Name } { Befehl }
Auf die Kommandozeile im Container gelangen:
docker exec -it { Container-Name } sh
oder
docker exec -it { Container-Name } bash
Container-Ports mit dem Host verbinden:
docker run --publish { Host-Port }:{ Container-Port }
Host-Ordner Container-Ordnern zuordnen:
docker run --volume { Host-Ordner/Datei }:{ Container-Ordner/Datei }
Software in Containern laufen zu lassen, ist eine Entwicklung, die schon vor und unabhängig von Docker begonnen hat. Das Augreifen dieser Technologie durch Microsoft und die Entwicklung einer grafischen Oberfläche zur bequemen Nutzung hat jedoch deutlich zu ihrer Verbreitung beigetragen.
Es gibt jedoch auch Alternativen zu Docker. Eine davon ist Podman, ein System, das ein GUI analog zu Docker Desktop anbietet und mit den gleichen Images und Konfigurationsdateien für Multi-Container-Anwendungen arbeitet wie Docker bzw. Docker Compose.
Es existieren zudem weiter Containerformate und seit 2015 gibt es die Open Container Initiative zur Festletgung von Industrie-Standards für containerisierte Systeme.