Docker

Jeder Aufruf einer gehosteten LLM-API schickt Ihren Prompt an den Server von jemand anderem und berechnet Ihnen Kosten pro Token. Fällt das Netzwerk aus, antwortet sie nicht mehr. Ollama beseitigt beide Probleme: Es lädt ein Modell mit offenen Gewichten auf Ihren Rechner und stellt es über eine REST-API auf localhost:11434 bereit. Eine einzige Binärdatei ist Modellverwaltung, Chat-Client und Server zugleich. Was Ollama tatsächlich macht Ollama kapselt llama.cpp und ähnliche Inferenz-Engines, sodass Sie nie ein Compiler-Flag oder einen CUDA-Bibliothekspfad anfassen müssen. ollama pull llama3.2 lädt eine quantisierte Modelldatei (GGUF-Format) aus Ollamas eigener Registry herunter statt von Hugging Face, kann aber auch GGUF-Dateien von dort importieren. Beim Ausführen des Modells übergibt Ollama diese Gewichte an einen Hintergrundserver, der sie in den RAM (oder VRAM, falls eine kompatible GPU gefunden wird) lädt, sie einige Minuten nach der letzten Anfrage im Speicher hält, damit die nächste Anfrage schnell beantwortet wird, und sie entlädt, sobald keine Anfragen mehr kommen. ...

docker build && docker push vom eigenen Rechner aus funktioniert, solange niemand sonst dasselbe Image veröffentlichen muss oder es nicht bei jedem Merge passieren muss, ohne dass Sie an der Tastatur sitzen. GitHub Actions führt diesen Build auf den Runnern von GitHub aus, taggt das Image passend zu dem, was den Workflow ausgelöst hat, und pusht es zu einer Registry, aus der Ihr Deploy-Schritt pullen kann. Nichts läuft lokal. Was es braucht, um ein Docker-Image aus der CI heraus zu bauen und zu pushen Fünf Teile müssen vorhanden sein, bevor ein Runner ein Image pushen kann: ...

Wo die Umgebungsvariablen eines Containers landen Starten Sie einen Container mit -e DB_PASSWORD=hunter2 und prüfen Sie ihn mit docker inspect: 1 2 docker run -d --name api -e DB_PASSWORD=hunter2 nginx:alpine docker inspect --format '{{json .Config.Env}}' api 1 ["DB_PASSWORD=hunter2","PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"] Das Passwort steht dort im Klartext, lesbar für jeden mit Zugriff auf den Docker-Socket, für docker exec api env und für jeden Prozess, der im Container läuft. Das ist kein Bug — genau dafür sind Umgebungsvariablen da. Das Problem ist, sie für Werte zu verwenden, die niemals so sichtbar sein sollten. ...

Warum ein Docker-Image zehnmal größer ist als die App Ein Node-Service mit ein paar hundert Kilobyte Quellcode landet als Image mit über 1 GB. Das ist das normale Ergebnis eines funktionierenden Builds, kein Fehler in einer bestimmten Zeile. Das Gewicht kommt von einem Basis-Image, das ein komplettes Betriebssystem mitschleppt, einer Build-Toolchain, die die laufende App nie aufruft, und einem Paketmanager-Cache, um den sich niemand kümmert. Sie zahlen dafür bei jedem Deploy: docker pull wird langsamer, und ein Vulnerability-Scanner meldet mehrere hundert zusätzliche Pakete. Auch der Speicherplatz summiert sich, über jeden Tag, an dem Sie je gepusht haben. Das zu beheben bedeutet, das Dockerfile neu zu schreiben, nicht die App. ...

