Viele bauen ihr Docker-Image nach jeder kleinen Codeänderung komplett neu. Dabei kann derselbe Bau Sekunden dauern – wenn die Zeilen richtig stehen.
Viele Einsteiger glauben, Docker baue nach einer Änderung einfach alles neu. Das klingt plausibel, denn sichtbar läuft der Bau ja vollständig durch. Zudem wirkt ein Dockerfile wie eine Art Skript, das man von oben nach unten ausführt.
Tatsächlich prüft Docker bei jedem Bau jede Anweisung gegen einen Cache, einen Vorrat bereits fertig gebauter Schichten. Eine Schicht entsteht dabei pro Anweisung im Dockerfile, etwa FROM, COPY oder RUN. Der Cache greift exakt, nicht ungefähr: Docker vergleicht den Anweisungstext und den Inhalt kopierter Dateien. Ab der ersten Änderung baut Docker alle folgenden Schichten neu; nur die Schichten davor kommen aus dem Cache.
Der Irrtum entsteht, weil die Reihenfolge der Zeilen harmlos aussieht. So landet COPY des ganzen Projektkatalogs gern ganz oben – und eine einzelne Quellcode-Änderung macht fast den gesamten Cache ungültig.
Bewährt hat sich die Reihenfolge FROM, WORKDIR, COPY nur der Abhängigkeitsdatei, Installationsbefehl, dann erst COPY des übrigen Codes. Steht COPY package.json und npm install vor COPY ., dauert ein Neubau nach einer reinen Code-Änderung nur Sekunden. Steht COPY . davor, wird bei jeder Änderung alles neu installiert – inklusive des Herunterladens aller Pakete.
Woran man es erkennt: Der Bau listet ab der geänderten Zeile jede Anweisung als neu ausgeführt statt mit dem Vermerk für einen Cache-Treffer. Eine reine Code-Änderung löst dann ein neues Installieren der Abhängigkeiten aus.
Der Build-Cache heißt also nicht „schneller, weil Docker klug ist“, sondern „schnell nur bis zur ersten geänderten Zeile“. Selten Geändertes gehört nach oben, häufig Geändertes nach unten.
📌 Build-Cache · Schicht-Reihenfolge · Dockerfile
📚 Cloud von Grund auf · Tag 22 von 30
#docker #devops #CloudHosting
Viele Einsteiger glauben, Docker baue nach einer Änderung einfach alles neu. Das klingt plausibel, denn sichtbar läuft der Bau ja vollständig durch. Zudem wirkt ein Dockerfile wie eine Art Skript, das man von oben nach unten ausführt.
Tatsächlich prüft Docker bei jedem Bau jede Anweisung gegen einen Cache, einen Vorrat bereits fertig gebauter Schichten. Eine Schicht entsteht dabei pro Anweisung im Dockerfile, etwa FROM, COPY oder RUN. Der Cache greift exakt, nicht ungefähr: Docker vergleicht den Anweisungstext und den Inhalt kopierter Dateien. Ab der ersten Änderung baut Docker alle folgenden Schichten neu; nur die Schichten davor kommen aus dem Cache.
Der Irrtum entsteht, weil die Reihenfolge der Zeilen harmlos aussieht. So landet COPY des ganzen Projektkatalogs gern ganz oben – und eine einzelne Quellcode-Änderung macht fast den gesamten Cache ungültig.
Bewährt hat sich die Reihenfolge FROM, WORKDIR, COPY nur der Abhängigkeitsdatei, Installationsbefehl, dann erst COPY des übrigen Codes. Steht COPY package.json und npm install vor COPY ., dauert ein Neubau nach einer reinen Code-Änderung nur Sekunden. Steht COPY . davor, wird bei jeder Änderung alles neu installiert – inklusive des Herunterladens aller Pakete.
Woran man es erkennt: Der Bau listet ab der geänderten Zeile jede Anweisung als neu ausgeführt statt mit dem Vermerk für einen Cache-Treffer. Eine reine Code-Änderung löst dann ein neues Installieren der Abhängigkeiten aus.
Der Build-Cache heißt also nicht „schneller, weil Docker klug ist“, sondern „schnell nur bis zur ersten geänderten Zeile“. Selten Geändertes gehört nach oben, häufig Geändertes nach unten.
📌 Build-Cache · Schicht-Reihenfolge · Dockerfile
📚 Cloud von Grund auf · Tag 22 von 30
#docker #devops #CloudHosting
11 Std vor
