Container-Images und Dateisysteme

Veröffentlicht am:

Die wichtigsten Befehle zum Merken

  • docker image inspect — Imageidentität und Schichten prüfen.
  • docker diff — Dateisystemänderungen eines Containers untersuchen.
  • docker rm — den gestoppten Testcontainer entfernen.

Befehle und Optionen

Befehl oder Syntax Bedeutung
--format '{{.Id}} {{json .RootFS.Layers}}' Image-ID und Schichtkennungen im Docker-Templateformat ausgeben.
docker run --name btc-image-lab Benannten Testcontainer erzeugen und ausführen.
--pull=never Nur das lokale Image verwenden; bei Fehlen scheitern.
sh -c '…' Zitierte Shellanweisung im Container ausführen.
printf "hello\n" > /lab.txt Testdatei in seiner beschreibbaren Schicht erstellen.
docker diff btc-image-lab Hinzugefügte, geänderte und gelöschte Pfade zeigen.
docker rm btc-image-lab Gestoppten Container samt beschreibbarer Schicht entfernen.

Die Umleitung betrifft das Containerdateisystem. Weder Volume noch Hostverzeichnis wird eingebunden.

Die entscheidenden Konzepte

1. Ein Image liefert wiederverwendbaren Ausgangsinhalt und Konfiguration

Ein Containerimage liefert Dateisysteminhalt und Ausführungskonfiguration. Imageschichten beschreiben Änderungen, die gemeinsam das anfängliche Dateisystem bilden. Mehrere Container können dieselben Inhalte verwenden.

Ein Tag ist ein Name, der auf andere Inhalte wechseln kann. Image-ID oder Registry-Digest kennzeichnen Inhalt genauer. Nur ein Tag dokumentiert daher weniger präzise, was tatsächlich lief.

2. Jeder Container besitzt eigene beschreibbare Änderungen

Normalerweise liegt eine beschreibbare Schicht über dem Image. Neue oder geänderte Dateien betreffen die Containeransicht und ändern nicht das gemeinsame Ausgangsimage aller Container.

Je nach Speicherbackend verwendet die Engine Copy-on-Write oder Snapshotmechanismen. Entscheidend ist die Trennung gemeinsamer Inhalte und individueller Änderungen, nicht ein universeller Verzeichnispfad auf der Disk.

3. Stoppen und Entfernen wirken unterschiedlich

Stoppen beendet laufende Prozesse, erhält aber normalerweise die beschreibbare Schicht. Derselbe erneut gestartete Container kann frühere Dateien weiterhin sehen.

Entfernen löscht diese Schicht. Ein neuer Container aus demselben Image erhält die entfernten Änderungen nicht automatisch zurück. Deshalb kann Neuerstellung eines scheinbar identischen Containers intern gespeicherte Anwendungsdaten verlieren.

4. Dauerhafte Mounts besitzen einen eigenen Lebenszyklus

Volumes und Bind-Mounts halten Daten außerhalb der gewöhnlichen Containerschicht. Dadurch können Daten Containerersatz überleben; Lebensdauer und Eigentümerschaft müssen aber ausdrücklich verwaltet werden.

Ein Mount kann zudem Imageinhalt am Zielpfad verdecken, ohne ihn zu löschen. Persistenz ist weder Backup noch Anwendungskonsistenz. Initialisierung, gemeinsamer Zugriff, Schutz und Wiederherstellung bleiben eigene Entscheidungen.

Ein kleines Beispiel

Optional: Nutze das genannte lokale Image und die Testengine. Führe Zeilen einzeln aus. Stoppe bei fehlgeschlagener Prüfung oder Erzeugung; untersuche oder entferne keinen fremden vorhandenen Container gleichen Namens.

docker image inspect alpine:3.20 --format '{{.Id}} {{json .RootFS.Layers}}'
docker run --name btc-image-lab --pull=never alpine:3.20 sh -c 'printf "hello\n" > /lab.txt'
docker diff btc-image-lab
docker rm btc-image-lab

Die Shell schreibt /lab.txt und endet. Der gestoppte Container bleibt prüfbar. docker diff sollte einen hinzugefügten Eintrag dafür zeigen; weitere Laufzeitänderungen sind möglich. A, C und D bedeuten hinzugefügt, geändert und gelöscht, keine Dateirechte.

Die Imageidentität bleibt die Ausgangsidentität; die Datei gehört zum Container. Der letzte Befehl entfernt Container und Testdatei, behält aber das lokale Image. Volume-Persistenz und Image-Neubau werden nicht demonstriert.

Merke dir: Das Image ist der wiederverwendbare Ausgangspunkt. Beschreibbare Schicht und dauerhafte Mounts besitzen unterschiedliche Lebenszyklen.