Der erste Docker-Build dauert Minuten, der zweite nur Sekunden – solange niemand die Anweisungsreihenfolge ändert. Dabei entscheidet oft allein die Reihenfolge im Dockerfile, ob der Cache greift oder nicht.
Das kennt jeder, der einmal ein Dockerfile (das Baurezept für ein Container-Image) geschrieben hat. Wer die Reihenfolge nicht versteht, wartet bei jeder kleinen Änderung wieder so lange wie beim ersten Mal.
Der Build-Cache ist ein Speicher für fertige Schichten. Ein Docker-Image besteht aus Schichten: Jede Anweisung wie FROM, RUN oder COPY erzeugt genau eine, die auf der vorherigen aufbaut. Beim Neubau prüft Docker jede Anweisung von oben nach unten und übernimmt unveränderte Schichten unverändert. Sobald sich eine Anweisung ändert, sind alle folgenden Schichten ungültig und werden neu gebaut – auch wenn sie selbst gleich geblieben sind.
Ein typisches Dockerfile für eine Node-Anwendung kopiert zuerst nur package.json, führt npm install aus und kopiert danach erst den Quellcode. Der Cache-Schlüssel einer Anweisung umfasst den Anweisungstext und den Inhalt kopierter Dateien: Ein geändertes package.json macht die Installations-Schicht ungültig, ein geänderter Quelltext nur die Kopier-Schicht. Eine reine Codeänderung baut also nur die letzte Schicht neu.
Verwechselt wird der Cache gern mit einem bloßen Zeitmesser. Er prüft keine Ähnlichkeit, sondern exakte Schlüssel. Steht COPY ganz oben, macht jede kleine Codeänderung die teure Installations-Schicht ungültig – und der Build dauert jedes Mal wie beim ersten Mal. Deshalb gilt: selten Geändertes wie das Basis-Image (das Image, auf dem das eigene aufbaut, etwa in der FROM-Anweisung) an den Anfang, häufig Geändertes wie den Quellcode an das Ende.
Der Build-Cache belohnt keine schönen Dockerfiles, sondern stabile Anweisungsreihen.
📌 Schichten · Cache-Schlüssel · Reihenfolge
📚 Cloud von Grund auf · Tag 5 von 30
#docker #devops #CloudHosting
Das kennt jeder, der einmal ein Dockerfile (das Baurezept für ein Container-Image) geschrieben hat. Wer die Reihenfolge nicht versteht, wartet bei jeder kleinen Änderung wieder so lange wie beim ersten Mal.
Der Build-Cache ist ein Speicher für fertige Schichten. Ein Docker-Image besteht aus Schichten: Jede Anweisung wie FROM, RUN oder COPY erzeugt genau eine, die auf der vorherigen aufbaut. Beim Neubau prüft Docker jede Anweisung von oben nach unten und übernimmt unveränderte Schichten unverändert. Sobald sich eine Anweisung ändert, sind alle folgenden Schichten ungültig und werden neu gebaut – auch wenn sie selbst gleich geblieben sind.
Ein typisches Dockerfile für eine Node-Anwendung kopiert zuerst nur package.json, führt npm install aus und kopiert danach erst den Quellcode. Der Cache-Schlüssel einer Anweisung umfasst den Anweisungstext und den Inhalt kopierter Dateien: Ein geändertes package.json macht die Installations-Schicht ungültig, ein geänderter Quelltext nur die Kopier-Schicht. Eine reine Codeänderung baut also nur die letzte Schicht neu.
Verwechselt wird der Cache gern mit einem bloßen Zeitmesser. Er prüft keine Ähnlichkeit, sondern exakte Schlüssel. Steht COPY ganz oben, macht jede kleine Codeänderung die teure Installations-Schicht ungültig – und der Build dauert jedes Mal wie beim ersten Mal. Deshalb gilt: selten Geändertes wie das Basis-Image (das Image, auf dem das eigene aufbaut, etwa in der FROM-Anweisung) an den Anfang, häufig Geändertes wie den Quellcode an das Ende.
Der Build-Cache belohnt keine schönen Dockerfiles, sondern stabile Anweisungsreihen.
📌 Schichten · Cache-Schlüssel · Reihenfolge
📚 Cloud von Grund auf · Tag 5 von 30
#docker #devops #CloudHosting
11 Std vor
