Sofortantwort
Container einfach erklärt
Technologie zur Isolation und Portabilität von Anwendungen.
- Kurz gesagt
- Verpackt Anwendung + Abhängigkeiten in ein portables, isoliertes Paket
- Typischer Einsatz
- ML-Model-Serving, Entwicklungsumgebung, Microservices
- Wichtig zu wissen
- Standard für ML-Model-Serving, Microservices und CI/CD-Pipelines
Container im Überblick
Docker ist die Technologie, die das “Works on my machine”-Problem gelöst hat. Ein Docker-Container verpackt eine Anwendung zusammen mit allen Abhängigkeiten – Python-Version, Bibliotheken, Konfiguration – in eine portable Einheit. Dieser Container läuft identisch auf jedem System, das Docker unterstützt. Für KI-Projekte ist Docker unverzichtbar: ML-Modelle haben oft sehr spezifische Abhängigkeiten (CUDA-Version, PyTorch-Version), die in Containern zuverlässig reproduziert werden.
Docker verpackt deine Anwendung mit allem, was sie braucht, in einen Container. Dieser Container läuft überall gleich – auf deinem Laptop, im Rechenzentrum oder in der Cloud.
Warum ist das wichtig?
“Works on my machine” ist Geschichte. Mit Docker hat jeder exakt dieselbe Umgebung – gleiche Python-Version, gleiche Bibliotheken, gleiche Konfiguration.
Dockerfile → Image → Container:
Dockerfile (Bauplan) → docker build → Image (Vorlage) → docker run → Container (laufend)
Beispiel Dockerfile für ML:
FROM python:3.11
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["python", "serve.py"]
Technisch betrachtet
Container vs. VM
| Aspekt | Container | VM |
|---|---|---|
| Startzeit | Sekunden | Minuten |
| Größe | MBs | GBs |
| Overhead | Minimal | Hoch |
| Isolation | Prozess-Level | Hardware-Level |
| OS | Teilt Host-Kernel | Eigenes OS |
Docker für ML/KI
- GPU-Support:
--gpus allfür NVIDIA GPU-Zugriff - NVIDIA Container Toolkit: CUDA und cuDNN im Container
- Multi-Stage Builds: Kleine Production-Images durch Build-Stages
- Volume Mounts: Modelle und Daten außerhalb des Containers speichern
Schritt für Schritt
Eine Anwendung als Container bereitstellen
Ein Container trennt den Bauplan einer Anwendung von der konkreten Maschine, auf der sie später läuft.
Laufzeit beschreiben
Bauplan
Ein Bauplan definiert Betriebssystembasis, Abhängigkeiten, Startbefehl und die Dateien der Anwendung.
anwendung + abhaengigkeiten + startbefehlImage erzeugen
Image
Aus dem Bauplan entsteht ein versioniertes Image, das unverändert verteilt werden kann.
bauplan -> build -> versioniertes imageImage prüfen
Prüfung
Automatisierte Tests und Sicherheitsprüfungen bestätigen, dass die Anwendung in der vorgesehenen Umgebung funktioniert.
image -> tests + sicherheitscheckContainer ausführen
Betrieb
Die Infrastruktur startet aus dem Image eine laufende Instanz mit klarer Konfiguration und begrenzten Rechten.
image + konfiguration -> laufender container
Konkretes Beispiel
Gleiche Umgebung für Entwicklung und Betrieb
Ein Team betreibt eine kleine API für ein KI-gestütztes Produkt.
Installation auf jeder Maschine
Bibliotheken und Konfigurationen werden manuell eingerichtet. Ein Update funktioniert in der Entwicklung, aber nicht im Betrieb.
Versioniertes Container-Image
Die getestete Laufzeit wird als Image bereitgestellt. Entwicklung, Test und Betrieb verwenden dieselbe Grundlage.
Container machen die Umgebung zu einem überprüfbaren Teil des Produkts.
Einordnung
Vorteile und Grenzen
Das spricht dafür
- Wiederholbare Laufzeit: Anwendung und Abhängigkeiten sind gemeinsam versioniert und reproduzierbar.
- Klare Isolation: Dienste lassen sich mit eigenen Konfigurationen und Ressourcen voneinander trennen.
- Einfachere Übergaben: Ein geprüftes Image kann über verschiedene Umgebungen hinweg genutzt werden.
- Gute Automatisierbarkeit: Build, Test und Release lassen sich auf denselben Bauplan stützen.
Das solltest du beachten
- Images brauchen Pflege: Abhängigkeiten und Basisimages müssen regelmäßig aktualisiert und geprüft werden.
- Daten gehören nicht ins Image: Persistente Daten und Zugangsinformationen brauchen eigene sichere Wege.
- Ressourcen sind begrenzt: CPU, Speicher und bei KI auch GPU-Zugriff müssen passend konfiguriert werden.
- Kein Ersatz für Orchestrierung: Viele Container auf vielen Maschinen benötigen zusätzliche Betriebsmechanismen.
Vertiefung · für FortgeschritteneVom Bauplan zur laufenden Anwendung
Container trennen die unveränderliche Anwendungsvorlage von ihrer konkreten Ausführung.
isolierte laufende Anwendung