Docker – Grundlagen, Images, Container und Compose

Einführung

Was ist ein Container

Definition

Ein Container ist ein Prozess auf dem Host-System, der durch Kernel-Funktionen von den übrigen Prozessen abgeschottet wird. Er bringt sein eigenes Dateisystem, seinen eigenen Netzwerk-Stack und seinen eigenen Prozessbaum mit, benutzt aber den Kernel des Hosts.

Was ein Container mitbringt

die Anwendung selbst
die Laufzeitumgebung (z.B. Python, Node.js, Java)
die benötigten Bibliotheken und Werkzeuge
die Konfigurationsdateien
die Umgebungsvariablen

Die zwei Kernel-Mechanismen dahinter

Mechanismus	Aufgabe
Namespaces	Trennt Sichtbarkeit: eigener Prozessbaum, eigenes Netzwerk, eigene Mountpoints, eigene Benutzer-IDs
cgroups	Begrenzt Verbrauch: CPU, Arbeitsspeicher, Block-I/O

Die Ausgangslage ohne Container

"Auf meinem Rechner läuft es"

Eine Anwendung wird auf dem Arbeitsplatz entwickelt und getestet, auf dem Server läuft sie nicht. Ursache sind Unterschiede in der Betriebssystemversion, in den Versionen der installierten Software, in den Bibliotheken und in der Konfiguration.

Abhängigkeitskonflikte

Zwei Anwendungen auf demselben Server brauchen dieselbe Bibliothek in unterschiedlichen Versionen. Installiert werden kann nur eine davon.

Ressourcenverbrauch

Der klassische Ausweg war eine virtuelle Maschine je Anwendung. Jede davon bringt ein vollständiges Betriebssystem mit und belegt Arbeitsspeicher, Plattenplatz und CPU-Zeit, obwohl nur ein einzelner Dienst darin läuft.

Trennung von Diensten

Auf einem gemeinsam genutzten Server beeinflussen sich Dienste gegenseitig. Ein Update für den einen kann den anderen stillegen.

Container und virtuelle Maschine

Virtuelle Maschine

Ein Hypervisor stellt virtuelle Hardware bereit. Darauf läuft ein vollständiges Betriebssystem mit eigenem Kernel.

Container

Die Container-Laufzeit startet einen isolierten Prozess auf dem vorhandenen Kernel. Es wird kein zweites Betriebssystem gebootet.

	Virtuelle Maschine	Container
Kernel	eigener Kernel je VM	gemeinsamer Kernel des Hosts
Startzeit	Sekunden bis Minuten	Millisekunden
Größe	mehrere Gigabyte	wenige Megabyte bis wenige hundert Megabyte
Isolation	durch Virtualisierung, sehr stark	durch Kernel-Funktionen, schwächer
Fremde Kernel	möglich (Windows auf Linux-Host)	nicht möglich

Aufbau im Vergleich

Virtuelle Maschine              Container
+---------------------+        +---------------------+
|     Anwendung       |        |     Anwendung       |
+---------------------+        +---------------------+
|      Gast-OS        |        |  Container-Laufzeit |
+---------------------+        +---------------------+
|     Hypervisor      |        |                     |
+---------------------+        |      Host-OS        |
|      Host-OS        |        |                     |
+---------------------+        +---------------------+
|      Hardware       |        |      Hardware       |
+---------------------+        +---------------------+

Konsequenz für die Praxis

Auf einem Linux-Host laufen Container mit Debian, Ubuntu, Alpine oder Rocky Linux nebeneinander, weil nur die Userland-Dateien unterschiedlich sind. Ein Windows-Container läuft auf einem Linux-Host nicht.

Aufbau von Docker

Komponente	Aufgabe
Docker-Client (`docker`)	Kommandozeilenwerkzeug, nimmt die Befehle entgegen und schickt sie an den Daemon
Docker-Daemon (`dockerd`)	Dienst auf dem Host, verwaltet Images, Container, Netzwerke und Volumes
containerd / runc	Startet und überwacht die eigentlichen Container-Prozesse
Registry	Server, auf dem Images liegen (Docker Hub oder eine eigene Registry)

Zusammenspiel

Benutzer --> docker --> dockerd --> containerd --> Container
                          |
                          v
                       Registry

Kommunikationsweg

Der Client spricht den Daemon über den Unix-Socket /var/run/docker.sock an. Wer auf diesen Socket schreiben darf, hat vollen Zugriff auf den Host.

Begriffe

Begriff	Bedeutung
Image	Unveränderliche Vorlage, aus der Container erzeugt werden
Container	Laufende Instanz eines Images
Dockerfile	Textdatei mit der Bauanleitung für ein Image
Registry	Ablage für Images
Volume	Von Docker verwalteter Speicherbereich für dauerhafte Daten
Compose	Werkzeug, um mehrere Container aus einer YAML-Datei gemeinsam zu betreiben

Übung

Zeichnen Sie auf dem Blatt zwei Stapel nebeneinander: einmal Hardware → Host-OS → Hypervisor → Gast-OS → Anwendung, einmal Hardware → Host-OS → Container-Laufzeit → Anwendung.
Notieren Sie zu jeder der folgenden Anforderungen, ob Sie eine VM oder einen Container wählen würden, und warum: eigener Kernel mit eigenem Modul, 30 gleichartige Webdienste auf einem Host, Windows-Server-Dienst auf einem Debian-Host, Testumgebung die in Sekunden neu aufgebaut werden muss.

Installation unter Debian

Ausgangslage

Alle Übungen laufen auf einer Debian-VM in VirtualBox. Die Pakete aus dem Debian-Repository (docker.io) hinken der Entwicklung hinterher und enthalten das Compose-Plugin nicht. Deshalb wird das offizielle Docker-Repository eingebunden.

Paketquelle einbinden

Grundpakete installieren

sudo apt update
sudo apt install -y ca-certificates curl

Angabe	Bedeutung
`-y`	Rückfragen werden automatisch mit Ja beantwortet
`ca-certificates`	Wurzelzertifikate, damit HTTPS-Downloads geprüft werden können
`curl`	Werkzeug zum Herunterladen des Signaturschlüssels

Verzeichnis für den Signaturschlüssel anlegen

