Docker

Docker ist eine Open-Source-Plattform zum Erstellen, Teilen und Ausführen von Anwendungen in Containern: isolierten Prozessen mit eigenem Dateisystem, Code, Bibliotheken und Systempaketen, die sich den Betriebssystemkernel des Hosts teilen. dotCloud, das Unternehmen, das sich später in Docker, Inc. umbenannte, veröffentlichte Docker im März 2013 als Open Source. Das Befehlszeilenprogramm, das geschichtete Imageformat und die öffentliche Registry machten Linux-Container zu einem alltäglichen Werkzeug für Entwickler. Im maschinellen Lernen legt ein Docker-Image die genaue Python-Version, CUDA-Bibliotheken, den PyTorch-Build und die Modellgewichte fest. So verhält sich ein Modell auf einem Laptop, einem GPU-Server, einem CI-Runner und einem Edge-Gerät gleich.

So funktioniert Docker#

Eine Dockerfile führt die Schritte zum Erstellen eines Images auf: ein Basisimage, von dem aus gestartet wird, Befehle zum Installieren von Paketen, zu kopierende Dateien und der beim Start auszuführende Befehl. Jede Anweisung RUN, COPY oder ADD fügt eine schreibgeschützte Ebene hinzu. Beim nächsten Build werden zwischengespeicherte Ebenen wiederverwendet, bis sich eine Anweisung oder eine ihrer Eingabedateien ändert. Früh installierte Abhängigkeiten bleiben daher im Cache, während der Anwendungscode in Sekunden neu erstellt wird. Ein Image besteht aus diesem Ebenenstapel und Metadaten. Ein Container ist eine laufende Instanz eines Images mit einer dünnen, beschreibbaren Ebene darüber. Diese wird zusammen mit dem Container gelöscht, sofern die Daten nicht in ein eingebundenes Volume geschrieben werden.

Der Befehl docker kommuniziert mit Docker Engine, einem Hintergrunddienst, der jeden Container an containerd und die Laufzeitumgebung runc auf niedriger Ebene übergibt. Diese verwenden Linux-Namespaces, um Prozesse, Netzwerk und Dateisystem eines Containers zu isolieren, und cgroups, um dessen CPU- und Arbeitsspeichernutzung zu begrenzen. Images werden über Registries wie Docker Hub, GitHub Container Registry, NVIDIA NGC und die jeweilige Registry eines Cloud-Anbieters geteilt. Sie verwenden das Imageformat der Open Container Initiative, sodass Podman, containerd und Kubernetes sie unverändert ausführen können.

Ultralytics veröffentlicht offizielle Docker-Images für jedes Hardwareziel, darunter CUDA-GPUs, CPUs, ARM64-Boards, NVIDIA Jetson-Geräte und AMD-GPUs. Jedes Image ist außerdem mit der Ultralytics-Versionsnummer gekennzeichnet, um reproduzierbare Builds zu ermöglichen. Das weiter unten verwendete schlanke Image latest-python enthält bereits Python, PyTorch, das Paket ultralytics und Nano-Gewichte für YOLO26. Die Dockerfile eines Projekts muss daher nur noch den eigenen Code hinzufügen:

# Official Ultralytics CPU image with Python, PyTorch, ultralytics, and yolo26n.pt
FROM ultralytics/ultralytics:latest-python

# Install extra dependencies in their own layer, cached until requirements.txt changes
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Copy the application last, so code edits rebuild only this layer
COPY app.py .

# Command every container runs when it starts
CMD ["python", "app.py"]

Mit docker build -t yolo-app . werden aus dieser Datei und den Dateien in ihrem Verzeichnis ein Image erstellt; docker run --rm yolo-app startet daraus einen Container. Wird das Image in eine Registry übertragen, kann jeder andere Rechner dieselbe Umgebung abrufen und ausführen, etwa als API für Modellbereitstellung oder als nächtlichen Inferenz-Job.

Docker für maschinelles Lernen#

Container greifen über das NVIDIA Container Toolkit auf GPUs zu. Der NVIDIA-Treiber bleibt auf dem Host; das Image enthält nur CUDA-Bibliotheken für den Benutzerbereich, die mit diesem Treiber kompatibel sein müssen. Unter Linux ist CDI ab Docker 28.2 standardmäßig aktiviert. Daher fordert --device nvidia.com/gpu=all GPUs als CDI-Geräte an und erhält den GPU-Zugriff in lang laufenden Containern aufrecht. Das ältere Flag --gpus all kann diesen Zugriff verlieren, wenn der Host systemd neu lädt.

Für das Training sind zwei weitere Einstellungen wichtig. PyTorch-DataLoader-Worker übergeben Batches über den gemeinsamen Speicher /dev/shm an den Trainingsprozess. Docker begrenzt diesen standardmäßig auf 64 MB. Daher werden Trainingscontainer mit --ipc=host oder einem größeren --shm-size ausgeführt. Datensätze und Ausgaben gehören in eingebundene Volumes, denn bei einem Trainingslauf, der Checkpoints im Container speichert, gehen diese beim Entfernen des Containers verloren. Wird statt latest ein Release-Tag oder Image-Digest festgelegt, bleiben ein Job für verteiltes Training oder eine Modellbereitstellung auf allen Rechnern beim selben Image. Sowohl Inferenzserver wie der NVIDIA Triton Inference Server als auch verwaltete Dienste wie Vertex AI führen Modelle als Container-Images aus.

Docker im Vergleich zu virtuellen Maschinen und Kubernetes#

• Virtuelle Maschinen: Ein Hypervisor emuliert Hardware, und jede VM startet ihren eigenen Gastkernel. Das isoliert Arbeitslasten stärker und ermöglicht beliebige Gastbetriebssysteme, erfordert jedoch ein vollständiges Betriebssystem-Image pro VM und führt zu längeren Startzeiten. Da Container den Linux-Kernel des Hosts gemeinsam nutzen, führt Docker Desktop sie unter macOS und Windows in einer schlanken Linux-VM aus.
• Docker Compose: Definiert mehrere Container, die gemeinsam auf einem Host laufen, etwa eine Inferenz-API, einen Cache und einen Erfassungsdienst für Metriken.
• Kubernetes: Plant Container über einen Cluster hinweg ein, startet ausgefallene Container neu und skaliert Replikate je nach Datenverkehr. Kubernetes 1.24 entfernte dockershim, seinen integrierten Adapter für Docker Engine. Cluster führen Container daher über containerd oder CRI-O aus. Mit Docker erstellte Images laufen dort weiterhin, weil sie standardkonforme OCI-Images sind.