Einsteigerfrage zu Volume

Döckerchen

New member
... ich habe im Portainer ein Volume angelegt ...
1748506670393.png
Anschließend habe ich im SSH-Terminal (Ich wußte nicht wie ich das (in diesem Fall TasmoAdmin) im Portainer mache) einen Container angelegt:

Code:
sudo docker run -d -p 5555:80 -v /var/lib/docker/volumes/tasmoadmin/_data:/data --name=TasmoAdmin --restart=always ghcr.io/tasmoadmin/tasmoadmin:latest

Jetzt wird mir angezeigt, dass das Volume "Unused" ist. Aber dort finde ich aktuelle Daten was wohl heißt das er doch benutzt wird.

Wo ist mein Fehler ?! Wie sollte ich es machen ? :rolleyes:

Danke vorab für Hinweise.
 
Hi,

wie kommst Du denn auf: -v /var/lib/docker/volumes/tasmoadmin/_data:/data? Sowas sieht man eigentlich eher, wenn man lokale Pfade mountet (z.B. /opt/docker/containerXY/daten:/data). Wenn Du ein reguläres Volume angelegt hast und nicht auf einen spezifischen Host-Ordner verweisen möchtest, sollte einfach nur das Volume angegeben werden und der Pfad im Container. Das hast Du auch schon bei der Portainer-Installation gemacht:

Volume angelegen:
docker volume create portainer_data

Container starten:
docker run -d -p 8000:8000 -p 9443:9443 --name portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:lts

Da ist der entsprechende Teil zur Einbindung eines Volumes eben -v portainer_data:/data

Somit sollte es bei Dir eigentlich so aussehen:
sudo docker run -d -p 5555:80 -v tasmoadmin:/data --name=TasmoAdmin --restart=always ghcr.io/tasmoadmin/tasmoadmin:latest

Jedenfalls meinem Verständnis nach und ich hab von der Thematik sicherlich auch nur wenig (bis keine) Ahnung 😅
 
Portainer hat recht: das Volume wird nicht verwendet.

Du bindest das Verzeichnis das Docker als Volume managed, ohne es wirklich als Volume zu verwenden. So ist es weder gewollt noch gedacht. Ein Volume wird ausschließlich über seinen Handle referenziert. So wie es @blurrrr im letzten Befehl von seinem Post auch zeigt.
 
Danke für deine Erläuterungen ... hier meine Vorgehensweise:
- Im Portainer das Volume angelegt, siehe erster Screenshot #1
- Diesen Pfad dann, wie im 2ten Screenshot, ausgetauscht, Vorgabe hier ... also prinzipiell alles so wie hier
1748518983972.png

Und das hat ja (fast) geklappt, das Volume wird benutzt aber es steht im Portainer "Unused" ...
 
Sorry ... der Wald mit den vielen Bäumen bzw. der Schlauch auf dem ich stehe ...
Somit sollte es bei Dir eigentlich so aussehen:
sudo docker run -d -p 5555:80 -v tasmoadmin:/data --name=TasmoAdmin --restart=always ghcr.io/tasmoadmin/tasmoadmin:latest
Heißt das, dass das Volume für TasmoAdmin mit diesem Befehl automatisch angelegt wird ?!
 
Da wird aber kein "Volume" angelegt, da wird ein "mount bind" genutzt, heisst Du bindest ein - auf dem Host existierendes Verzeichnis - im Container ein. Ein Volume hingegen kannst Du Dir (so ganz grob) wie eine virtuelle Festplatte vorstellen, welche auf dem Host liegt. Diese würdest Du dann an den Container übergeben, welcher diese virtuelle Festplatte dann in seinem Zielverzeichnis einbindet.

Es besteht also ein Unterschied zwischen...
<Volume-Name>:<Pfad im Container>
und
<Pfad auf dem Host>:<Pfad im Container>
 
Mir schwirrt der Kopf ... ich möchte eigentlich nur wissen, wie ich den TasmoAdmin-Container incl. Datenablage auf einem persistenten Volume sauber einbinde ...

In meinem Alter lerne ich sehr langsam aber dafür vergesse ich sehr schnell .... :oops:
 
