Читать книгу Kubernetes - Kelsey Hightower - Страница 25

Die Begriffe »Docker Image Format« und »Container-Images« sind vielleicht ein wenig verwirrend. Das Image ist keine einzelne Datei, sondern eher eine Spezifikation für eine Manifest-Datei, die auf andere Dateien verweist. Das Manifest und die zugehörigen Dateien werden von den Benutzern oft als eine Einheit behandelt. Durch diese Indirektion sind ein effizienteres Abspeichern und Übermitteln möglich. Neben diesem Format gibt es noch eine API zum Hoch- und Runterladen von Images in und aus einer Image Registry.

Container-Images bestehen aus einer Folge von Dateisystem-Layern, bei denen jede Schicht die vorigen Layer übernimmt und anpasst. Um das besser zu verstehen, wollen wir ein paar Container bauen. Beachten Sie, dass die Layer eigentlich von unten nach oben gestapelt werden, aber zum leichteren Verständnis gehen wir andersherum vor:

.

└── Container A: nur Basis-Betriebssystem, wie z.B. Debian

└── Container B: baut auf A auf, fügt Ruby v2.1.10 hinzu

└── Container C: baut auf A auf, fügt Golang v1.6 hinzu

Wir haben jetzt drei Container: A, B und C. B und C sind von A abgespalten (forked) und haben abgesehen von den Dateien des Basis-Containers keine Gemeinsamkeiten. Wir können jetzt noch weitergehen und zu B noch Rails (Version 4.2.6) hinzufügen. Vielleicht wollen wir noch eine alte Anwendung unterstützen, die eine ältere Version von Rails (Version 3.2.x) benötigt. Dazu können wir ein Container-Image bauen, das diese Anwendung basierend auf B unterstützt, um sie vielleicht irgendwann einmal nach Version 4 zu aktualisieren:

. (Fortsetzung von oben)

└── Container B: baut auf A auf, fügt Ruby v2.1.10 hinzu

└── Container D: baut auf B auf, fügt Rails v4.2.6 hinzu

└── Container E: baut auf B auf, fügt Rails v3.2.x hinzu

Konzeptionell gesehen baut jeder Layer eines Container-Image auf einem vorigen auf. Jeder Verweis auf einen Eltern-Layer ist ein Zeiger. Während es sich bei diesem Beispiel hier um einen einfachen Satz von Containern handelt, können andere Container mit realen Anwendungen Teil eines größeren und umfangreicheren gerichteten azyklischen Graphen sein.

Container-Images werden meist mit einer Container-Konfigurationsdatei kombiniert, die Anweisungen zum Einrichten der Container-Umgebung und Ausführen eines Anwendungs-Entrypoint enthält. Die Container-Konfiguration besitzt auch oft Informationen zum Einrichten der Netzwerkumgebung, zu Namensräumen, Ressourcen-Begrenzungen (cgroups) und welche syscall-Einschränkungen auf eine laufende Container-Instanz angewendet werden sollten. Das Root-Dateisystem und die Konfigurationsdatei des Containers werden meist im Docker-Image-Format zusammengefasst.

Container gehören zu einer von zwei Hauptkategorien:

 System-Container

 Anwendungs-Container

System-Container versuchen, virtuelle Maschinen nachzubilden, und führen häufig einen vollständigen Boot-Prozess durch. Oft enthalten sie eine Reihe von System-Diensten, die sich gerne in einer VM finden, wie zum Beispiel ssh, cron und syslog. Als Docker noch neu war, waren diese Arten von Containern sehr verbreitet. Mit der Zeit betrachtete man sie aber als schlechte Praxis und man hat sich eher auf Anwendungs-Container konzentriert.

Anwendungs-Container unterscheiden sich von System-Containern darin, dass sie im Allgemeinen nur ein einzelnes Programm in sich laufen lassen. Das mag eine unnötige Einschränkung sein, aber es bietet die perfekte Granularitäts-Stufe für das Zusammenstellen skalierbarer Anwendungen und ist eine Design-Philosophie, die durch Pods stark gefördert wird (auf Pods gehen wir im Detail in Kap. 5 ein).