Shared Volume/Datei Berechtigungen/Besitz (Docker)

Question

Ich habe ein etwas nerviges Problem bei der Verwendung eines Docker-Container (ich bin auf Ubuntu, also keine Virtualisierung wie VMWare oder b2d). Ich habe mein Image erstellt und verfüge über einen aktiven Container, der über ein freigegebenes (angehängtes) Verzeichnis von meinem Host und eine gemeinsame (angehängte) Datei von meinem Host verfügt. Hier ist der docker run Befehl in voller Länge:

docker run -dit \ 
-p 80:80 \ 
--name my-container \ 
-v $(pwd)/components:/var/www/components \ 
-v $(pwd)/index.php:/var/www/index.php \ 
my-image 

Dies funktioniert gut, und beide /components (und dessen Inhalt) und die Datei werden in geeigneter Weise geteilt. Wenn ich jedoch Änderungen an dem Verzeichnis vornehmen möchte (z. B. eine neue Datei oder einen neuen Ordner hinzufügen) oder die gemountete Datei (oder eine Datei im Verzeichnis) bearbeiten möchte, kann dies aufgrund falscher Berechtigungen nicht durchgeführt werden. Running ls- lFh zeigt, dass die owner und group für die montierten Elemente in libuuid:libuuid geändert wurden. Das Ändern des Datei- oder Parent-Verzeichnisses erfordert root-Berechtigungen, die meinen Arbeitsablauf erschweren (da ich von Sublime Text und nicht von Terminal arbeite, wird ein Popup für admin privs angezeigt).

Warum tritt dies auf? Wie kann ich umgehen/dies richtig umgehen? Von Managing Data Volumes: Mount a Host File as a Data Volume:

Hinweis: Viele Werkzeuge verwendet, um Dateien mit vi bearbeiten und sed --in-Platz in einer Inode Veränderung führen kann. Seit Docker v1.1.0 erzeugt dies einen Fehler wie "sed: kann ./sedKdJ9Dy nicht umbenennen: Gerät oder Ressource beschäftigt". Wenn Sie die gemountete Datei bearbeiten möchten, ist es oft am einfachsten, das übergeordnete Verzeichnis anzuhängen.

Dies scheint darauf hinzudeuten, anstatt /components und /index.php der Montage, ich sollte stattdessen das übergeordnete Verzeichnis der beiden montieren. Klingt in der Theorie großartig, aber basierend auf dem Verhalten der -v Option und wie es mit /directory interagiert, würde es scheinen, dass jede Datei in meinem übergeordneten Verzeichnis geändert würde, um im Besitz von libuuid:libuuid sein. Außerdem habe ich viele Dinge innerhalb des Elternverzeichnisses, die im Container nicht benötigt werden - Dinge wie Build-Tools, verschiedene Dateien, einige komprimierte Ordner usw. Das Verschachteln des gesamten übergeordneten Verzeichnisses wäre verschwenderisch.

Lauf chown user:group auf /components und /index.phpauf meinem Host-Maschine erlauben Sie mir, dies zu umgehen und scheinen weiterhin mit dem Behälter zu synchronisieren. Ist das etwas, das ich jedes Mal tun muss, wenn ich einen Container mit bereitgestellten Host-Volumes ausführen? Ich vermute, dass es einen effizienteren Weg gibt, um dies zu tun, und ich finde nirgendwo eine Erklärung für meinen speziellen Anwendungsfall.

Ich benutze diesen Container für die Entwicklung eines Moduls für ein anderes Programm und habe keine Lust, einen reinen Datencontainer zu verwalten - die einzigen wichtigen Dateien stammen von meinem Host; Persistenz wird nicht anderswo benötigt (wie eine Datenbank usw.).

• Dockerfile
• /setup
• auf Pastebin Erstellt Post eine noch längere zu vermeiden. Läuft nie ab.

Nach dem Erstellen des Images, das ist der Fahrbefehl Ich verwende:

docker run -dit \ 
    -p 80:80 \ 
    --name my-container \ 
    -v $(pwd)/components:/var/www/wp-content/plugins/my-plugin-directory/components \ 
    -v $(pwd)/index.php:/var/www/wp-content/plugins/my-plugin-directory/index.php \ 
    my-image 

Answer 1

Es ist wie Ihre chown -R nginx:nginx ... Befehle in Ihrem Container aussieht sind das Eigentum Bits auf Ihren Dateien zu ändern, indem besessen werden libuuid auf Ihrem Host-Computer.

Eine grundlegende Erläuterung zur Funktionsweise von Dateibesitz-Bits zwischen dem Host und den Andock-Containern finden Sie unter Understanding user file ownership in docker: how to avoid changing permissions of linked volumes.