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.gz

Um 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?

  1. ADas rm nach && wird beim Build nicht ausgeführt. rm in eine eigene RUN-Anweisung auslagern
  2. BGelöschte Dateien bleiben als Build-Cache im Image. Das Image mit docker build --no-cache neu bauen
  3. 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.

Dieses Thema üben Zur Themenseite

Weitere Fragen zu Grundlagen von Cloud und Containern

  1. Fünf Images legen jeweils eine eigene Schicht von 30 MB über dasselbe Basis-Image (120 MB). Komprimierung der Schichten und Platzbedarf der Metadaten werden vernachlässigt. Wie viel Festplattenplatz belegen die Images, wenn alle fünf auf einen Server geholt werden (pull)?
  2. Welche Kombination gibt für das obige Dockerfile richtig an, welcher Befehl beim Bauen des Images mit docker build und welcher beim Starten eines Containers mit docker run ausgeführt wird?
  3. Das aus dem obigen Dockerfile gebaute Image pinger wird mit docker run pinger example.com gestartet. Welcher Befehl wird im Container ausgeführt?
  4. Aus dem Image nginx, einem Webserver, der auf Port 80 lauscht, wird mit dem obigen Befehl ein Container gestartet. Die IP-Adresse des Hosts sei 192.0.2.10, und es gebe keine Einschränkungen etwa durch eine Firewall. Mit welcher URL erreicht man diesen Webserver vom Browser eines anderen PCs im selben Netzwerk?
  5. Das obige Dockerfile (B) ist aus Dockerfile (A) entstanden, in dem RUN npm ci nach COPY . . stand, indem die Reihenfolge so geändert wurde, dass zuerst nur die Abhängigkeitsdateien kopiert werden. npm ci dauert 120 Sekunden, npm run build 30 Sekunden und COPY . . 2 Sekunden; die Zeit der übrigen Anweisungen ist vernachlässigbar. Das Image wird 20-mal am Tag neu gebaut, wobei sich jeweils nur der Quellcode unter src ändert (package.json und package-lock.json bleiben unverändert). Um wie viel ist die gesamte Build-Zeit pro Tag bei B kürzer als bei A, wenn der Cache des vorherigen Builds genutzt werden kann?