Sorry ... der Wald mit den vielen Bäumen bzw. der Schlauch auf dem ich stehe ...

Heißt das, dass das Volume für TasmoAdmin mit diesem Befehl automatisch angelegt wird ?!
Wenn es nicht existiert, wird es angelegt.
Wenn es existiert, wird es wiederverwendet.

Prinzipiel hast Du im Docker data-root Verzeichnis nichts zu suchen, außer Du weisst sehr genau was Du tust.

Nach 12 Jahren mit Docker kann ich sagen, dass es nie notwendig war auf das Verzeichnis zuzugreifen.
 
Ich habe jetzt denContainer gelöscht und mit
Code:
sudo docker run -d -p 5555:80 -v tasmoadmin:/data --name=TasmoAdmin --restart=always ghcr.io/tasmoadmin/tasmoadmin:latest
Volume wurde angelegt, alles sieht so aus wie ich erwartet hatte, Danke dafür.
 
... falls jemand Langeweile hat würde ich mich über ein Tutorial "Volume Organisation in Docker (bzw. Portainer) für Dummies" freuen ... 🙄
Die Fundstellen / "Schnipsel" hier im Forum und anderswo bauen auf Basis-Wissen auf das mir (und vielleicht auch anderen) schlicht fehlt.
 
Moinsen,
ich bin hier garantiert nicht die Docker-Leuchte, da gibt es weitaus erfahrenere Menschen hier :).
Rein laienhaft würde ich es so zusammenfassen:
du kannst container so laufen lassen, dass keine Daten verblieben, wenn du den Container wieder verwirfst (nicht-persistent), die Daten werden dann rein innerhalb des Containers gespeichert und sind eben auch mit dem Container-Aus "weg".
Da das aber nicht immer unbedingt erwünscht ist, gibt es vor allem 2 Möglichkeiten, um Daten aus dem Container persistent (also erhaltend auch nach Löschen des Containers selbst) zu machen:
1. Angeben von bind mounts
2. nutzen von Volumes

1, Ist oben ja bereits erklärt, du mappst einen Ordner auf dem host System mit einem im Container laufenden Ordner (der anders nicht per se erreichbar ist, weil im Container). Das ist dann nützlich, wenn du sowohl vom Container als auch vom host aus auf diesen Ordner zugreifen musst. Beispiel: paperless, da gibt es Ordner, die im Betrieb nicht genutzt werden müssen (Datenbank, läuft alles Container-intern) aber auch Ordner, auf die du zugreifen willst (inbox, media, export für document_exporter). Diese letzteren würdest du dann mit bind mount erledigen.
2. Volumes sind das Mittel der Wahl, um Daten persistent aufzubewahren. Allerdings sind die Volumes innerhalb der docker Verwaltung und somit vom host nicht einfach einzusehen und erreichbar. Innerhalb der docker Verwaltung (also unterhalb des docker root-Verzeichnisses, idR /var/lib/docker), nicht aber innerhalb der Container. Genau das ist der Trick, denn auch wenn du einen Container "platt"machst, die Daten bleiben im Volume dazu erhalten.

Also: beides um Daten auch nach Entfernen eines Containers weiter vorzuhalten, um ein "Aufblasen" der Containergröße zu vermeiden (würde ja passieren, wenn Daten IM Container gespeichert werden)...
...wobei Volumes direkt und unter docker verwaltet werden, bind mounts aber mit ihren gemappten Ordnern selber verwaltet werden auf dem hostsystem.
...Volumes sind dabei nicht einfach so erreichbar vom hostsystem, bind mounts (je nach Rechtevergabe) aber schon (ist ja ein "normaler" Ordner auf dem host. Volumes also eher nicht für Daten die auch regelmäßig vom hostsystem (oder extern) erreichbar sein müssen.
...Volumes sind "somewhat" sicherer als bind mounts, weil durch die trennende docker Verwaltung eine gewisse Separation zwischen Container Daten und host bestehen bleibt, bei Nutzung von bind mounts wird diese Trennung quasi aufgehoben, was eben potentielle Risiken birgt (aber eben afaik auch nicht immer wirklich vermeidbar ist).

Das ist jedenfalls mein kleiner und bescheidener Wissensstand dazu, sicherlich grob verkürzt (und ggf deutlich zu ergänzen)....mal sehen, was die docker Pros dahingehend noch beitragen. ;)
 
