Die meisten Neulinge wundern sich, warum ein kleiner Code-Fix den kompletten Docker-Build neu auslöst. Dabei entscheidet oft nur die Reihenfolge der Zeilen im Dockerfile über Sekunden oder Minuten Bauzeit.

Das Symptom: Nach jeder noch so kleinen Codeänderung läuft der Bau minutenlang durch. Pakete werden erneut installiert, obwohl sich daran nichts geändert hat. Der Build-Cache, also das Zwischenspeichern bereits gebauter Schritte, greift scheinbar nie.

Dahinter steckt das Schichtprinzip: Jede Zeile im Dockerfile (der Bauanleitung für ein Image) erzeugt eine eigene Schicht. Das fertige Image, also die unveränderliche Vorlage für Container, besteht aus diesen Schichten wie ein Stapel. Eine unveränderte Schicht wird aus dem Cache wiederverwendet. Ändert sich eine Zeile, wird sie neu gebaut, und alle folgenden ebenso, weil sie auf dem Ergebnis aufbauen. Steht COPY, das Kopieren eigener Dateien, früh im Dockerfile, macht jede Codeänderung den Rest ungültig.

Konkret: Ein Dockerfile beginnt mit FROM, dann RUN zum Installieren der Abhängigkeiten, dann erst COPY des Quellcodes. Wer umgekehrt erst den Code kopiert und danach RUN ausführt, baut die Abhängigkeiten bei jedem Fix neu. Die Regel lautet: Anweisungen mit selten ändernden Inhalten wie RUN an den Anfang, Anweisungen mit häufig ändernden Inhalten wie COPY ans Ende.

So prüft man es: Beim Bau die Ausgabe der Zeilen ansehen, die als wiederverwendet markiert sind. Zeigen die frühen Zeilen wie die Abhängigkeiten einen Treffer und startet der Neubau erst beim Kopieren des Quellcodes, stimmt die Anordnung.

Schichten sind keine Zufallsprodukte, sondern ein Stapel: Ein früher Treffer im Cache spart alles darunter. Ordnung im Dockerfile heißt Reihenfolge nach Änderungshäufigkeit.

📌 Dockerfile-Schichten · Build-Cache · Reihenfolge nach Änderungshäufigkeit

📚 Cloud von Grund auf · Tag 4 von 30
#docker #kubernetes #devops