Ich bin mir nicht sicher, ob ich das verstehe, docker-compose run --user ist eine Option, und docker-compose.yml unterstützt den Schlüssel user (http://docs.docker.com/compose/yml/ #working95dir-entrypoint-user-hostname-domainname-mem95limit-privileged-restart-stdin95open-tty-cpu95shares).

Ich schätze, wir müssten die Auflösung von Umgebungsvariablen im Feld user unterstützen, damit Sie es auf $UID setzen können, ist das richtig? #1377

Hallo. Ja, die Erweiterung $UID würde in diesem Fall ausreichen. Dennoch wäre die Option --user für den Befehl docker-compose up (nicht nur für docker-compose run ) nützlich, um das gesamte Projekt als bestimmter Benutzer zu starten.

Der Punkt ist, den Benutzer angeben zu können, ohne yml zu berühren.

Starten Sie das gesamte Projekt als bestimmter Benutzer

Es kam mir nie in den Sinn, dass die Leute das wollen könnten. Können Sie den Anwendungsfall näher erläutern?

Egal, ich habe nach oben gescrollt. Gehe ich recht in der Annahme, dass Sie Linux verwenden? Bei der Verwendung von boot2docker werden Dateien mit vernünftigen Berechtigungen erstellt.

Ich frage mich, ob es eine Möglichkeit gibt, den Docker-Daemon so zu konfigurieren, dass er dies für jedes Volume tut, das er bereitstellt.

Ja, unter Linux.

Ich verwende compose, um Tests auf CI auszuführen, indem ich das Host-Volume mounte (ja, ich weiß). Ohne diese Option werden einige Dateien mit „falschen“ Eigentumsrechten erstellt, dh root:root

Ich weiß, dass ich einen reinen Datencontainer verwenden und Dateien daraus untersuchen/kopieren könnte, aber ein Host-Volume ist viel bequemer und erfordert weniger Skripting.

up --user könnte gefährlich sein, wenn einige Container/Dienste bereits einen Benutzer angeben.

@mrzechonek Ich denke nicht, dass das Ändern eines Containers aufgrund seiner Umgebung eine gute Praxis ist.

@josephpage ja, das könnte sein. Die $UID-Erweiterung würde jedoch ausreichen.

So ziemlich das einzige, was ich brauche, sind die richtigen Berechtigungen für Host-Volumes. Ich kenne keine andere Möglichkeit, dies zu erreichen, als den Containerprozess als $UID auszuführen ...

Ich würde es eigentlich vorziehen, wenn diese Funktion im Damon selbst vorhanden wäre, wie @aanand sagte. Oder vielleicht eine Option, um ein Volume in einem solchen Modus zu mounten (vielleicht ein Speichertreiber?).

@mrzechonek , hast du eine Problemumgehung gefunden?

Nicht wirklich, nein. Im Moment machen wir docker-compose run --user und benennen den Container dann um/benennen ihn um, damit compose denkt, er sei mit dem Befehl up gestartet worden, sodass stop und ps würde funktionieren.

1377 ist in Master und wird in der Version 1.5.0 enthalten sein, sodass Sie user: $UID in docker-compose.yml können. Wenn Sie mit Master vertraut sind, können Sie es jetzt ausprobieren, ansonsten sollte in den nächsten Wochen ein RC-Release folgen.

Ich werde dieses Thema schließen, da das Feature selbst als Teil von #1377 implementiert ist

und dann den Container umbenennen/neu benennen, damit compose denkt, dass er mit dem up-Befehl gestartet wurde

Dies ist eigentlich nicht das erste Mal, dass ich von der Notwendigkeit höre (obwohl ich in diesem Fall denke, dass es nur vorübergehend ist). Ich habe einen Lösungsvorschlag dafür in #2042

Danke, #1377 behebt das gut.

@mrzechonek Könnten Sie erläutern, wie dies Ihr Problem gelöst hat? Ich habe genau den gleichen Anwendungsfall: "Ich möchte, dass die dockerisierte App Dateien generiert, die mir gehören, nicht dem Root."

Ich habe versucht, user: $UID zum Container web hinzuzufügen, und wenn ich docker-compose run web touch foo verwende, erhalte ich Folgendes:

WARNING: The UID variable is not set. Defaulting to a blank string.

Die Datei foo wird erstellt, gehört aber immer noch root .

Ich habe user: $USER verwendet, aber $UID funktioniert auch. Ich weiß nicht, warum sich Ihr Setup über fehlende Variablen beschwert :(

Habe genau das gleiche Problem wie @michaelmior.

Wenn ich stattdessen $USER verwende, bekomme ich System error: Unable to find user Max . Was Sinn macht, weil es ein Host-Benutzer ist.

Was könnte dazu führen, dass $UID während der Docker-Compose-Ausführung nicht verfügbar ist?

Hallo, gleiches Problem hier.
Ich bin auf Fedora 23 und die UID-Variable wird nicht weitergegeben, wenn ich den Befehl env auf dem Host aufrufe.

Problemumgehung:
Führen Sie zuerst ein export UID auf dem Host aus und rufen Sie dann Ihr docker-compose an

Wäre schön, wenn docker-compose einfach $UID zur Verfügung stellen würde, ohne dass es exportiert werden müsste. Endet als Boilerplate.

Wenn UID nicht exportiert wird, gibt es für compose keine Möglichkeit, es zu bekommen, also denke ich, dass das, was Sie fragen, unmöglich ist.

Verfassen Sie also einfach, da eine laufende Anwendung nicht auf den Benutzer schließen kann, als der sie ausgeführt wird?

Sicher, es könnte die Umgebungsvariable $USER lesen, aber Sie können das auch aus der Compose-Datei heraus tun! Wenn die Variable nicht exportiert wird, steht sie untergeordneten Prozessen nicht zur Verfügung. Die wirklich einfache Lösung scheint zu sein, es einfach zu exportieren.

Ich denke eher, dass, wenn die UID nicht deklariert ist, die ausführbare Datei die UID des Ausführenden prüfen und als solche verfügbar machen könnte.

Denken Sie wieder an Boilerplate und leicht zu übersehende Schritte. Die meisten Leute wollen ein Setup, bei dem der einzige Schritt docker-compose up ist. Warum eine winzige variable Anforderung hinzufügen, die 99 % der Menschen alle auf genau die gleiche Weise festlegen werden.

Gibt es eine nette Ressource, die andere ähnliche Fallstricke zwischen Mac- und Linux-Hosts aufzeigt?

Außerdem ist es nicht wirklich das, was wir unter Linux wollen, den Benutzer zu zwingen, wir wollen das Verhalten, das Mac hat, wo selbst wenn Sie als Root im Container laufen, neue Dateien auf Host-Volumes nützliche Berechtigungen haben :(

Ich war eigentlich nur verwirrt darüber, warum mein Mac-Verhalten besser war als mein Linux-Verhalten, und es hat nicht unbedingt etwas mit diesem Problem zu tun. Ich habe eine Ausgabe auf Dinghy gestartet , um nach Lösungen für ein nettes Erlebnis unter Linux zu suchen.

@mrzechonek können Sie mitteilen, wie Sie die user: -Direktive verwenden, um sicherzustellen, dass die Dateiberechtigungen auf Host und Container korrekt sind?

Ich füge einfach user: $UID in die Datei .yml ein. Das ist unter Linux, Gentoo und Ubuntu 12.04.

@mrzechonek danke. Macht Ihr Container dann etwas Laufzeitmagie? Soweit ich weiß, spiegelt user: die Dockerfile-Anweisung wider. Aber das bedeutet einfach, dass die Befehle innerhalb des Containers als user: $UID ausgeführt werden. Ich kann nicht verstehen, wie das mit Volume-Berechtigungen hilft =/.

@mrzechonek : Das ist anders. Wir wollen eine Funktion, um den Benutzer zu steuern, als der der Container außerhalb des Hostsystems fungiert, unabhängig davon, als wen er innerhalb des Containers selbst eingerichtet ist.

Denken Sie: _" root im Container schreibt als myuser Benutzer auf Host"_.

In unserem Anwendungsfall ist es so ziemlich immer derselbe Benutzer, der den Container erstellt und ausführt, also gibt es kein Problem.

Wenn Sie jedoch Containerbenutzer "dynamisch" Hostbenutzern zuordnen möchten, besteht die einzige Möglichkeit darin, LXC-Benutzernamensräume im Docker-Daemon selbst zu unterstützen, eine Funktion, die nicht implementiert ist (noch? soweit ich wissen?).

Ich glaube nicht, dass docker-compose das tun könnte.

Scheint, als hätte ich ein paar Releases verpasst: https://integratedcode.us/2015/10/13/user-namespaces-have-arrived-in-docker/

Sorry, ich nutze Docker nicht mehr, zumindest nicht aktiv im aktuellen Projekt.

Danke @mrzechonek. Letztendlich versuche ich, das zu tun, was @gkop versucht – die vom Container generierten Dateien auf den auf dem Host gemounteten Volumes zu haben, die dem Container-Starter gehören. So funktioniert es unter OS X mit der neuesten Docker 1.12 Beta (wie?) und so würde ich es auch gerne unter Linux sehen.

@mrzechonek - Einige Anwendungen erfordern, dass sie als ein bestimmter Benutzer ausgeführt werden, oder dass der Benutzer, den sie ausführen, einem echten Benutzer im System zugeordnet werden muss. In diesen Fällen ist es einfacher, es einfach als root zu belassen und die Zuordnung über den Kopf des Containers hinweg durchzuführen.

(Dies ist anstelle vieler hässlicher Hacks, um das Benutzerschema des aktuell laufenden Systems auf den Container abzubilden, nur um alles in eine Reihe zu bringen.)

@dmitrym0 Ich denke, dass Sie unter OSX boot2docker in einer nativen OSX-Virtualisierung (https://github.com/mist64/xhyve/) ausführen und dann Container in dieser VM erstellt werden. Dies bedeutet, dass die VM wirklich die gesamte Benutzerzuordnung durchführt, nicht der Docker-Daemon. root des Containers ist immer noch root des Hosts.

$UID ist auf Ubuntu 16.04-Hosts nicht standardmäßig festgelegt. Es wäre trivial für Docker-Compose, die Benutzer-ID zu erhalten, die es ausführt, und es trotzdem einzufügen. Viel weniger Boilerplate-Code und Umgebung, die für Benutzer von App-Entwicklern eingerichtet wurden, was sinnvoll ist, da es bei Compose ausschließlich um Docker UX geht.

+1 für docker-compose up --user oder ausführender Benutzer ....

Gibt es zu diesem Problem Lösungen oder Neuigkeiten?

Nein, und ich habe dieses Feature vor einiger Zeit für die Docker-Engine geöffnet: https://github.com/docker/docker/issues/22415

Ich denke, dies ist ein Problem mit viel größeren Auswirkungen, als es derzeit anerkannt wird. In der Lage zu sein, zu ändern, für welchen Benutzer der Container das Dateisystem berührt, ohne den Container selbst auf die Berechtigungssysteme aufmerksam machen zu müssen, würde einige Türen öffnen.

Wenn Sie daran interessiert sind, schlage ich vor, das von mir verlinkte Ticket zu teilen und zu bewerten.

das funktioniert bei mir: user: "1000:1000"

@jovanialferez Zu Ihrer Information , wenn Sie es so hartcodieren, werden Sie in Schwierigkeiten geraten, wenn andere Personen an dem Projekt beteiligt sind, deren UID und GID nicht auf 1000 eingestellt sind. Ich denke, OSX beginnt mit der Nummerierung normaler Benutzer bei 500 und jedem Linux Eine Installation mit mehreren Benutzern würde zu einer UID größer als 1000 führen.

@jovanialferez das funktioniert nur unter Linux.

notiert. danke @nfm @luispabon

Ich bin kürzlich von Mac auf Linux umgestiegen und wurde gerade davon getroffen, verstehe nicht wirklich, wie das noch nicht gelöst ist

Erwähnen Sie dieses Problem erneut, damit Neulinge es sehen: https://github.com/moby/moby/issues/22415

Wir brauchen wirklich die Möglichkeit, Docker-Prozesse extern einem bestimmten Benutzer zuzuordnen. Betonung auf extern . Wählen Sie nicht die UID/GID des Prozesses im Container. Ordnen Sie den Containerprozess jedoch von außen einer lokalen UID/GID zu.

Ja, in der Tat. Das Zuweisen der uid/gid des aktuellen Benutzers in den Container funktioniert nur unter Linux. Scheint aber ein Docker-Problem zu sein.

Wir stoßen auf ein etwas esoterischeres Problem unter Windows. Wir verwenden eine lokale OrientDB-Instanz, die die Dateien in das Dateisystem des Hosts schreibt, und unter Windows scheint dies nicht der Fall zu sein. Oh ... vielleicht liegt es daran, dass das Host-Volume kein Block-Volume ist?

Als ich vor fast einem Jahr versuchte, dies zu lösen, stieß ich auf dieses Thema. Da zu diesem Zeitpunkt keine Lösung bereitgestellt wurde, habe ich eine Reihe von Wrapping-Bash-Skripten erstellt, um Ihr Docker-Compose auszuführen.

Jetzt nach einem Jahr ist alles gleich. Ich frage mich, wie lange es dauert, ein so einfaches Problem für eine Software wie Docker-Compose zu lösen, die nicht einmal ein echter Anbieter, sondern ein Wrapper ist.

$UID wird unter Linux standardmäßig nicht exportiert, ok? Dies hindert uns daran, ein universelles Docker-Compose zu erstellen - was an sich schon eine seltsame Sache ist, da angenommen wird, dass diese Software eine Front-End-Lösung ist, oder?

Wenn Sie keine Zeit mit Kleinigkeiten verschwenden möchten - und das verstehe ich - warum lassen Sie uns dann nicht einfach einen zufälligen Host-Befehl ausführen, bevor Sie einen Dienst ausführen, hm? Wir könnten einfach so etwas tun:

services:
  web:
     ...
     host_command: export UID

Ist das nicht offensichtlich?

+1

Dieses Problem hat nicht genug Likes und +1 und für mich wird es übersehen, aber von vielen Benutzern, einschließlich mir, benötigt und angefordert.

Ich bin hier, um auch meine +1 zu geben, weil ich davon betroffen bin. Ich möchte derzeit nicht, dass meine Container als Root ausgeführt werden. Ich möchte, dass sie ein Volume im Host gemeinsam nutzen, auf das mein Benutzer schreiben kann. Dies ist nicht möglich, wenn ich den Benutzer nicht setze, und die Erweiterung wäre der natürlichste Weg , dies anstelle von user: 1000:1000 zu tun, da dies, wie bereits erwähnt, zu Konflikten mit Benutzern mit einer anderen Umgebung führen wird. $UID erweist sich, auch wenn es nicht exportiert wird, als bessere Lösung, da es umgebungsbasiert ist als Docker-Expose-basiert.

Nur meine 2 Cent. Also, hat irgendjemand trotzdem einen Weg gefunden, dies zu tun?

@darkguy2008 - Stellen Sie sicher, dass Sie dies hochtreiben: https://github.com/moby/moby/issues/22415

Ich vermute, dass ein Feature im Docker selbst benötigt wird, bevor Compose darauf aufbauen kann.

Ich bin mir nicht sicher, ob ich das verstehe, docker-compose run --user ist eine Option, und docker-compose.yml unterstützt den Schlüssel user (http://docs.docker.com/compose/yml/ #working95dir-entrypoint-user-hostname-domainname-mem95limit-privileged-restart-stdin95open-tty-cpu95shares).

Ich schätze, wir müssten die Auflösung von Umgebungsvariablen im Feld user unterstützen, damit Sie es auf $UID setzen können, ist das richtig? #1377

Die Verbindung ist unterbrochen.

Es wurde festgestellt, dass das Hinzufügen einer obligatorischen Variablen als Problemumgehung hilfreich war:

version: "3"
services:
  testapp:
    image: ubuntu:20.04
    entrypoint: /bin/bash -c "cd $PWD && touch tmp"
    user: ${CURRENT_UID:?"Please run as follows 'CURRENT_UID=$(id -u):$(id -g) docker-compose up'"}
    volumes:
      - $PWD:$PWD

Würde zeigen:

ERROR: Missing mandatory value for "user" option in service "testapp": "Please run as follows 'CURRENT_UID=$(id -u):$(id -g) docker-compose up'"

Festlegen, dass die Datei wie folgt ausgeführt werden muss:

CURRENT_UID=$(id -u):$(id -g) docker-compose up

Es wurde festgestellt, dass das Hinzufügen einer obligatorischen Variablen als Problemumgehung hilfreich war:

version: "3"
services:
  testapp:
    image: ubuntu:20.04
    entrypoint: /bin/bash -c "cd $PWD && touch tmp"
    user: ${CURRENT_UID:?"Please run as follows 'CURRENT_UID=$(id -u):$(id -g) docker-compose up'"}
    volumes:
      - $PWD:$PWD

Würde zeigen:

ERROR: Missing mandatory value for "user" option in service "testapp": "Please run as follows 'CURRENT_UID=$(id -u):$(id -g) docker-compose up'"

Festlegen, dass die Datei wie folgt ausgeführt werden muss:

CURRENT_UID=$(id -u):$(id -g) docker-compose up

Das Problem ist, dass meine Dienste zum Starten root Zugriff benötigen. Z.B:

app-php-fpm  | [14-Jun-2020 00:15:12] NOTICE: [pool www] 'user' directive is ignored when FPM is not running as root
app-php-fpm  | [14-Jun-2020 00:15:12] NOTICE: [pool www] 'group' directive is ignored when FPM is not running as root
app-redis    | 1:M 14 Jun 2020 00:15:12.710 * Ready to accept connections
app-php-fpm  | [14-Jun-2020 00:15:12] ERROR: Unable to create the PID file (/run/php-fpm.pid).: Permission denied (13)
app-php-fpm  | [14-Jun-2020 00:15:12] ERROR: FPM initialization failed
app-webserver exited with code 1
app-mysql exited with code 1
app-php-fpm exited with code 78