Viele Dockerfiles beginnen damit, das gesamte Projekt per COPY zu kopieren. Dabei zerstört jede Quellcode-Änderung den gesamten Build-Cache.
Wer ein Dockerfile schreibt, begegnet sofort dem Build-Cache. Wer ihn nicht kennt, wartet bei jedem Neubau Minuten statt Sekunden.
Ein Dockerfile ist eine Liste von Anweisungen, die mit docker build zu einem Image (einer startfertigen Vorlage für Container) verarbeitet wird. Jede Anweisung erzeugt eine Schicht, also das Änderungsprotokoll dieser einen Zeile im Dateisystem. Das Image ist ein Stapel dieser Schichten; docker run startet daraus den Container.
Der Cache prüft beim Neubau jede Anweisung von oben nach unten. Ist eine Zeile unverändert, wird ihre Schicht samt aller darunterliegenden wiederverwendet. Ab der ersten geänderten Zeile wird alles Folgende neu gebaut, auch wenn es sich gar nicht verändert hat.
Konkret: Zuerst FROM, also die Wahl des Basis-Images als Startpunkt, dann COPY der Paketliste, dann RUN zur Installation der Abhängigkeiten, erst danach COPY des Quellcodes und der Startbefehl. Ändert sich nur der Quellcode, bleibt die teure Installation im Cache. Steht die Quellcode-Zeile dagegen oben, läuft RUN bei jeder kleinen Änderung erneut.
Verwechselt wird der Cache gern mit dem Build-Kontext, also dem Verzeichnis, das dem Build als Quelle dient. Der Kontext bestimmt, welche Dateien überhaupt an COPY übergeben werden; der Cache bestimmt, welche Schichten wiederverwendet werden. Eine .dockerignore-Datei hält Unnötiges wie .git aus dem Kontext fern und beschleunigt den Build zusätzlich.
Der Build-Cache belohnt nicht die schönste Zeile, sondern die stabilste Reihenfolge: Selten Geändertes nach oben, Häufig Geändertes nach unten.
📌 Layer · Build-Cache · Reihenfolge im Dockerfile
📚 Cloud von Grund auf · Tag 4 von 30
#docker #devops #CloudHosting
Wer ein Dockerfile schreibt, begegnet sofort dem Build-Cache. Wer ihn nicht kennt, wartet bei jedem Neubau Minuten statt Sekunden.
Ein Dockerfile ist eine Liste von Anweisungen, die mit docker build zu einem Image (einer startfertigen Vorlage für Container) verarbeitet wird. Jede Anweisung erzeugt eine Schicht, also das Änderungsprotokoll dieser einen Zeile im Dateisystem. Das Image ist ein Stapel dieser Schichten; docker run startet daraus den Container.
Der Cache prüft beim Neubau jede Anweisung von oben nach unten. Ist eine Zeile unverändert, wird ihre Schicht samt aller darunterliegenden wiederverwendet. Ab der ersten geänderten Zeile wird alles Folgende neu gebaut, auch wenn es sich gar nicht verändert hat.
Konkret: Zuerst FROM, also die Wahl des Basis-Images als Startpunkt, dann COPY der Paketliste, dann RUN zur Installation der Abhängigkeiten, erst danach COPY des Quellcodes und der Startbefehl. Ändert sich nur der Quellcode, bleibt die teure Installation im Cache. Steht die Quellcode-Zeile dagegen oben, läuft RUN bei jeder kleinen Änderung erneut.
Verwechselt wird der Cache gern mit dem Build-Kontext, also dem Verzeichnis, das dem Build als Quelle dient. Der Kontext bestimmt, welche Dateien überhaupt an COPY übergeben werden; der Cache bestimmt, welche Schichten wiederverwendet werden. Eine .dockerignore-Datei hält Unnötiges wie .git aus dem Kontext fern und beschleunigt den Build zusätzlich.
Der Build-Cache belohnt nicht die schönste Zeile, sondern die stabilste Reihenfolge: Selten Geändertes nach oben, Häufig Geändertes nach unten.
📌 Layer · Build-Cache · Reihenfolge im Dockerfile
📚 Cloud von Grund auf · Tag 4 von 30
#docker #devops #CloudHosting
2 Tage vor
