Containerization
Containerisierung bündelt eine Anwendung mit ihrer Laufzeitumgebung, ihren Bibliotheken und Einstellungen in einem Image. Dieses wird als isolierter Prozess ausgeführt und nutzt den Kernel des Host-Betriebssystems gemeinsam.
Containerisierung ist eine Methode zur Verpackung von Software: Eine Anwendung und alle für ihre Ausführung benötigten Komponenten, darunter Laufzeitumgebung, Bibliotheken, Systempakete und Konfiguration, werden in einem Image gebündelt, das als isolierter Prozess, einem Container, läuft. Jeder Container hat sein eigenes Dateisystem, seinen eigenen Prozessbaum und eigene Netzwerkschnittstellen. Alle Container auf einem Host nutzen jedoch gemeinsam dessen Betriebssystemkernel und sind dadurch wesentlich leichter als virtuelle Maschinen. Beim maschinellen Lernen (ML) verhindert Containerisierung Konflikte zwischen Projekten, die unterschiedliche Versionen von Python, CUDA oder PyTorch benötigen. Außerdem kann ein auf einer Workstation trainiertes Modell unverändert auf einem Server, in einem Cluster oder auf einem Edge-Computing-Gerät laufen.
So funktionieren Container#
Linux-Container basieren hauptsächlich auf zwei Kernel-Funktionen. Namespaces legen fest, was ein Prozess sehen kann, und geben ihm eigene Prozess-IDs, einen eigenen Netzwerk-Stack, eigene Einhängepunkte und eigene Nutzer. Cgroups (Kontrollgruppen) legen fest, welche Ressourcen er nutzen darf, indem sie CPU, Speicher und E/A begrenzen. Die Entwicklung begann mit chroot im Jahr 1979 und FreeBSD Jails im Jahr 2000. Cgroups kamen 2008 in den Linux-Kernel, und Docker machte Container 2013 zum Mainstream. Die 2015 gegründete Open Container Initiative (OCI) standardisierte Image- und Laufzeitformate. Daher läuft ein mit einem Tool erstelltes Image auch mit einem anderen.
Eine Container-Laufzeitumgebung übernimmt die eigentliche Arbeit. Hochrangige Laufzeitumgebungen wie containerd und CRI-O rufen Images ab und verwalten den Lebenszyklus von Containern. Eine niedrigstufige OCI-Laufzeitumgebung wie runc erstellt die Namespaces und Cgroups und startet den Prozess. Da Linux-Container einen Linux-Kernel benötigen, laufen sie unter macOS und Windows in einer kleinen virtuellen Linux-Maschine.
Images, Ebenen und Registries#
Ein Image besteht aus einem Stapel schreibgeschützter Ebenen und einer Konfiguration, in der der auszuführende Befehl angegeben ist. Beim Start fügt die Laufzeitumgebung die Ebenen mithilfe von OverlayFS meist zu einem Dateisystem zusammen und ergänzt eine dünne beschreibbare Ebene für den Container. So nutzen mehrere Container dieselbe Kopie des Images auf der Festplatte. Registries wie Docker Hub, GitHub Container Registry und die Registry jedes Cloud-Anbieters speichern Images unter Tags wie latest und unter Inhaltsprüfsummen. Diese SHA-256-Hashes identifizieren immer dieselben Bytes. Builds verwenden unveränderte Ebenen wieder. Deshalb installieren Dockerfiles Abhängigkeiten, bevor sie häufig bearbeiteten Code kopieren:
Containerisierung in ML-Arbeitsabläufen#
In MLOps-Pipelines transportieren Container ein Projekt vom Experiment bis in die Produktion. Framework-Images wie die im NVIDIA NGC Catalog legen CUDA-, cuDNN- und Framework-Versionen fest. So wird jeder Knoten eines Jobs für verteiltes Training mit derselben Software ausgeführt. Der Host stellt lediglich den GPU-Treiber bereit, den das NVIDIA Container Toolkit im Container verfügbar macht. Tests der kontinuierlichen Integration laufen im selben Image, das später ausgeliefert wird. Inferenzserver für die Modellbereitstellung werden als Images ausgeführt, die Kubernetes je nach Datenverkehr repliziert und skaliert. Edge-KI-Geräte wie NVIDIA Jetson-Boards erhalten Modellaktualisierungen, indem sie ein neues Image-Tag abrufen.
Die On-Premises-Integration der Ultralytics Platform für Enterprise-Arbeitsbereiche installiert bei Bedarf Docker und führt einen Worker-Container aus dem offiziellen Ultralytics-Image aus, das zur ARM64-, CPU- oder NVIDIA-GPU-Hardware des Hosts passt. Der Worker bindet den Dataset-Ordner schreibgeschützt ein. So bleiben die Quellbilder auf diesem Computer, während Trainingsmetriken und der beste Prüfpunkt jedes YOLO26-Laufs an die Platform übermittelt werden.
Container und virtuelle Maschinen#
Eine virtuelle Maschine führt auf einem Hypervisor ein vollständiges Gastbetriebssystem mit eigenem Kernel aus. Jede VM enthält daher ein mehrere Gigabyte großes Betriebssystem-Image und startet wie ein separater Computer. Ein Container ist ein gewöhnlicher Prozess auf dem gemeinsam genutzten Host-Kernel. Deshalb startet er so schnell wie die darin laufende Anwendung und benötigt nur seine eigenen Dateien. Durch den gemeinsam genutzten Kernel kann eine Sicherheitslücke im Kernel alle Container auf einem Host gefährden. Deshalb werden beide Ansätze oft kombiniert: Öffentliche Clouds führen Kundencontainer in VMs aus, und abgeschottete Laufzeitumgebungen schaffen eine zusätzliche Grenze für nicht vertrauenswürdigen Code, etwa für Code, den KI-Agenten in Agent-Sandboxen schreiben und ausführen. Googles gVisor fängt Systemaufrufe eines Containers mit einem eigenen Kernel im Userspace ab. Kata Containers führt jeden Container in einer leichtgewichtigen virtuellen Maschine aus. AWS entwickelte seine Firecracker-MicroVMs, um AWS-Lambda-Funktionen auf dieselbe Weise zu isolieren.
