DevOps

Eine Abfrage, die 200ms gegen Ihre Datenbank braucht, braucht auch beim millionsten Aufruf noch 200ms, und jeder dieser Aufrufe konkurriert um dieselben Verbindungen, dieselbe Disk-I/O und dieselbe CPU. Redis hält die Antwort im Speicher, auf einem Server, der sonst nichts tut, sodass der millionste Lesevorgang einen Netzwerk-Roundtrip kostet statt eines Query-Plans. Was Redis als Cache wirklich macht Redis ist ein Key-Value-Store im Arbeitsspeicher. Werte liegen im RAM, daher liegen Lese- und Schreibzeiten im Sub-Millisekunden-Bereich statt bei den zehn bis hundert Millisekunden, die eine relationale Abfrage kostet, sobald Joins, belastete Indizes oder ein ausgelasteter Connection-Pool ins Spiel kommen. Redis steht neben Ihrer Datenbank, nicht an ihrer Stelle: Ihre Anwendung fragt zuerst Redis und geht nur dann zur Datenbank, wenn Redis die Antwort nicht hat. ...

Was zwischen Browser und Ihrer App steht Rufen Sie im Browser example.com auf, erreicht die Anfrage nie direkt den Prozess, der Ihren Code ausführt. Sie trifft zuerst auf etwas anderes: einen Server, der die Anfrage liest, entscheidet, welches Backend antworten soll, sie dorthin weiterleitet und die Antwort zurückschickt, als hätte er sie selbst erzeugt. Dieser Server ist ein Reverse Proxy. Nginx, Caddy, Traefik und HAProxy übernehmen alle diese Aufgabe, ebenso der Load Balancer vor einem Kubernetes-Cluster. Das Grundmuster ändert sich nie: Clients sprechen nur mit dem Proxy, mit sonst nichts. Die eigentlichen Server bleiben dahinter, egal wie viele es sind und wo sie laufen. ...

Sie holen sich das neueste main per Pull, und Git bricht ab mit CONFLICT (content): Merge conflict in checkout.js. Sie lösen den Konflikt, und im Log steht jetzt ein Commit namens Merge branch 'main' into feature/checkout, oben auf den drei Commits, die Sie tatsächlich geschrieben haben. Vier Commits, eine einzige echte Änderung. Ein Kollege, der diese Historie nächsten Monat liest, kann nicht erkennen, welcher welcher ist. git merge und git rebase beantworten dieselbe Frage: Wie bringe ich meinen Branch auf den Stand der Änderungen, die anderswo gemacht wurden. Sie hinterlassen sehr unterschiedliche Spuren, und die falsche Wahl auf einem geteilten Branch richtet echten Schaden an. ...

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. ...