Ein tiefer Einblick in die Schichten von Container-Images

Container revolutionieren die Softwareentwicklung, indem sie Prozesse wie virtuelle Maschinen effizient simulieren. Doch was steckt hinter diesem faszinierenden Konzept? In einem Artikel erklärt Ken Muse die grundlegenden Schichten von Container-Images. [...]

Container sind erstaunlich. Sie ermöglichen es einfachen Prozessen, wie virtuelle Maschinen zu agieren. Unter dieser Eleganz verbirgt sich eine Reihe von Mustern und Praktiken, die letztlich alles zum Funktionieren bringen. An der Wurzel des Designs stehen die Schichten (Layer). (c) dotnetpro

Container sind erstaunlich. Sie ermöglichen es einfachen Prozessen, wie virtuelle Maschinen zu agieren. Unter dieser Eleganz verbirgt sich eine Reihe von Mustern und Praktiken, die letztlich alles zum Funktionieren bringen. An der Wurzel des Designs stehen die Schichten (Layer). Schichten sind die grundlegende Methode zur Speicherung und Verteilung der Inhalte eines containerisierten Dateisystems. Das Design ist sowohl überraschend einfach als auch sehr leistungsstark.
Beim Erstellen eines Images verwenden Sie typischerweise eine Dockerfile, um die Inhalte des Containers zu definieren. Sie enthält eine Reihe von Befehlen wie:

FROM scratch
RUN echo „hello“ > /work/message.txt
COPY content.txt /work/content.txt
RUN rm -rf /work/message.txt
Code kopieren

Unter der Haube wird die Container-Engine diese Befehle in der Reihenfolge ausführen und für jeden einen Layer erstellen. Aber was passiert da wirklich? Am einfachsten ist es, sich jede Schicht als ein Verzeichnis vorzustellen, das alle modifizierten Dateien enthält.

FROM scratch bedeutet, dass dieser Container ohne Inhalte startet und dies die erste Schicht ist, die durch ein leeres Verzeichnis /img/layer1 repräsentiert werden kann.

Die zweite Schicht wird durch die Ausführung des nächsten Dockerfile-Befehls erstellt, der eine Datei in /work/message.txt schreibt. Diese Inhalte werden in /img/layer2/work/message.txt geschrieben.

Die dritte Schicht entsteht durch die Anwendung des nächsten Befehls, der die Datei content.txt vom Host in dieses Verzeichnis kopiert.

Um diese Layer zu teilen, ist der einfachste Ansatz, eine komprimierte .tar.gz für jedes Verzeichnis zu erstellen. Um die Gesamtdateigröße zu reduzieren, werden alle Dateien, die unveränderte Kopien von Daten aus einer vorherigen Schicht sind, entfernt. Ein „whiteout file“ könnte als Platzhalter verwendet werden, um zu verdeutlichen, wann eine Datei gelöscht wurde.

Das Erstellen vieler Images auf diese Weise resultiert in vielen layer1-Verzeichnissen. Um sicherzustellen, dass der Name einzigartig ist, wird die komprimierte Datei auf der Grundlage eines Hashwerts des Inhalts benannt. Dies ähnelt der Funktionsweise von Git. Es identifiziert identische Inhalte und erkennt gleichzeitig jede Beschädigung der Dateien während des Downloads. Der Hashwert des Inhalts muss mit dem Dateinamen übereinstimmen, andernfalls ist die Datei beschädigt.

Um die Ergebnisse reproduzierbar zu machen, ist eine weitere Sache erforderlich – eine Datei, die erklärt, wie die Schichten angeordnet sind (ein Manifest). Das Manifest identifiziert, welche Dateien heruntergeladen werden und in welcher Reihenfolge sie entpackt werden müssen. Dies ermöglicht das Wiederherstellen der Verzeichnisstrukturen. Es bietet außerdem einen wichtigen Vorteil: Schichten können zwischen Bildern wiederverwendet und geteilt werden, was die lokalen Speicheranforderungen minimiert.

Wenn eine Container-Instanz läuft, benötigt sie ein Dateisystem, das bereitgestellt werden muss. In erster Linie muss ein Directory mit allen Dateien, die verfügbar sein müssen, erstellt werden. Im Wesentlichen umfasst der Prozess des Erstellens eines Snapshots das Herunterladen des Manifests und das Erstellen einer Liste von Schichten. Ein „diff applier“ ist dafür verantwortlich, die Inhalte der komprimierten Schichtendatei zu entpacken und die Änderungen auf das aktive Snapshot anzuwenden.

Weitere Erklärungen finden Sie im Blog von Ken Muse.

Dieser Artikel stammt von com! professional.


Mehr Artikel

News

KI ist das neue Lernfach für uns alle

Die Mystifizierung künstlicher Intelligenz treibt mitunter seltsame Blüten. Dabei ist sie weder der Motor einer schönen neuen Welt, noch eine apokalyptische Gefahr. Sie ist schlicht und einfach eine neue, wenn auch höchst anspruchsvolle Technologie, mit der wir alle lernen müssen, sinnvoll umzugehen. Und dafür sind wir selbst verantwortlich. […]

Case-Study

Erfolgreiche Migration auf SAP S/4HANA

Energieschub für die IT-Infrastruktur von Burgenland Energie: Der Energieversorger hat zusammen mit Tietoevry Austria die erste Phase des Umstieges auf SAP S/4HANA abgeschlossen. Das burgenländische Green-Tech-Unternehmen profitiert nun von optimierten Finanz-, Logistik- und HR-Prozessen und schafft damit die Basis für die zukünftige Entflechtung von Energiebereitstellung und Netzbetrieb. […]

FH-Hon.Prof. Ing. Dipl.-Ing. (FH) Dipl.-Ing. Dr. techn. Michael Georg Grasser, MBA MPA CMC, Leiter FA IT-Infrastruktur der Steiermärkischen Krankenanstaltengesellschaft m.b.H. (KAGes). (c) © FH CAMPUS 02
Interview

Krankenanstalten im Jahr 2030

Um sich schon heute auf die Herausforderungen in fünf Jahren vorbereiten zu können, hat die Steiermärkische Krankenanstaltengesellschaft (KAGes) die Strategie 2030 formuliert. transform! sprach mit Michael Georg Grasser, Leiter der Fachabteilung IT-Infrastruktur. […]

News

Risiken beim Einsatz von GenAI in vier Schritten senken

Die Themen Datenschutz und Modellverwaltung sind in der Datenwissenschaft zwar nicht neu, doch GenAI hat ihnen eine neue Dimension der Komplexität verliehen, die Datenschutzbeauftragte vor neue Herausforderungen stellt. Die Data-Science-Spezialisten von KNIME haben die Potenziale und Risiken der KI-Nutzung beim Einsatz bei der Datenarbeit zusammengefasst und empfehlen vier Schritte zur Risikominimierung. […]

Be the first to comment

Leave a Reply

Your email address will not be published.


*