Was ein schlechtes Dockerfile kostet 1 2 3 4 5 6 FROM node:latest COPY . . RUN npm install CMD ["node", "server.js"] Vier Zeilen, und jede kostet etwas. docker build führt npm install bei jeder Codeänderung erneut aus, weil COPY . . den Layer-Cache zerstört, bevor der Install-Schritt überhaupt eine Chance hat, wiederverwendet zu werden. Das fertige Image trägt die komplette Debian-Basis, den gesamten node_modules-Baum inklusive Dev-Abhängigkeiten und alle Build-Tools, die npm install zum Kompilieren nativer Module nachgeladen hat. Nichts davon wird verworfen. Der Container läuft als Root, weil ihm niemand etwas anderes sagt, und node:latest bedeutet, dass sich das Base-Image zwischen zwei Builds ändern kann, ohne dass irgendwo festgehalten wird, was Sie tatsächlich ausgeliefert haben. ...

Das Problem, das Compose löst Eine echte Anwendung ist selten nur ein Container. Eine Web-API braucht eine Datenbank, die Datenbank braucht ein Volume, damit ihre Daten einen Neustart überstehen, und dann kommen noch ein Redis-Cache und ein Hintergrund-Worker dazu. Das sind vier docker run-Befehle, jeder mit eigenen Flags für Ports, Volumes und Umgebungsvariablen, dazu ein gemeinsames Netzwerk. In der richtigen Reihenfolge. Jedes Mal, wenn Sie sich an die Arbeit setzen. ...

Warum zwei Container auf demselben Host sich standardmäßig nicht erreichen Starten Sie Postgres und Ihre API mit einem einfachen docker run, und die API kommt nicht an die Datenbank heran, obwohl beide Container auf derselben Maschine laufen. 1 2 docker run -d --name db postgres:16 docker run -d --name api myapp Beide landen auf der Standard-Bridge von Docker, auf der jeder Docker-Container landet, solange Sie nichts anderes angeben. Sie bekommen eine IP-Adresse. Eine Möglichkeit, sich gegenseitig über den Namen zu finden, fehlt jedoch — die API müsste also die interne IP der Datenbank fest eintragen, eine Adresse, die sich bei jedem Neustart des Containers ändert. ...

Docker und Podman führen dieselben Images mit denselben Befehlen aus. Was sie trennt, ist die Architektur: Podman hat keinen Hintergrund-Daemon und läuft standardmäßig rootless, während Docker das ausgereifte Tooling, Docker Desktop und erstklassige Compose-Unterstützung mitbringt. Im Folgenden die Unterschiede, die Ihre Arbeit wirklich betreffen: Daemon, root, Compose und Pods. Was ist Podman? Podman (Pod Manager) ist ein Tool zur Verwaltung von Containern und Pods, entwickelt von Red Hat als Open-Source-Alternative zu Docker. Seine Haupteigenschaft? Es benötigt keinen Daemon, der ausgeführt wird. ...

Was Docker wirklich macht Docker ist eine Open-Source-Plattform, die eine Anwendung mit allem, was sie zum Laufen braucht – Code, Bibliotheken, Runtime, Konfiguration – in einen Container verpackt, der sich auf jeder Maschine gleich verhält. Ein Umzug macht den Kompromiss greifbar. Sie haben zwei Möglichkeiten: Alle Gegenstände lose transportieren und hoffen, dass sie unversehrt ankommen Alles in organisierte, beschriftete und leicht zu bewegende Kartons packen Docker macht genau das mit Softwareanwendungen: Es verpackt sie in Container, die alles Notwendige zum Laufen enthalten. ...

Warum ein Container beim Neustart seine Daten verliert Schreiben Sie eine Zeile in eine Datenbank, die in einem Docker-Container läuft, stoppen Sie den Container und starten Sie ihn neu: Die Zeile ist weg. Jeder Container bekommt sein Dateisystem bei jedem Start frisch aus seinem Image. Alles, was der Container selbst schreibt – Datenbankdateien, Uploads, Logs –, landet in einer beschreibbaren Schicht, die verworfen wird, sobald der Container entfernt wird. Ein Docker-Volume ist der Weg, diese Daten außerhalb des Containers zu halten, wo sie erhalten bleiben. ...