Kleine Codezeile geändert, und der Docker-Build läuft wieder minutenlang. Der Schuldige ist meist nicht Docker, sondern die Reihenfolge der Anweisungen im Dockerfile.

Es geht um den Build-Cache, die Wiederverwendung bereits gebauter Schichten beim Image-Neubau. Er entscheidet, ob eine Änderung in Sekunden oder in Minuten fertig ist.

Zuerst erstellt Docker aus jeder Anweisung im Dockerfile, dem Textrezept für ein Container-Image, genau eine Schicht. FROM, RUN und COPY bauen also einen Stapel auf, bei dem jede Schicht auf der vorherigen ruht. Man kann sich das wie gefrorene Zwischenstände vorstellen. Ändert sich nichts, wird eine Schicht einfach wiederverwendet.

Dann prüft Docker beim Neubau jede Anweisung von oben nach unten. Der Cache-Schlüssel umfasst dabei den Anweisungstext und den Inhalt kopierter Dateien. Ist beides unverändert, kommt die Schicht aus dem Cache. Ein unverändertes package.json lässt die Installation also unberührt.

Danach endet die Wiederverwendung an der ersten veränderten Anweisung. Im Stapel heißt das: Alles unterhalb der ersten veränderten Schicht bleibt gültig, alles oberhalb wird neu gebaut. Ein geändertes package.json macht die Installations-Schicht bewusst ungültig, weil ja wirklich neu installiert werden muss.

Zuletzt entscheidet die Reihenfolge über die Dauer: erst die Abhängigkeitsliste kopieren, dann die Pakete installieren, dann den Quellcode. Wird der ganze Code per COPY ganz oben kopiert, macht jede Zeilenänderung die teure Installation ungültig. Der Build dauert dann wieder so lange wie beim ersten Mal.

Seltener Geändertes gehört nach oben, häufig Geändertes nach unten. So bleibt bei einer reinen Codeänderung nur die unterste Schicht übrig.

📌 Build-Cache · Schichten · Reihenfolge

📚 Cloud von Grund auf · Tag 22 von 30
#docker #devops #CloudHosting