Was ist Container-Image?

Schreibgeschützte Vorlage, aus der Container erzeugt werden. Sie legt die Dateien einer Anwendung wie ausführbare Dateien, Bibliotheken und Einstellungen in Schichten übereinander und fügt eine Konfiguration wie den Startbefehl hinzu; einen Betriebssystemkernel enthält sie nicht. Images werden aus einem Dockerfile o. Ä. gebaut und über Registries gespeichert und verteilt. Ein Image wird über Repository-Namen und Tag angegeben (zum Beispiel web:1.4) oder eindeutig über einen aus seinem Inhalt berechneten Digest (sha256:…). Identische Schichten werden von mehreren Images gemeinsam genutzt.

Japanische Bezeichnung: コンテナイメージ

„Container-Image“ kommt in 3 Übungsfragen aus 1 Themen vor, z. B. Grundlagen von Cloud und Containern.

Fachgebiet: Grundlagen von Cloud und Containern

Wie Schichten funktionieren

Jede Dockerfile-Anweisung, die Dateien ändert (RUN, COPY usw.), wird zu einer Schicht. Schichten werden über einen aus ihrem Inhalt berechneten Digest identifiziert; Images auf demselben Basis-Image teilen sich daher diese Schicht und laden und speichern sie nur einmal. Wird eine Datei in einer späteren Schicht gelöscht, bleibt der Inhalt der früheren Schicht im Image; große temporäre Dateien entfernt man daher in derselben Anweisung oder hält sie mit einem Multi-Stage-Build aus dem endgültigen Image heraus.

Tags und Digests

Ein Tag wie latest oder web:1.4 ist ein von Menschen vergebener Name und kann später auf ein anderes Image umgesetzt werden. Ein Digest wird aus dem Inhalt des Images berechnet und ändert sich, wenn sich auch nur ein Bit unterscheidet. In der Produktion oder überall dort, wo genau das Getestete verwendet werden muss, gibt man Images über ihren Digest an.

Images klein und sicher halten

Lässt man Compiler und Paketverwaltungswerkzeuge weg, die zur Laufzeit nicht gebraucht werden, wird das Image kleiner, schneller geholt und bietet Schwachstellen weniger Angriffsfläche. Ein typisches Verfahren ist ein Multi-Stage-Build, der eine Build-Stage von einer Laufzeit-Stage trennt. Geheime Werte kommen nicht ins Image, sondern werden beim Start übergeben.

Jetzt üben: Fragen zu Container-Image

Welche Beschreibung des Verhältnisses zwischen einem Container-Image und einem Container ist richtig?

AWird ein Container angehalten, werden die im Container vorgenommenen Änderungen automatisch in das Image zurückgeschrieben und überschreiben das ursprüngliche Image
BEin Image ist eine schreibgeschützte Vorlage, und aus einem Image lassen sich mehrere Container starten, von denen jeder eine eigene beschreibbare Schicht hat
CAus einem Image kann gleichzeitig nur ein Container gestartet werden; für einen zweiten muss das Image zuvor unter einem anderen Namen kopiert werden

Antwort und Erläuterung anzeigen

Antwort: B. Ein Image ist eine schreibgeschützte Vorlage, und aus einem Image lassen sich mehrere Container starten, von denen jeder eine eigene beschreibbare Schicht hat

Ein Image ist eine schreibgeschützte Vorlage, die die Dateien und Einstellungen bündelt, die zum Ausführen einer Anwendung nötig sind, und ein Container ist eine aus einem Image erzeugte Ausführungseinheit. Beim Erzeugen eines Containers wird über die Schichten (Layer) des Images eine beschreibbare Schicht gelegt, die nur diesem Container gehört. Aus einem Image lassen sich daher viele Container starten, und Änderungen in einem Container wirken sich weder auf andere Container noch auf das Image aus. Soll eine Änderung in einem Image erhalten bleiben, ändert man üblicherweise das Dockerfile und baut das Image neu.

In einem Kubernetes-Deployment wird das Container-Image in der Pod-Vorlage auf eine neue Version geändert. Was geschieht mit der Standard-Update-Strategie (RollingUpdate)?

AEin neues ReplicaSet wird erzeugt; Pods der neuen Version kommen hinzu, während Pods der alten Version abgebaut werden. Das alte ReplicaSet bleibt für ein Rollback mit 0 Pods bestehen
BDas Container-Image in den laufenden Pods wird an Ort und Stelle durch die neue Version ersetzt, ohne die Pods neu zu erzeugen, sodass sich weder IP-Adressen noch Namen der Pods ändern
CAlle Pods der alten Version werden gleichzeitig gelöscht und dann die Pods der neuen Version gemeinsam erzeugt, sodass der Dienst während des Updates vorübergehend ausfällt

Antwort und Erläuterung anzeigen

Antwort: A. Ein neues ReplicaSet wird erzeugt; Pods der neuen Version kommen hinzu, während Pods der alten Version abgebaut werden. Das alte ReplicaSet bleibt für ein Rollback mit 0 Pods bestehen

Ändert sich die Pod-Vorlage, erzeugt ein Deployment ein ReplicaSet für die neue Vorlage und baut die Pods des alten ReplicaSets schrittweise ab, während es prüft, dass die neuen Pods bereit sind. Auch während des Updates bearbeitet daher eine bestimmte Zahl von Pods weiter Anfragen. Das alte ReplicaSet bleibt mit 0 Pods erhalten, sodass kubectl rollout undo zur vorherigen Version zurückkehren kann. Die Strategie, die zuerst alle Pods löscht und dann neu erzeugt, heißt Recreate und wird nur verwendet, wenn sie ausdrücklich angegeben ist.

Häufige Fragen

Was ist der Unterschied zwischen einem Image und einem Container?

Ein Image ist eine schreibgeschützte Vorlage, und ein Container ist eine daraus erzeugte laufende (oder angehaltene) Instanz. Aus einem Image lassen sich viele Container erzeugen, und jeder erhält seine eigene beschreibbare Schicht. Das ähnelt dem Verhältnis zwischen einer Programmdatei und einem Prozess.

Liefert der Tag latest immer die neueste Version?

latest ist ein gewöhnlicher Tag ohne besondere Bedeutung. Er ist nur der Standardname, der verwendet wird, wenn kein Tag angegeben ist, und zeigt nur dann auf eine neue Version, wenn jemand ihn umsetzt. Um eine Version festzulegen, gibt man einen konkreten Tag oder einen Digest an.