Wo werden Docker-Images, Container und Volumes auf dem Linux-Hostsystem gespeichert?

Möchten Sie wissen, wo sich Docker-Images, -Container und -Volumes befinden?

In einer typischen Linux-Umgebung finden Sie das Docker-Image und die Containerdaten in:

/var/lib/docker/

Wenn Ihrem Server der Speicherplatz ausgeht, sollten Sie unbedingt in dieses Verzeichnis schauen.

In erster Linie befinden sich alle Docker-bezogenen Entitäten unter /var/lib/docker . Aber lassen Sie uns genauer darauf eingehen, mit dem Alpenbild und dem Container als praktisches Beispiel.

Hinweis:Bitte beachten Sie, dass diese Informationen nur zu Bildungszwecken dienen. Das Manipulieren von Docker-Verzeichnissen/Dateien mit dem Hostsystem wird eigentlich nie empfohlen. Die Befehle docker und docker-compose sollten immer die bevorzugte Methode sein. Auf physisch gespeicherte Docker-Verzeichnisse/Dateien sollte nur als letzter Ausweg in Notsituationen zugegriffen oder diese manipuliert werden.

Speicherort von Docker-Images

Wann immer Sie den docker pull verwenden Befehl oder führen Sie docker-compose up -d aus Um den Start von Anwendungen vorzubereiten, werden hier Bilder auf einem Ubuntu-Server gespeichert:

/var/lib/docker/overlay2

Hier ist Overlay2 der standardmäßige Docker-Speichertreiber auf Ubuntu. Sie können dies bestätigen, indem Sie docker info ausführen Befehl und suchen Sie nach dem Speichertreiber:

...
Storage Driver: overlay2
...

Wenn dies anders ist als bei Ihnen, verwenden Sie einen anderen Speichertreiber für Docker. Ebenso würde der Verzeichnisort nach demselben Speichertreiber benannt werden. Die Verfügbarkeit des Speichertreibers hängt von der Kernel-Unterstützung ab.

Spezifische Bildpositionen

Wenn Sie nach den Speicherorten bestimmter Bilder suchen, können Sie den Befehl inspect in Docker für das gezogene Bild verwenden.

Nehmen wir zum Beispiel an, ich habe das Alpine-Image mit docker pull alpine gezogen . Führen Sie den folgenden Befehl aus, um ihn zu untersuchen:

[email protected]:~$ docker inspect alpine

Sobald Sie den Befehl ausführen, werden Sie drei Felder innerhalb der Data bemerken Unterabschnitt unter GraphDriver :

