Praxisnahe, zeitlose Guides fuer Entwickler. Jeder baut auf echten Befehlen und lauffaehigen Beispielen auf und sagt klar, wann man das behandelte Werkzeug nicht einsetzen sollte.
Unten steht alles, neueste zuerst.
Praxisnahe, zeitlose Guides fuer Entwickler. Jeder baut auf echten Befehlen und lauffaehigen Beispielen auf und sagt klar, wann man das behandelte Werkzeug nicht einsetzen sollte.
Unten steht alles, neueste zuerst.
Fragen Sie ein allgemeines LLM nach der Rückgaberichtlinie Ihres Unternehmens oder den Support-Tickets der letzten Woche, und es wird entweder sagen, dass es das nicht weiß, oder etwas Plausibles erfinden. Sein Wissen endet dort, wo die Trainingsdaten aufhören. Es hat Ihre Dokumente nie gesehen und kann sie nicht mitten im Gespräch nachschlagen. Retrieval-Augmented Generation (RAG) behebt genau das: Bevor das Modell antwortet, findet ein separater Schritt den relevanten Text in Ihren eigenen Daten und gibt ihn dem Modell als Teil des Prompts mit. ...
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: ...
Führen Sie kubectl run nginx --image=nginx:1.27 aus, und Kubernetes erstellt genau einen Pod namens nginx. Löschen Sie ihn mit kubectl delete pod nginx, und er ist endgültig weg — niemand bemerkt es, niemand ersetzt ihn. Ein Pod ist die kleinste bereitstellbare Einheit in Kubernetes: ein oder mehrere Container, die sich einen Netzwerk-Namespace und eine Reihe von Volumes teilen und zusammen auf einem einzelnen Node eingeplant werden. Dieser einzelne Pod ist in Produktion eine Sackgasse. Stürzt der Container darin ab, startet der kubelet ihn an Ort und Stelle neu. Startet der Node neu, oder löscht jemand den Pod, stellt ihn nichts wieder her. Ein nackter Pod weiß nicht, dass er eigentlich existieren sollte. ...
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. ...