Zehn Sekunden Codeänderung, dann wartet man fünf Minuten auf denselben Build. Schuld ist meist eine einzige Zeile an der falschen Stelle im Dockerfile.

Gemeint ist der Aufbau eines Container-Images aus einer Beschreibungsdatei, dem Dockerfile. Das Image ist die unveränderliche Vorlage, aus der Container gestartet werden. Jede Anweisung darin – etwa COPY zum Kopieren von Dateien oder RUN zum Ausführen eines Befehls – erzeugt eine eigene Schicht, und der Build-Cache entscheidet, welche davon neu berechnet werden muss.

Zuerst liest das Build-Werkzeug das Dockerfile von oben nach unten und prüft jede Anweisung gegen den Cache. Sind Anweisungstext und Inhalt kopierter Dateien unverändert, wird die vorhandene Schicht wiederverwendet. Das Ergebnis ist sofort da, ohne Rechenarbeit.

Dann stößt das Werkzeug auf die erste geänderte Anweisung, etwa ein neues COPY mit anderem Quellcode. Diese Schicht wird neu gebaut. Der Cache-Schlüssel umfasst dabei beide Teile: Anweisungstext und Dateiinhalte.

Danach sind alle folgenden Schichten ungültig, auch wenn sie selbst gleich geblieben sind. Steht die teure Installation der Abhängigkeiten unterhalb des Quellcode-Kopierens, muss sie bei jeder Codeänderung erneut laufen – der Build dauert dann wieder so lange wie beim ersten Mal.

Zuletzt dreht man die Reihenfolge um: erst die Abhängigkeitsliste wie package.json kopieren und installieren, danach erst den Quellcode. Eine reine Codeänderung baut dann nur noch die letzte Schicht neu, aus Minuten werden Sekunden. Eine .dockerignore-Datei hält zudem unnötige Dateien aus dem Build-Kontext fern.

Der Cache ist kein Automatik-Glück, sondern folgt der Reihenfolge der Anweisungen. Seltenes nach oben, Häufiges nach unten: Diese eine Sortierung entscheidet über die Dauer jedes Neubaus.

📌 Schichten · Cache-Schlüssel · Reihenfolge

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