...
        "GraphDriver": {
            "Data": {
                "MergedDir": "/var/lib/docker/overlay2/64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a9a525ab9e365e/merged",
                "UpperDir": "/var/lib/docker/overlay2/64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a9a525ab9e365e/diff",
                "WorkDir": "/var/lib/docker/overlay2/64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a9a525ab9e365e/work"
            },

...

Alle oben genannten Verzeichnispfade sind die physischen Speicherorte des Alpine-Images auf dem Hostsystem. Notieren Sie sich das Verzeichnis mit dem großen Hash-Namen in den drei Feldern oben:64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a9a525ab9e365e .

Insgesamt gibt es eigentlich vier Arten von Feldern:

LowerDir :Dies sind die schreibgeschützten Schichten eines Overlay-Dateisystems. Für Docker sind dies die Bildebenen, die der Reihe nach zusammengestellt werden.

UpperDir :Dies ist die Lese-Schreib-Schicht eines Overlay-Dateisystems. Für Docker ist dies das Äquivalent der containerspezifischen Schicht, die Änderungen enthält, die von diesem Container vorgenommen wurden.

Arbeitsverzeichnis :Dies ist ein erforderliches Verzeichnis für Overlay, es benötigt ein leeres Verzeichnis für den internen Gebrauch.

MergedDir :Dies ist das Ergebnis des Overlay-Dateisystems. Docker chroott effektiv in dieses Verzeichnis, wenn der Container ausgeführt wird.

Zitiert aus dieser Referenz (gut zum Weiterlesen).

Standort der Docker-Container

Wie Bilder werden auch Container im selben speichertreiberbasierten Verzeichnis gespeichert.

/var/lib/docker/overlay2

Spezifische Containerstandorte

Wenn Sie nach den Standorten bestimmter Container suchen, können Sie wieder den inspect verwenden Befehl für den laufenden Container.

Sagen wir zum Beispiel, ich habe den Alpine-Container mit docker run -ti -d alpine ausgeführt . Wenn Sie docker ps ausführen , sehen Sie, dass es ausgeführt wird:

[email protected]:~$ docker ps
CONTAINER ID   IMAGE     COMMAND     CREATED         STATUS         PORTS     NAMES
cb341d6a28fa   alpine    "/bin/sh"   6 seconds ago   Up 5 seconds             confident_banzai

Hier wurde der Container zufällig confident_banzai genannt . Untersuchen wir es also:

[email protected]:~$ docker inspect confident_banzai

Sobald Sie den obigen Befehl ausgeführt haben, werden Sie alle vier zuvor erwähnten Felder innerhalb der Data bemerken Unterabschnitt unter GraphDriver . In diesen Verzeichnissen befinden sich die Containerdaten physisch auf Ihrem Hostsystem:

...
        "GraphDriver": {
            "Data": {
                "LowerDir": "/var/lib/docker/overlay2/d734685e284c92bdcb6063ac292a48813f30f4b0b2dd6fa2882279c569e506a3-init/diff:/var/lib/docker/overlay2/64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a9a525ab9e365e/diff",
                "MergedDir": "/var/lib/docker/overlay2/d734685e284c92bdcb6063ac292a48813f30f4b0b2dd6fa2882279c569e506a3/merged",
                "UpperDir": "/var/lib/docker/overlay2/d734685e284c92bdcb6063ac292a48813f30f4b0b2dd6fa2882279c569e506a3/diff",
                "WorkDir": "/var/lib/docker/overlay2/d734685e284c92bdcb6063ac292a48813f30f4b0b2dd6fa2882279c569e506a3/work"
            },
            "Name": "overlay2"
        },
...

Referenz zum Weiterlesen.

Die oben genannten Verzeichnisse sind die physischen Speicherorte Ihrer Containerdaten innerhalb des Hostsystems. Denken Sie an das große Verzeichnis mit dem Hash-Namen:64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a9a525ab9e365e aus den Docker-Images Sektion? Das Verzeichnis darunter heißt diff , wie Sie im LowerDir sehen können Abschnitt nach : , der jetzt ein Einhängepunkt für den Container ist – abgerufen aus dem Basis-Image UpperDir !

Diese Verzeichnisse sind auch nach dem Beenden des Containers weiterhin verfügbar. Also der vollständige Pfad, der zwischen dem Bild (MergedDir , UpperDir und WorkDir ) und den Container (LowerDir Einhängepunkt) ist:

/var/lib/docker/overlay2/64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a9a525ab9e365e/

Der Zweck des Bildes ist zusammenhängend, nachdem es sich dem Container bis zum LowerDir zugewiesen hat Ebene, weshalb die vier Felder aufgrund der dynamischen Natur des letzteren zugewiesen werden und auf einem anderen Verzeichnis (mit einem neuen Hash) basieren, das zu:

wird

/var/lib/docker/overlay2/d734685e284c92bdcb6063ac292a48813f30f4b0b2dd6fa2882279c569e506a3/

Hinweis:Der Verzeichnis-Mount-Prozess vom Basis-Image zum Container ist dem Mounten von Volumes in Docker sehr ähnlich!

Speicherort der Docker-Volumes

Im Gegensatz zu Docker-Images und -Containern sind die physischen Speicherorte für Volumes ziemlich einfach. Volumes befinden sich unter:

/var/lib/docker/volumes/

Spezifische Volume-Standorte

In diesem Fall gibt es hauptsächlich zwei Typen. Das eine sind reguläre Docker-Volumes und das andere bind mounts.

Docker-Volumes

Wenn Sie nach den Speicherorten bestimmter Volumes suchen, können Sie das docker volume ls verwenden Befehl zuerst und überprüfen Sie den Namen oder die ID des Volumes.

Zum Beispiel habe ich den Alpine-Container mit dem folgenden Befehl mit einem Volume ausgeführt:

[email protected]:~$ docker run -ti -d --name alpine-container -v test-data:/var/lib/app/content alpine

Jetzt ein Volume namens test-data wird automatisch erstellt. Lassen Sie uns nun eine Datei mit dem Namen test.md erstellen an diesem Ort:

[email protected]:~$ docker exec alpine-container sh -c "touch /var/lib/app/content/test.md"

Überprüfen Sie, ob die Datei tatsächlich erstellt wurde:

[email protected]:~$ docker exec -ti alpine-container sh
/ # ls /var/lib/app/content/
test.md
/ # exit

Wenn Sie docker volume ls ausführen , das Volume mit dem Namen test-data aufgeführt werden:

[email protected]:~$ docker volume ls
DRIVER    VOLUME NAME
local     d502589845f7ae7775474bc01d8295d9492a6c26db2ee2c941c27f3cac4449d1
local     e71ee3960cfef0a133d323d146a1382f3e25856480a727c037b5c81b5022cb1b
local     test-data

Schließlich können Sie den tatsächlichen Speicherort der Datei auf Ihrem Hostsystem bestätigen:

[email protected]:~$ sudo ls -l /var/lib/docker/volumes/test-data/_data
total 0
-rw-r--r-- 1 root root 0 Oct  6 23:20 test.md

Daher befindet sich der Pfad für das gemountete Volume immer in einem Verzeichnis namens _data innerhalb des jeweiligen Volume-Verzeichnisses.

Sie können solche Pfade auch auf Docker-Weise überprüfen, indem Sie docker volume inspect verwenden Befehl, gefolgt vom Volume-Namen oder der ID, und nach dem Mountpoint suchen Parameter innerhalb der Ausgabe:

[email protected]:~$ docker volume inspect test-data
[
    {
        "CreatedAt": "2021-10-06T23:20:20+05:30",
        "Driver": "local",
        "Labels": null,
        "Mountpoint": "/var/lib/docker/volumes/test-data/_data",
        "Name": "test-data",
        "Options": null,
        "Scope": "local"
    }
]

Reittiere binden

Die Speicherorte von Bind-Mounts sind ziemlich offensichtlich und sogar noch einfacher, da Sie das Volume direkt von einem Host-seitigen Speicherort aus mounten:

[email protected]:~$ mkdir /home/avimanyu/test-data
[email protected]:~$ docker run -ti -d --name alpine-container -v /home/avimanyu/test-data:/var/lib/app/content alpine

In diesem Fall ein per Bind gemountetes Volume mit dem Namen test-data wird auf der Containerseite als /var/lib/app/content verfügbar sein .

Zusammenfassung

In diesem kurzen Tutorial habe ich einen generischen Linux-basierten Ansatz gewählt, um die physischen Speicherorte von Docker-Images, Containern und Volumes anzuzeigen, die sich auf Ihrem Linux-Server (in diesem Fall Ubuntu 20.04) auf Hostebene befinden.

Wenn Sie Feedback, Kommentare oder Vorschläge zu diesem Ansatz teilen möchten, hinterlassen Sie bitte Ihre Gedanken im Kommentarbereich unten.