Grundlagen von Cloud und Containern
FROM alpine
COPY data.tar.gz /tmp/
RUN tar -xzf /tmp/data.tar.gz -C /opt && rm /tmp/data.tar.gzUm das 500 MB große Archiv data.tar.gz zu entpacken, wurde mit dem obigen Dockerfile ein Image gebaut. Obwohl das Archiv nach dem Entpacken im selben RUN gelöscht wurde, blieb das Image um die Größe des Archivs größer. Welche Kombination aus Ursache und Abhilfe ist am besten geeignet?
- ADas rm nach && wird beim Build nicht ausgeführt. rm in eine eigene RUN-Anweisung auslagern
- BGelöschte Dateien bleiben als Build-Cache im Image. Das Image mit docker build --no-cache neu bauen
- CDas Archiv bleibt in der Schicht, die die COPY-Anweisung erzeugt hat. Mit einem Multi-Stage-Build nur die entpackten Dateien in das endgültige Image kopieren
Antwort und Erläuterung anzeigen
Antwort: C. Das Archiv bleibt in der Schicht, die die COPY-Anweisung erzeugt hat. Mit einem Multi-Stage-Build nur die entpackten Dateien in das endgültige Image kopieren
Jede Dockerfile-Anweisung, die das Dateisystem ändert (etwa COPY oder RUN), wird zu einer Schicht, und ein Image ist die Übereinanderlagerung dieser Schichten. Wird eine Datei in einer späteren Schicht gelöscht, wird in der oberen Schicht nur eine Löschmarkierung vermerkt; das 500 MB große Archiv in der COPY-Schicht bleibt im Image. Entpackt man mit einem Multi-Stage-Build in einer anderen Stage und holt nur die entpackten Dateien mit COPY --from in die letzte Stage, ist das Archiv nicht im endgültigen Image enthalten. Herunterladen, Entpacken und Löschen innerhalb eines RUN ist ein weiterer Weg, der sich aber nicht für eine mit COPY hineingebrachte Datei eignet.
Weiter: 9 weitere Fragen zu Grundlagen von Cloud und Containern