DevOps

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

Was Kubernetes macht Einen einzelnen Docker-Container auf einer Maschine starten Sie von Hand. Fünfzig Container auf zehn Maschinen sind eine andere Sache: sie neu starten, wenn sie abstürzen, verschieben, wenn eine Maschine ausfällt, den Datenverkehr zwischen ihnen aufteilen, sie ohne Ausfallzeit aktualisieren. Kubernetes (kurz K8s) ist das System, das diese Verwaltung für Sie übernimmt. Was ist Kubernetes? Kubernetes ist eine Open-Source-Plattform für die Container-Orchestrierung. Sie wurde 2014 von Google entwickelt, basierend auf 15 Jahren Erfahrung in der Verwaltung von Containern im großen Maßstab, und wird jetzt von der Cloud Native Computing Foundation (CNCF) gepflegt. ...