sudo install -m 0755 -d /etc/apt/keyrings

Angabe	Bedeutung
`-m 0755`	Rechte des angelegten Verzeichnisses
`-d`	Es wird ein Verzeichnis statt einer Datei angelegt

Signaturschlüssel holen

sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

Angabe	Bedeutung
`-f`	Bei HTTP-Fehlern keine Fehlerseite speichern, sondern abbrechen
`-s`	Keine Fortschrittsanzeige
`-S`	Fehlermeldungen trotz `-s` anzeigen
`-L`	Weiterleitungen folgen
`-o`	Zieldatei
`a+r`	Leserecht für alle, damit apt den Schlüssel lesen kann

Hinweis

apt-key gibt es nicht mehr. Schlüssel liegen heute als Datei unter /etc/apt/keyrings und werden in der Paketquelle über signed-by genau dieser einen Quelle zugeordnet.

Paketquelle eintragen

vim /etc/apt/sources.list.d/docker.list

deb [arch=amd64 signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/debian trixie stable

Angabe	Bedeutung
`arch=amd64`	Nur die 64-Bit-Intel/AMD-Architektur wird geladen
`signed-by=…`	Nur mit diesem Schlüssel signierte Pakete werden aus dieser Quelle akzeptiert
`trixie`	Codename der Debian-Version; bei einer anderen Debian-Version hier anpassen
`stable`	Der stabile Zweig des Docker-Repositories

Docker installieren

sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Paket	Inhalt
`docker-ce`	Der Daemon
`docker-ce-cli`	Das Kommando `docker`
`containerd.io`	Die darunterliegende Container-Laufzeit
`docker-buildx-plugin`	Der aktuelle Build-Unterbau (BuildKit)
`docker-compose-plugin`	Das Unterkommando `docker compose`

Installation prüfen

Version des Clients und des Daemons

docker version

Dienst-Status

systemctl status docker

Systemweite Informationen

docker info

Funktionstest

sudo docker run --rm hello-world

Angabe	Bedeutung
`--rm`	Der Container wird nach dem Ende automatisch gelöscht

Docker ohne sudo benutzen

sudo usermod -aG docker $USER
newgrp docker

Angabe	Bedeutung
`-a`	Gruppe hinzufügen, bestehende Gruppen bleiben erhalten
`-G`	Betrifft die Nebengruppen
`newgrp docker`	Die neue Gruppe gilt sofort in dieser Sitzung, ohne Neuanmeldung

Sicherheitshinweis

Mitglieder der Gruppe docker dürfen den Docker-Socket ansprechen und darüber Container mit vollen Hostrechten starten. Diese Gruppenmitgliedschaft ist gleichwertig mit Root-Rechten auf dem Host.

Aufbau der Kommandozeile

Grundmuster

docker [Objekt] [Aktion] [Optionen] [Argumente]

Beispiel

docker container ls -a

Kurzformen

Häufige Kommandos gibt es zusätzlich ohne Objekt: docker ps statt docker container ls, docker images statt docker image ls.

Übung

Installieren Sie Docker auf Ihrer Debian-VM über das offizielle Repository.
Prüfen Sie mit docker version, dass Client und Server dieselbe Version melden.
Nehmen Sie Ihren Benutzer in die Gruppe docker auf und starten Sie docker run --rm hello-world ohne sudo.
Lassen Sie sich mit docker info anzeigen, welcher Storage-Treiber verwendet wird.

Images

Was ist ein Image

Ein Image ist eine unveränderliche Vorlage. Es enthält ein fertiges Dateisystem und die Angabe, welches Kommando beim Start ausgeführt wird. Aus einem Image lassen sich beliebig viele Container erzeugen.

Beim Start eines Containers legt Docker über die schreibgeschützten Image-Schichten eine dünne beschreibbare Schicht. Alle Änderungen im laufenden Container landen dort und sind mit dem Container weg.

Layer

Ein Image besteht aus übereinanderliegenden Schichten. Jede Anweisung im Dockerfile erzeugt eine Schicht.

Schicht	Inhalt
1	Debian-Basis
2	Systempakete nachinstalliert
3	Python-Abhängigkeiten installiert
4	Anwendungscode kopiert

Vorteile

Beim Neubau werden nur die Schichten ab der geänderten Anweisung neu erzeugt, der Rest kommt aus dem Cache
Mehrere Images teilen sich gemeinsame Basisschichten
Jede Schicht liegt nur einmal auf der Platte

Overlay-Dateisystem

Docker legt die Schichten mit overlay2 übereinander. Sichtbar ist immer die oberste Fassung einer Datei. Wird eine Datei aus einer unteren Schicht geändert, kopiert der Kernel sie zuerst in die beschreibbare Schicht (Copy-on-Write) und ändert erst dann die Kopie.

Registries und Namensformat

Vollständiger Name eines Images

[Registry/][Namensraum/]Repository[:Tag]

Angabe	Beispiel	Bedeutung
Registry	`docker.io`	Server; fehlt die Angabe, wird Docker Hub benutzt
Namensraum	`library`	Konto oder Organisation; `library` steht für die offiziellen Images
Repository	`debian`	Name des Images
Tag	`13`	Version; fehlt die Angabe, wird `latest` benutzt

Gleichbedeutend

debian:13
docker.io/library/debian:13

Hinweis zu latest

latest ist kein Versionshinweis, sondern nur ein Tag-Name wie jeder andere. In Kursumgebungen und im Betrieb immer eine feste Version angeben.

Images herunterladen

docker pull debian:13
docker pull caddy:2

Images auflisten

docker images

Ausgabe

REPOSITORY   TAG       IMAGE ID       CREATED        SIZE
nginx        1.29      3b4a1c2f9e70   2 weeks ago    192MB
debian       13        7c9e5d1a4b83   3 weeks ago    117MB

Spalte	Bedeutung
REPOSITORY	Name des Images
TAG	Version
IMAGE ID	Eindeutige Kennung
CREATED	Zeitpunkt, an dem das Image gebaut wurde
SIZE	Größe

Ausgabe auf bestimmte Spalten begrenzen

docker images --format "table Vorlage:.Repository\tVorlage:.Tag\tVorlage:.Size"

Angabe	Bedeutung
`--format`	Eigene Ausgabevorlage; die Feldnamen in geschweiften Klammern werden ersetzt

Images untersuchen

Alle Metadaten als JSON

docker inspect debian:13

Nur einzelne Felder

docker inspect --format 'Vorlage:.Os Vorlage:.Architecture' debian:13

Bauschritte eines Images anzeigen

docker history caddy:2

Images löschen

Ein bestimmtes Image

docker rmi debian:13

Alle Images, die von keinem Container benutzt werden

docker image prune -a

Angabe	Bedeutung
`-a`	Nicht nur namenlose Zwischenschichten, sondern alle unbenutzten Images

Übung

Laden Sie debian:13 und alpine:3 herunter und vergleichen Sie die Größen.
Lassen Sie sich mit docker history die Schichten von caddy:2 anzeigen und bestimmen Sie die größte Schicht.
Geben Sie mit docker inspect --format nur das Kommando aus, das beim Start des Caddy-Images ausgeführt wird.
Löschen Sie alpine:3 wieder.

Container

Lifecycle

Zustand	Bedeutung
created	Container angelegt, aber nicht gestartet
running	Prozess läuft
paused	Prozesse angehalten, Speicher bleibt belegt
exited	Prozess beendet, Container samt Daten noch vorhanden
removed	Container gelöscht

Wichtig

Ein Container lebt genau so lange wie sein Hauptprozess. Endet der Prozess, endet der Container.

Ersten Container starten

docker run --name web -d -p 8080:80 nginx:1.29

Angabe	Bedeutung
`--name web`	Fester Name; ohne diese Angabe vergibt Docker einen Zufallsnamen
`-d`	Betrieb im Hintergrund, die Konsole bleibt frei
`-p 8080:80`	Port 8080 des Hosts wird auf Port 80 im Container geleitet
`nginx:1.29`	Zu verwendendes Image

Interaktiver Betrieb

docker run -it --rm debian:13 bash

Angabe	Bedeutung
`-i`	Standardeingabe bleibt offen
`-t`	Ein Terminal wird zugeteilt
`--rm`	Container wird nach dem Beenden gelöscht
`bash`	Ersetzt das im Image hinterlegte Startkommando

Container auflisten

Laufende Container

docker ps

Ausgabe

CONTAINER ID   IMAGE        COMMAND                  STATUS         PORTS                                     NAMES
9f31c07ab2d4   nginx:1.29   "/docker-entrypoint.…"   Up 4 minutes   0.0.0.0:8080->80/tcp, [::]:8080->80/tcp   web

Alle Container, auch beendete

docker ps -a

Nur die Kennungen

docker ps -q

Angabe	Bedeutung
`-a`	Auch Container in anderen Zuständen als running
`-q`	Nur die Container-IDs, geeignet zur Weiterverarbeitung

Starten, Stoppen, Neustarten

docker stop web
docker start web
docker restart web

Ablauf beim Stoppen

Docker schickt SIGTERM, wartet standardmäßig zehn Sekunden und schickt danach SIGKILL.

Wartezeit ändern

docker stop -t 30 web

Angabe	Bedeutung
`-t 30`	Wartezeit in Sekunden bis zum harten Abbruch

Prozesse anhalten und fortsetzen

docker pause web
docker unpause web

Beim Anhalten werden die Prozesse im Container eingefroren, der belegte Arbeitsspeicher bleibt bestehen. Im Unterschied zu docker stop läuft der Container danach an derselben Stelle weiter.

Restart-Policy

docker run -d --name web --restart unless-stopped -p 8080:80 nginx:1.29

Wert	Verhalten
`no`	Kein automatischer Neustart (Vorgabe)
`on-failure`	Neustart nur bei Exit-Code ungleich 0
`always`	Immer, auch nach einem `docker stop` mit anschließendem Neustart des Daemons
`unless-stopped`	Wie `always`, aber ein manuell gestoppter Container bleibt gestoppt

Container löschen

Beendeten Container löschen

docker rm web

Laufenden Container löschen

docker rm -f web

Alle beendeten Container löschen

docker container prune

Angabe	Bedeutung
`-f`	Container wird zuerst hart beendet und dann gelöscht

Logs

docker logs web
docker logs -f web
docker logs --tail 20 web
docker logs -t web

Angabe	Bedeutung
`-f`	Ausgabe läuft weiter mit
`--tail 20`	Nur die letzten 20 Zeilen
`-t`	Mit Zeitstempel

Woher die Logs kommen

Docker sammelt das, was der Hauptprozess auf die Standardausgabe und die Standardfehlerausgabe schreibt. Was ein Dienst in eine Datei im Container schreibt, taucht hier nicht auf.

Kommandos im laufenden Container

docker exec web ls -l /usr/share/nginx/html
docker exec -it web bash

Angabe	Bedeutung
`-i`	Standardeingabe offen halten
`-t`	Terminal zuteilen

Hinweis

Änderungen über docker exec liegen nur in der beschreibbaren Schicht dieses Containers und sind nach dem Löschen weg. Für dauerhafte Änderungen gehört die Anpassung ins Dockerfile.

Ressourcen begrenzen

docker run -d --name web --memory 256m --cpus 0.5 nginx:1.29

Angabe	Bedeutung
`--memory 256m`	Obergrenze für den Arbeitsspeicher
`--cpus 0.5`	Anteil an einem CPU-Kern

Laufende Auslastung anzeigen

docker stats

Übung

Starten Sie einen Nginx-Container im Hintergrund mit dem Namen web und Portweiterleitung 8080 auf 80.
Rufen Sie die Seite mit curl http://localhost:8080 ab und sehen Sie sich anschließend die Logs an.
Öffnen Sie mit docker exec eine Shell im Container und ersetzen Sie die Datei /usr/share/nginx/html/index.html durch einen eigenen Text.
Löschen Sie den Container, starten Sie ihn neu und prüfen Sie, was aus Ihrer Änderung geworden ist.
Starten Sie den Container erneut mit --restart unless-stopped, starten Sie die VM neu und prüfen Sie, ob der Container wieder läuft.

Ports veröffentlichen

Netzwerk-Namespace

Jeder Container bekommt einen eigenen Netzwerk-Namespace mit eigener IP-Adresse. Ein Dienst, der im Container auf Port 80 lauscht, ist damit zunächst nur innerhalb des Containers erreichbar.

Host-Port und Container-Port

Host-Port	Richtung	Container-Port
8080	→	80

Alles, was auf dem Host an Port 8080 ankommt, wird an Port 80 im Container weitergereicht.

Client ---> Host:8080 ---> Container:80 ---> Dienst

Port veröffentlichen

docker run -d -p 8080:80 nginx:1.29

Aufbau der Angabe

-p Host-Port:Container-Port

Mehrere Ports

docker run -d -p 8080:80 -p 8443:443 nginx:1.29

Bindung an eine bestimmte Adresse

docker run -d -p 127.0.0.1:8080:80 nginx:1.29

Wirkung

Der Dienst ist nur noch vom Host selbst erreichbar. Ohne Adressangabe bindet Docker an alle Adressen des Hosts.

Wichtig für die Firewall

Veröffentlichte Ports werden von Docker über eigene nftables-Regeln freigeschaltet. Eine Regel in der INPUT-Kette des Hosts greift dabei nicht. Wer den Zugriff einschränken will, bindet an eine feste Adresse wie oben oder arbeitet mit der Kette DOCKER-USER.

Zufällige Ports

docker run -d -P nginx:1.29
docker ps

Angabe	Bedeutung
`-P`	Alle im Image mit EXPOSE angegebenen Ports werden auf freie hohe Host-Ports gelegt

Die tatsächlich vergebenen Ports stehen in der Spalte PORTS der Ausgabe von docker ps.

PORTS
0.0.0.0:32768->80/tcp

Übung

Starten Sie zwei Nginx-Container gleichzeitig, einen auf Host-Port 8080, einen auf 8081.
Versuchen Sie, einen dritten Container ebenfalls auf 8080 zu starten, und lesen Sie die Fehlermeldung.
Starten Sie einen Container mit -p 127.0.0.1:8082:80 und prüfen Sie von einem zweiten Rechner aus, ob er erreichbar ist.

Daten dauerhaft speichern

Das Problem

Die beschreibbare Schicht gehört zum Container. Wird der Container gelöscht, sind die Daten weg. Für Datenbanken, Konfigurationen und Nutzdaten braucht es Speicher außerhalb des Containers.

Speicherarten

Art	Ablage	Einsatz
Bind Mount	Beliebiges Verzeichnis des Hosts	Konfigurationsdateien, Zertifikate, Entwicklung
Named Volume	Von Docker verwaltet unter `/var/lib/docker/volumes`	Nutzdaten von Diensten und Datenbanken
Anonymes Volume	Wie Named Volume, aber ohne Namen	Entsteht automatisch, ungeeignet für geplante Datenhaltung

Bind Mount

docker run -d -p 8080:80 -v /srv/web:/usr/share/nginx/html nginx:1.29

Aufbau der Angabe

-v Host-Verzeichnis:Container-Verzeichnis

Eigenschaft	Bewertung
Direkter Zugriff vom Host	Vorteil bei Konfiguration und Entwicklung
Abhängig von der Verzeichnisstruktur des Hosts	Nachteil bei Umzug auf ein anderes System
Rechte richten sich nach den Host-Rechten	Häufige Fehlerquelle bei "permission denied"

Named Volume

Volume anlegen

docker volume create webdata

Volume verwenden

docker run -d -v webdata:/usr/share/nginx/html nginx:1.29

Aufbau der Angabe

-v Volumename:Container-Verzeichnis

Verhalten beim ersten Start

Ist das Volume leer, kopiert Docker den Inhalt des Container-Verzeichnisses aus dem Image hinein. Bei einem Bind Mount passiert das nicht, dort überdeckt das Host-Verzeichnis den Inhalt.

Anonymes Volume

Enthält ein Image die Anweisung VOLUME, legt Docker beim Start ein Volume ohne Namen an. Solche Volumes tauchen in docker volume ls nur mit einer langen Kennung auf und bleiben nach dem Löschen des Containers zurück.

vim Dockerfile

FROM debian:13
VOLUME /app/data
CMD ["bash"]

docker build -t volumetest .
docker run -it --rm volumetest
docker volume ls

Volume in mehreren Containern

Ein Named Volume kann von mehreren Containern gleichzeitig eingebunden werden.

docker run -d --name schreiber -v gemeinsam:/app/data debian:13 sleep 3600
docker run -d --name leser -v gemeinsam:/app/data debian:13 sleep 3600
docker exec schreiber sh -c 'echo Testeintrag > /app/data/test.txt'
docker exec leser cat /app/data/test.txt

Angabe	Bedeutung
`sleep 3600`	Hält den Container am Leben, damit er für `docker exec` zur Verfügung steht
`sh -c`	Das Kommando wird in einer Shell ausgeführt, damit die Umleitung `>` im Container wirkt und nicht auf dem Host

Hinweis

Docker regelt den gleichzeitigen Zugriff nicht. Schreiben mehrere Container in dieselben Dateien, muss die Anwendung selbst dafür sorgen, dass sich das verträgt.

Volumes verwalten

docker volume ls
docker volume inspect webdata
docker volume rm webdata
docker volume prune

Kommando	Bedeutung
`ls`	Alle Volumes anzeigen
`inspect`	Ablageort und Optionen anzeigen
`rm`	Einzelnes Volume löschen
`prune`	Alle Volumes löschen, die kein Container benutzt

Daten sichern und zurückspielen

Sichern

docker run --rm -v webdata:/source -v /backup:/backup debian:13 tar czf /backup/webdata.tar.gz -C /source .

Zurückspielen

docker run --rm -v webdata:/target -v /backup:/backup debian:13 tar xzf /backup/webdata.tar.gz -C /target

Angabe	Bedeutung
`--rm`	Der Hilfscontainer wird nach der Sicherung gelöscht
`-v webdata:/source`	Das zu sichernde Volume wird eingehängt
`-v /backup:/backup`	Das Zielverzeichnis des Hosts wird eingehängt
`-c`	Archiv erzeugen
`-x`	Archiv entpacken
`-z`	Mit gzip komprimieren
`-f`	Name der Archivdatei
`-C`	Vor dem Packen bzw. Entpacken in dieses Verzeichnis wechseln

Nur-Lese-Einbindung

docker run -d -v /srv/web:/usr/share/nginx/html:ro nginx:1.29

Angabe	Bedeutung
`:ro`	Der Container darf nur lesen

Zertifikate, Schlüssel und Konfigurationsdateien werden grundsätzlich mit :ro eingebunden.

Übung

Legen Sie auf dem Host /srv/web mit einer eigenen index.html an und binden Sie das Verzeichnis in einen Nginx-Container ein.
Ändern Sie die Datei auf dem Host und laden Sie die Seite neu, ohne den Container anzufassen.
Legen Sie ein Named Volume an, hängen Sie es unter /usr/share/nginx/html ein und prüfen Sie, was Docker beim ersten Start hineinkopiert hat.
Binden Sie ein Named Volume in zwei Container gleichzeitig ein, schreiben Sie aus dem einen eine Datei hinein und lesen Sie sie aus dem anderen.
Sichern Sie das Volume nach /backup, löschen Sie es und spielen Sie es zurück.

Eigene Images bauen

Dockerfile

Ein Dockerfile ist eine Textdatei mit den Bauanweisungen. Jede Anweisung erzeugt eine Schicht.

FROM

Legt das Basis-Image fest, muss die erste Anweisung sein

FROM python:3.13-slim

Variante	Bedeutung
`python:3.13`	Vollständige Debian-Basis, groß, viele Werkzeuge enthalten
`python:3.13-slim`	Abgespeckte Debian-Basis, deutlich kleiner
`python:3.13-alpine`	Alpine-Basis, am kleinsten, andere C-Bibliothek, gelegentlich Kompatibilitätsprobleme

WORKDIR

Setzt das Arbeitsverzeichnis für alle folgenden Anweisungen, legt es bei Bedarf an

WORKDIR /app

COPY

Kopiert Dateien vom Baukontext in das Image

COPY requirements.txt .
COPY app.py .

Baukontext

Der Baukontext ist das Verzeichnis, das beim Bauen als letztes Argument angegeben wird. Nur Dateien aus diesem Verzeichnis können kopiert werden.

RUN

Führt ein Kommando beim Bauen aus

RUN pip install --no-cache-dir -r requirements.txt

Angabe	Bedeutung
`--no-cache-dir`	pip legt keinen Paketcache im Image ab, das Image bleibt kleiner

Mehrere Kommandos zusammenfassen

Jede RUN-Anweisung erzeugt eine Schicht. Zusammengehörige Schritte gehören in eine Anweisung, das Aufräumen in dieselbe Zeile.

RUN apt-get update && apt-get install -y --no-install-recommends \
        curl \
    && rm -rf /var/lib/apt/lists/*

Angabe	Bedeutung
`--no-install-recommends`	Empfohlene, aber nicht zwingende Pakete werden weggelassen
`rm -rf /var/lib/apt/lists/*`	Die Paketlisten werden entfernt; in einer eigenen Schicht würde das nichts bringen, weil die Daten in der darunterliegenden Schicht bleiben

ENV

Setzt eine Umgebungsvariable im Image und in jedem daraus erzeugten Container

ENV PYTHONUNBUFFERED=1

USER

Legt fest, unter welchem Benutzer der Hauptprozess läuft

RUN useradd -r -u 1001 app
USER app

Angabe	Bedeutung
`-r`	Systembenutzer ohne Heimatverzeichnis und ohne Anmeldung
`-u 1001`	Feste UID, damit die Rechte auf Volumes vorhersagbar bleiben

Ohne diese Anweisung läuft der Prozess im Container als root.

EXPOSE

Dokumentiert, auf welchem Port der Dienst lauscht

EXPOSE 5000

EXPOSE veröffentlicht keinen Port. Es dient als Hinweis und wird von -P ausgewertet.

CMD und ENTRYPOINT

CMD legt das Startkommando fest und ist beim Start überschreibbar

CMD ["python", "app.py"]

ENTRYPOINT legt das Startkommando fest, CMD liefert dann nur noch die Argumente

ENTRYPOINT ["python", "app.py"]

Schreibweise	Bedeutung
`CMD ["python", "app.py"]`	Exec-Form; der Prozess wird direkt gestartet und erhält die Signale von `docker stop`
`CMD python app.py`	Shell-Form; es wird eine Shell dazwischengeschaltet, Signale kommen beim Prozess nicht sauber an

Es gilt immer nur die letzte CMD-Anweisung im Dockerfile. Die Exec-Form ist die einzusetzende Schreibweise.

.dockerignore

Schließt Dateien vom Baukontext aus

vim .dockerignore

.git
__pycache__
*.log

Ohne diese Datei wird das gesamte Verzeichnis an den Daemon übertragen, auch das Git-Verzeichnis.

Image bauen

docker build -t webapp:1.0 .

Angabe	Bedeutung
`-t webapp:1.0`	Name und Tag des entstehenden Images
`.`	Der Baukontext, hier das aktuelle Verzeichnis

Reihenfolge im Dockerfile

Selten geänderte Anweisungen gehören nach oben, häufig geänderte nach unten. Deshalb wird zuerst requirements.txt kopiert und installiert und erst danach der Anwendungscode. Eine Codeänderung macht dann nur die letzten Schichten ungültig.

Mehrstufiger Bau

Bei mehrstufigen Builds wird in einer ersten Stufe gebaut und in einer zweiten nur das Ergebnis übernommen. Compiler und Entwicklungspakete landen damit nicht im fertigen Image.

FROM golang:1.24 AS build
WORKDIR /src
COPY . .
RUN go build -o /out/server .

FROM debian:13-slim
COPY --from=build /out/server /usr/local/bin/server
CMD ["server"]

Angabe	Bedeutung
`AS build`	Name der ersten Stufe
`--from=build`	Die Datei wird aus der genannten Stufe übernommen, nicht aus dem Baukontext

Beispiel: eigene Anwendung

Projektverzeichnis anlegen

mkdir -p ~/webapp
cd ~/webapp

Anwendung

vim app.py

from flask import Flask

app = Flask(__name__)

@app.route("/")
def hello():
    return "Hallo aus dem Container\n"

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=5000)

Abhängigkeiten

vim requirements.txt

flask==3.1.0

Bauanleitung

vim Dockerfile

FROM python:3.13-slim

ENV PYTHONUNBUFFERED=1
WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY app.py .

RUN useradd -r -u 1001 app
USER app

EXPOSE 5000
CMD ["python", "app.py"]

Bauen und starten

docker build -t webapp:1.0 .
docker run -d --name webapp -p 5000:5000 webapp:1.0
curl http://localhost:5000

Übung

Bauen Sie das Image webapp:1.0 und starten Sie es.
Ändern Sie den Text in app.py, bauen Sie erneut und beobachten Sie, welche Schichten aus dem Cache kommen.
Tauschen Sie im Dockerfile die Reihenfolge, kopieren Sie also app.py vor der Installation der Abhängigkeiten, bauen Sie erneut und vergleichen Sie die Bauzeit.
Prüfen Sie mit docker exec webapp id, unter welchem Benutzer der Prozess läuft.
Legen Sie eine .dockerignore an und vergleichen Sie die Größe des übertragenen Baukontexts in der Ausgabe von docker build.

Docker Compose

Was ist Compose

Compose beschreibt mehrere Container samt Netzwerken und Volumes in einer YAML-Datei und betreibt sie gemeinsam.

Aktueller Stand

Compose ist ein Unterkommando von Docker und wird als docker compose aufgerufen. Das alte, separat installierte Python-Werkzeug docker-compose mit Bindestrich wird nicht mehr gepflegt. In Anleitungen im Netz steht häufig noch die alte Schreibweise.

Aufbau der Datei

Dateiname

Der aktuelle Standardname ist compose.yaml. docker-compose.yml wird aus Kompatibilitätsgründen weiterhin gelesen.

Keine Versionsangabe

Die früher übliche erste Zeile version: '3.8' ist entfallen. Sie wird ignoriert und erzeugt beim Start eine Warnung.

vim compose.yaml

services:
  web:
    image: nginx:1.29
    ports:
      - "8080:80"
    volumes:
      - ./html:/usr/share/nginx/html:ro
    restart: unless-stopped

  app:
    build: ./app
    environment:
      APP_ENV: production
    depends_on:
      - db
    restart: unless-stopped

  db:
    image: postgres:17
    environment:
      POSTGRES_PASSWORD: geheim
    volumes:
      - dbdata:/var/lib/postgresql/data
    restart: unless-stopped

volumes:
  dbdata:

Schlüssel	Bedeutung
`services`	Die einzelnen Container
`image`	Fertiges Image aus einer Registry
`build`	Verzeichnis mit einem Dockerfile, aus dem gebaut wird
`ports`	Portweiterleitungen wie bei `-p`
`volumes`	Einbindungen wie bei `-v`
`environment`	Umgebungsvariablen
`depends_on`	Startreihenfolge
`restart`	Neustartverhalten
`volumes` (unten)	Deklaration der benannten Volumes

Netzwerk

Compose legt für jedes Projekt ein eigenes Netzwerk an. Alle Dienste des Projekts hängen darin und erreichen sich über den Dienstnamen als Hostnamen. Der Dienst app erreicht die Datenbank also über den Namen db, ohne dass ein Port veröffentlicht werden muss.

Wichtig

Nur Dienste, die von außen erreichbar sein müssen, bekommen einen Eintrag unter ports. Alles andere bleibt im internen Netz.

Projekt starten und stoppen

docker compose up -d
docker compose ps
docker compose stop
docker compose down
docker compose down -v

Kommando	Bedeutung
`up -d`	Erzeugt und startet alle Dienste im Hintergrund
`ps`	Zustand der Dienste des Projekts
`stop`	Hält die Container an, löscht sie aber nicht
`down`	Hält an und entfernt Container und Netzwerk
`down -v`	Zusätzlich werden die Volumes des Projekts gelöscht

Projektname

Der Projektname ist standardmäßig der Name des Verzeichnisses. Alle erzeugten Container, Netzwerke und Volumes tragen ihn als Präfix.

Weitere Kommandos

docker compose logs -f
docker compose logs -f web
docker compose up -d --build
docker compose exec web bash
docker compose run --rm app bash
docker compose up -d --scale app=3
docker compose config

Kommando	Bedeutung
`logs -f`	Logs aller Dienste mitlaufen lassen
`logs -f web`	Logs eines einzelnen Dienstes
`up -d --build`	Vor dem Start werden die selbst gebauten Images neu erzeugt
`exec web bash`	Shell in einem bereits laufenden Dienst
`run --rm app bash`	Startet einen zusätzlichen, einmaligen Container des Dienstes; `--rm` löscht ihn danach
`up -d --scale app=3`	Startet den Dienst in drei Instanzen
`config`	Zeigt die zusammengesetzte und geprüfte Konfiguration; erste Anlaufstelle bei YAML-Fehlern

Grenzen von scale

Ein Dienst mit einem festen Eintrag unter ports oder mit container_name lässt sich nicht vervielfältigen, weil Host-Port und Name nur einmal vergeben werden können. Sinnvoll ist --scale daher nur für Dienste hinter einem Reverse Proxy.

Healthcheck und depends_on

depends_on wartet nur darauf, dass der Container gestartet ist, nicht darauf, dass der Dienst darin bereit ist. Mit einem Healthcheck lässt sich das ändern.

services:
  app:
    image: webapp:1.0
    depends_on:
      db:
        condition: service_healthy

  db:
    image: postgres:17
    environment:
      POSTGRES_PASSWORD: geheim
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 10s
      timeout: 5s
      retries: 5

Schlüssel	Bedeutung
`test`	Kommando, das den Zustand prüft; Rückgabewert 0 bedeutet gesund
`CMD-SHELL`	Das Kommando wird in einer Shell ausgeführt
`interval`	Abstand zwischen zwei Prüfungen
`timeout`	Zeit, nach der eine Prüfung als fehlgeschlagen gilt
`retries`	Zahl der Fehlversuche, bis der Dienst als ungesund gilt
`condition: service_healthy`	Der abhängige Dienst startet erst, wenn der Healthcheck gesund meldet

Übung

Legen Sie ein Verzeichnis ~/stack mit einer compose.yaml an, die Nginx und Ihre webapp:1.0 enthält.
Starten Sie den Stack und prüfen Sie mit docker compose ps und docker network ls, was Compose angelegt hat.
Prüfen Sie aus dem Nginx-Container heraus mit docker compose exec web curl http://app:5000, ob die Namensauflösung über den Dienstnamen funktioniert.
Fügen Sie bewusst einen YAML-Fehler ein und lassen Sie ihn sich mit docker compose config anzeigen.

Abschlussprojekt: Uptime Kuma hinter Caddy

Ziel

Uptime Kuma wird über HTTPS unter kuma.it2XX.int erreichbar gemacht. Caddy nimmt die verschlüsselte Verbindung an und reicht sie intern unverschlüsselt an Uptime Kuma weiter. Beide Dienste liegen in getrennten Compose-Projekten und werden über ein gemeinsames Netzwerk verbunden.

Bestandteil	Aufgabe
Caddy	Nimmt Port 80 und 443 an, terminiert TLS, leitet weiter
Uptime Kuma	Überwachungsdienst, lauscht intern auf Port 3001
Netzwerk `proxy`	Verbindet die beiden Projekte
Zertifikat	`/etc/ssl/own.crt` und `/etc/ssl/own.key` auf dem Host

Warum zwei getrennte Projekte

Der Reverse Proxy ist ein eigenständiger Dienst, der später weitere Anwendungen bedienen soll. Jede Anwendung bekommt ihr eigenes Projektverzeichnis und kann unabhängig neu gestartet werden, ohne den Proxy anzufassen.

Namensauflösung

Der Name kuma.it2XX.int muss auf die Adresse des Docker-Hosts zeigen.

vim /etc/hosts

10.20.XX.10   kuma.it2XX.int kuma

Gemeinsames Netzwerk anlegen

docker network create proxy

Das Netzwerk wird außerhalb der Projekte angelegt, damit beide Compose-Dateien es als bestehendes Netzwerk einbinden können.

Zertifikat prüfen

ls -l /etc/ssl/own.crt /etc/ssl/own.key
openssl x509 -in /etc/ssl/own.crt -noout -subject -dates

Angabe	Bedeutung
`-in`	Zu prüfende Zertifikatsdatei
`-noout`	Das Zertifikat selbst wird nicht ausgegeben
`-subject`	Zeigt den Namen, auf den das Zertifikat ausgestellt ist
`-dates`	Zeigt Beginn und Ende der Gültigkeit

Der im Zertifikat eingetragene Name muss kuma.it2XX.int lauten, sonst lehnt der Browser die Verbindung ab.

Projekt Caddy

Verzeichnis anlegen

mkdir -p ~/proxy
cd ~/proxy

Konfiguration des Proxys

vim Caddyfile

kuma.it2XX.int {
    tls /etc/ssl/own.crt /etc/ssl/own.key
    reverse_proxy kuma:3001
}

Zeile	Bedeutung
`kuma.it2XX.int { }`	Der Block gilt für Anfragen mit diesem Hostnamen
`tls /etc/ssl/own.crt /etc/ssl/own.key`	Es wird das angegebene Zertifikat benutzt; damit fordert Caddy kein Zertifikat über ACME an
`reverse_proxy kuma:3001`	Weiterleitung an den Container `kuma` auf Port 3001

Compose-Datei

vim compose.yaml

services:
  caddy:
    image: caddy:2
    container_name: caddy
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - /etc/ssl/own.crt:/etc/ssl/own.crt:ro
      - /etc/ssl/own.key:/etc/ssl/own.key:ro
      - caddy_data:/data
      - caddy_config:/config
    networks:
      - proxy
    restart: unless-stopped

volumes:
  caddy_data:
  caddy_config:

networks:
  proxy:
    external: true

Eintrag	Bedeutung
`container_name: caddy`	Fester Containername statt des Namens aus Projekt und Dienst
`./Caddyfile:/etc/caddy/Caddyfile:ro`	Die Konfiguration wird nur lesend eingebunden
`/etc/ssl/own.crt:…:ro`	Zertifikat und Schlüssel werden unter demselben Pfad wie auf dem Host eingebunden, nur lesend
`caddy_data`	Dauerhafter Zustand von Caddy
`caddy_config`	Von Caddy erzeugte Konfigurationsdateien
`networks: proxy`	Der Dienst hängt im gemeinsamen Netz
`external: true`	Das Netz wird nicht von Compose angelegt, es muss vorhanden sein

Projekt Uptime Kuma

Verzeichnis anlegen

mkdir -p ~/kuma
cd ~/kuma

Compose-Datei

vim compose.yaml

services:
  kuma:
    image: louislam/uptime-kuma:1
    container_name: kuma
    volumes:
      - kuma_data:/app/data
    networks:
      - proxy
    restart: unless-stopped

volumes:
  kuma_data:

networks:
  proxy:
    external: true

Eintrag	Bedeutung
`container_name: kuma`	Unter diesem Namen erreicht Caddy den Dienst
kein `ports`-Eintrag	Der Dienst ist nur im internen Netz erreichbar, nicht direkt vom Host
`kuma_data:/app/data`	Datenbank und Konfiguration von Uptime Kuma bleiben erhalten

Starten und prüfen

Proxy starten

cd ~/proxy
docker compose up -d

Anwendung starten

cd ~/kuma
docker compose up -d

Zustand prüfen

docker compose ps
docker compose logs -f caddy

Verbindung testen

curl -I --cacert /etc/ssl/own.crt https://kuma.it2XX.int

Angabe	Bedeutung
`-I`	Nur die Kopfzeilen abrufen
`--cacert`	Das eigene Zertifikat wird zur Prüfung herangezogen

Danach die Seite im Browser aufrufen und den Ersteinrichtungsdialog von Uptime Kuma durchlaufen.

Typische Fehler

Meldung	Ursache
`network proxy declared as external, but could not be found`	Das Netzwerk wurde nicht mit `docker network create proxy` angelegt
`dial tcp: lookup kuma on …: no such host`	Der Kuma-Container läuft nicht oder hängt nicht im Netz `proxy`
`bind: address already in use`	Auf dem Host belegt bereits ein Dienst Port 80 oder 443
Browser meldet unbekannten Aussteller	Das eigene Wurzelzertifikat ist auf dem Client nicht eingetragen
Zertifikatsname passt nicht	Im Zertifikat steht ein anderer Name als `kuma.it2XX.int`

Übung

Bauen Sie beide Projekte wie beschrieben auf und rufen Sie Uptime Kuma über HTTPS auf.
Legen Sie in Uptime Kuma eine Überwachung für https://kuma.it2XX.int selbst an.
Halten Sie mit docker compose stop im Kuma-Projekt den Dienst an und sehen Sie sich an, welche Meldung Caddy im Log ausgibt.
Löschen Sie den Kuma-Container mit docker compose down und starten Sie ihn neu. Prüfen Sie, ob Ihre Überwachung noch vorhanden ist.
Erweitern Sie das Caddy-Projekt um einen zweiten Namen, der auf Ihre webapp:1.0 zeigt.

Empfehlungen für den Betrieb

Images

Feste Versionen statt latest verwenden
Zusammengehörige Schritte in einer RUN-Anweisung ausführen und im selben Schritt aufräumen
Selten geänderte Anweisungen nach oben, häufig geänderte nach unten
Mehrstufigen Bau nutzen, damit keine Bauwerkzeuge im fertigen Image landen
.dockerignore anlegen

Container

Ein Dienst je Container
Prozesse nicht als root laufen lassen
Dauerhafte Daten in Named Volumes, Konfiguration und Zertifikate als Bind Mount mit :ro
Nur die Ports veröffentlichen, die wirklich von außen erreichbar sein müssen
restart: unless-stopped für Dienste, die einen Neustart überstehen sollen

Sicherheit

Offizielle oder selbst gebaute Images bevorzugen
Images regelmäßig neu bauen, damit Sicherheitsupdates der Basis einfließen
Zugehörigkeit zur Gruppe docker nur an Personen vergeben, die Root-Rechte auf dem Host haben dürfen
Passwörter nicht ins Image, sondern über Umgebungsvariablen oder Dateien einbringen

Kommandoübersicht

Images

Kommando	Bedeutung
`docker pull image:tag`	Image herunterladen
`docker images`	Lokale Images anzeigen
`docker inspect image`	Metadaten anzeigen
`docker history image`	Schichten anzeigen
`docker build -t name:tag .`	Image bauen
`docker tag quelle ziel`	Weiteren Namen vergeben
`docker push image:tag`	Image in eine Registry laden
`docker rmi image`	Image löschen
`docker image prune -a`	Unbenutzte Images löschen

Container

Kommando	Bedeutung
`docker run image`	Container erzeugen und starten
`docker ps`	Laufende Container anzeigen
`docker ps -a`	Alle Container anzeigen
`docker stop name`	Container anhalten
`docker start name`	Container starten
`docker restart name`	Container neu starten
`docker pause name`	Prozesse im Container anhalten
`docker unpause name`	Angehaltene Prozesse fortsetzen
`docker rm name`	Container löschen
`docker rm -f name`	Laufenden Container löschen
`docker logs -f name`	Logs mitlaufen lassen
`docker exec -it name bash`	Shell im Container öffnen
`docker stats`	Ressourcenverbrauch anzeigen
`docker container prune`	Beendete Container löschen

Volumes und Netzwerke

Kommando	Bedeutung
`docker volume create name`	Volume anlegen
`docker volume ls`	Volumes anzeigen
`docker volume inspect name`	Ablageort anzeigen
`docker volume rm name`	Volume löschen
`docker network create name`	Netzwerk anlegen
`docker network ls`	Netzwerke anzeigen
`docker network inspect name`	Angeschlossene Container anzeigen

Compose

Kommando	Bedeutung
`docker compose up -d`	Projekt im Hintergrund starten
`docker compose up -d --build`	Vor dem Start neu bauen
`docker compose ps`	Dienste des Projekts anzeigen
`docker compose logs -f dienst`	Logs eines Dienstes
`docker compose exec dienst bash`	Shell in einem Dienst
`docker compose run --rm dienst bash`	Einmaligen Zusatzcontainer starten
`docker compose up -d --scale dienst=3`	Dienst in mehreren Instanzen starten
`docker compose config`	Konfiguration prüfen
`docker compose stop`	Dienste anhalten
`docker compose down`	Container und Netzwerk entfernen
`docker compose down -v`	Zusätzlich Volumes entfernen

System

Kommando	Bedeutung
`docker info`	Systemweite Informationen
`docker version`	Versionen von Client und Server
`docker system df`	Belegten Plattenplatz anzeigen
`docker system prune`	Unbenutzte Objekte löschen

Docker Essentials

Einführung

Was ist ein Container

Die Ausgangslage ohne Container

Container und virtuelle Maschine

Aufbau von Docker

Begriffe

Übung

Installation unter Debian

Ausgangslage

Paketquelle einbinden

Docker installieren

Installation prüfen

Docker ohne sudo benutzen

Aufbau der Kommandozeile

Übung

Images

Was ist ein Image

Layer

Overlay-Dateisystem

Registries und Namensformat

Images herunterladen

Images auflisten

Images untersuchen

Images löschen

Übung

Container

Lifecycle

Ersten Container starten

Interaktiver Betrieb

Container auflisten

Starten, Stoppen, Neustarten

Restart-Policy

Container löschen

Logs

Kommandos im laufenden Container

Ressourcen begrenzen

Übung

Ports veröffentlichen

Netzwerk-Namespace

Host-Port und Container-Port

Port veröffentlichen

Mehrere Ports

Bindung an eine bestimmte Adresse

Zufällige Ports

Übung

Daten dauerhaft speichern

Das Problem

Speicherarten

Bind Mount

Named Volume

Anonymes Volume

Volume in mehreren Containern

Volumes verwalten

Daten sichern und zurückspielen

Nur-Lese-Einbindung

Übung

Eigene Images bauen

Dockerfile

FROM

WORKDIR

COPY

RUN

ENV

USER

EXPOSE

CMD und ENTRYPOINT

.dockerignore

Image bauen

Tags

Mehrstufiger Bau

Beispiel: eigene Anwendung

Übung

Docker Compose

Was ist Compose

Aufbau der Datei

Netzwerk

Projekt starten und stoppen

Weitere Kommandos

Healthcheck und depends_on