Zuletzt bearbeitet von einem Moderator:
Ich ergänze mal ein wenig.

Wenn die Daten im Container liegen, dann sind die Daten mit der Löschung (nicht mit dem Stopp) des Containers weg. Spätestens wenn man den Container auf Basis einer neuen Image-Version neu erzeugt, sollte man vorher den alten gelöscht haben.. Sprich: es betrifft jeden irgendwann. Docker Compose bspw. ersetzt die Container (=Löschung und Neuanlage) bei Konfigurationsänderung am Service ohne das man viel davon mitbekommt.

Wie @the other schreibt: wenn Daten dauerhaft gespeichert werden sollen, müssen sie aus dem Container-Dateisystem ausgeleitet werden. Dafür mapped man wahlweise einen Host-Pfad (=Bind) oder ein von Docker gemanagtes Volume in einen Container-Pfad.

In beiden Fällen wird die Quelle über das Ziel gemountet, sodass die Originaldaten am Ziel nicht mehr zu sehen sind.

Sonderlocken:
  • Named Volumes:
    • Hier werden Daten am Ziel in das Named Volume zurückkopiert, bevor das Volume gemountet wird
      • Das passiert aber NUR wenn es leer ist -> Wenn in einer neuen Image Version am Ziel Änderungen wäre, würde man sie nicht mitbekommen. Das kann bei schlechtem Image Design ein Problem sein - idR ist es das nicht.
    • kann lokal und komplett von Docker gemanaged sein
    • kann lokal und ein Bind sein (dann gelten die Regeln beider Welten), muss dann entsprechend konfiguriert werden
    • kann ein cifs oder nfs remote share sein und muss dann entsprechend konfiguriert werden:
      • wird gemountet, sobald ein Container es verwendet, und unmounted wenn der letzte verwendende Container gestopped wurde
      • Hier gilt wie bei Binds: der Remote Share muss von der UID:GID bessen werden, die der Containerprozess verwendet oder entsprecht loose Berechtigungen besitzen
      • Bei cifs: die Credentials MÜSSEN bei der Volume deklaration im Klartext angegeben werde; Credential-Dateien werden nicht unterstützt
      • Bei nfs: erfahrungsgemäß funktioniert nfsv4 oder größer besser als nfsv3.
  • BInds
    • Man muss selbst darauf achten, dass der Besitzer des Host-Verzeichnisses mit der UID:GID des Container-Prozesses übereinstimmen, sonst kann der Prozess nicht auf das Host-Verzeichnis zugreifen
    • Einige Images verwenden fest vorgegebene UID:GID, andere erlauben es per Environment die UID und GID zu konfigurieren.
    • Docker mounted nicht wirklich den Host-Pfad, sondern löst dessen physikalischen Ort im Dateisystem auf und mounted diese Inode in den Container Pfad, sodass quasi zwei Zufahrten zum selben physikalischen Ort im Dateisystem geschaffen werden.
      • Warum ist das relevant? Angenommen der Host-Pfad, den man in den Container bindet, ist selbst ein Mountpoint, dann verändert sich beim unmounten/remounten der physikalische Ort und der Container bekommt nichts von der Änderung mit.
      • Hier sollte man ein Oberverzeichnis mappen, und bind propation konfigurieren, damit der Container Änderungen an sub-mounts mitbekommen darf.

Ich kann hier nur empfehlen die Funktionalität auszuprobieren und damit etwas rumzuspielen: anders wird es mit dem Aufbau nachhaltiger Erfahrung nicht funktionieren.
 

Zurzeit aktive Besucher

Neueste Beiträge

Letzte Anleitungen

Statistik des Forums

Themen
6.725
Beiträge
64.588
Mitglieder
7.007
Neuestes Mitglied
Eisy1966
Zurück
Oben