No estoy seguro de entender, docker-compose run --user es una opción, y docker-compose.yml admite la clave user (http://docs.docker.com/compose/yml/ #working95dir-entrypoint-user-hostname-domainname-mem95limit-privileged-restart-stdin95open-tty-cpu95shares).

Supongo que necesitaríamos admitir la resolución de variables de entorno en el campo user para que pueda configurarlo en $UID ¿no es así? #1377

Hola. Sí, la expansión $UID sería suficiente en este caso. Aún así, la opción docker-compose up --user el comando docker-compose up (no solo para docker-compose run ) sería útil para iniciar todo el proyecto como usuario particular.

El punto es permitir especificar el usuario sin tocar yml.

iniciar todo el proyecto como usuario particular

Nunca se me ocurrió que la gente podría querer hacer esto. ¿Podría dar más detalles sobre el caso de uso?

No importa, me desplacé hacia arriba. ¿Tengo razón al pensar que estás en Linux? Cuando usa boot2docker, crea archivos con permisos sensibles.

Me pregunto si hay una manera de configurar el demonio Docker para hacer esto para cada volumen que monte.

Sí, en Linux.

Estoy usando componer para ejecutar pruebas en CI montando el volumen del host (sí, lo sé). Sin esta opción, algunos archivos se crean con propiedad "incorrecta", es decir, root:root

Sé que podría usar un contenedor de solo datos e inspeccionar/copiar archivos de él, pero un volumen de host es mucho más conveniente y requiere menos secuencias de comandos.

up --user podría ser peligroso si algunos contenedores/servicios ya especifican un usuario.

@mrzechonek No creo que modificar un contenedor debido a su entorno sea una buena práctica.

@josephpage sí, podría ser. Sin embargo, la expansión de $UID funcionaría.

Casi lo único que necesito son los permisos adecuados en los volúmenes de host. No conozco otra forma de lograrlo, además de ejecutar el proceso del contenedor como $UID...

De hecho, preferiría que esta función estuviera presente en el propio Damon, como dijo @aanand . O tal vez una opción para montar un volumen en ese modo (¿un controlador de almacenamiento tal vez?).

@mrzechonek , ¿ha encontrado una solución?

No, realmente no. En este momento estamos haciendo docker-compose run --user y luego renombramos/volvimos a etiquetar el contenedor para hacer que compose crea que se inició con el comando up , de modo que stop y ps funcionaría.

1377 está en master y estará en la versión 1.5.0, por lo que podrá hacer user: $UID en docker-compose.yml . Si se siente cómodo usando el maestro, puede probarlo ahora; de lo contrario, debería haber una versión RC en las próximas semanas.

Voy a cerrar este problema ya que la función en sí se implementa como parte de #1377

y luego cambie el nombre / vuelva a etiquetar el contenedor para que compuse piense que fue iniciado por el comando up

En realidad, esta no es la primera vez que escucho sobre la necesidad de esto (aunque en este caso supongo que es solo temporal). Tengo una solución propuesta para ello en # 2042

Gracias, # 1377 soluciona esto muy bien.

@mrzechonek ¿Podría aclarar cómo esto resolvió su problema? Tengo exactamente el mismo caso de uso: "Me gustaría que la aplicación dockerizada generara archivos de mi propiedad, no de la raíz"

Intenté agregar user: $UID al contenedor web y cuando uso docker-compose run web touch foo obtengo lo siguiente:

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

Se crea el archivo foo , pero sigue siendo propiedad de root .

He usado user: $USER , pero $UID también funciona. No sé por qué su configuración se queja de que faltan variables :(

Teniendo exactamente el mismo problema que @michaelmior.

Cuando uso $USER en su lugar, obtengo System error: Unable to find user Max . Lo cual tiene sentido porque es un usuario host.

¿Qué podría causar que $UID no esté disponible durante la ejecución de docker-compose?

Hola, el mismo problema aquí.
Estoy en Fedora 23 y la variable UID no se propaga cuando llamo al comando env en el host.

solución alterna:
primero haga un export UID en el host, luego llame a su docker-compose

Sería bueno si docker-compose simplemente hiciera que $UID estuviera disponible sin tener que exportarlo. Termina siendo repetitivo.

Si UID no se exporta, no hay forma de que compuse lo obtenga, por lo que creo que lo que está preguntando es imposible.

Entonces, componer simplemente como una aplicación en ejecución no tiene forma de inferir el usuario con el que se está ejecutando.

Claro, podría leer la variable de entorno $USER , ¡pero también puede hacerlo desde el archivo Compose! Si la variable no se exporta, no estará disponible para los procesos secundarios. La solución realmente fácil parece ser simplemente exportarlo.

Estoy pensando más en que si el UID no está declarado, entonces el ejecutable podría ver el uid de quién lo ejecutó y hacerlo disponible como tal.

Nuevamente, pensando en repeticiones y pasos fáciles de pasar por alto. La mayoría de la gente quiere una configuración en la que el único paso sea docker-compose up . ¿Por qué agregar un pequeño requisito variable que el 99% de las personas van a configurar exactamente de la misma manera?

¿Hay algún buen recurso que explique otras trampas similares entre los hosts de Mac y Linux?

Además, forzar al usuario no es realmente lo que queremos en Linux, queremos el comportamiento que tiene Mac, donde incluso cuando se ejecuta como root en el contenedor, los archivos nuevos en los volúmenes del host tienen permisos útiles :(

En realidad, estaba confundido acerca de por qué mi comportamiento en Mac era mejor que mi comportamiento en Linux, y no tiene nada que ver estrictamente con este problema. Empecé un problema en Dinghy para buscar soluciones para una buena experiencia en Linux.

@mrzechonek , ¿puede compartir cómo usa la directiva user: para garantizar que los permisos de archivo sean correctos en el host y el contenedor?

Simplemente agrego user: $UID en el archivo .yml . Eso es en Linux, Gentoo y Ubuntu 12.04.

@mrzechonek gracias. ¿Su contenedor entonces hace algo de magia en el tiempo de ejecución? Según tengo entendido, user: refleja la instrucción Dockerfile. Pero eso simplemente significa que los comandos dentro del contenedor se ejecutan como user: $UID . No puedo entender cómo eso ayuda con los permisos de volumen =/.

@mrzechonek : Esto es diferente. Queremos una función para controlar el usuario como actúa el contenedor, fuera del sistema host, independientemente de quién esté configurado dentro del propio contenedor.

Piense: _" root en el contenedor se escribe como myuser usuario en el host"_.

En nuestro caso de uso, casi siempre es el mismo usuario el que crea el contenedor y lo ejecuta, por lo que no hay problema.

Sin embargo, si desea asignar usuarios de contenedores a usuarios de host "dinámicamente", creo que la única forma de hacerlo es admitir espacios de nombres de usuario LXC en el propio demonio docker, característica que no está implementada (¿todavía? hasta donde yo ¿saber?).

No creo que sea algo que docker-compose pueda hacer.

Parece que me perdí algunos lanzamientos: https://integratedcode.us/2015/10/13/user-namespaces-have-arrived-in-docker/

Lo siento, ya no uso Docker, al menos no activamente en el proyecto actual.

Gracias @mrzechonek. En última instancia, estoy tratando de hacer lo que @gkop está tratando de hacer: tener los archivos generados por el contenedor en los volúmenes montados en el host que pertenecen al iniciador del contenedor. Así es como funciona en OS X con la última versión beta de Docker 1.12 (¿cómo?) y así es como me gustaría verlo también en Linux.

@mrzechonek : algunas aplicaciones requieren que se ejecuten como un usuario en particular, o requieren que el usuario que están ejecutando se asigne a uno real en el sistema. En esos casos, es más fácil simplemente dejarlo como root y hacer el mapeo sobre el encabezado del contenedor.

(esto es en lugar de muchos trucos feos para mapear el esquema de usuario del sistema en ejecución actual en el contenedor solo para que todo se alinee)

@dmitrym0 Creo que en OSX, ejecuta boot2docker dentro de una virtualización OSX nativa (https://github.com/mist64/xhyve/) y luego se crean contenedores dentro de esa VM. Esto significa que en realidad es la máquina virtual la que realiza todo el mapeo de usuarios, no el demonio docker. El root del contenedor sigue siendo el root del host.

$UID no está configurado de forma predeterminada en los hosts de Ubuntu 16.04. Sería trivial para docker-compose adquirir la identificación del usuario ejecutándolo e inyectándolo de todos modos. Mucho menos código repetitivo y entorno configurado para los usuarios de redacción de desarrollo de aplicaciones, lo que tiene sentido ya que componer tiene que ver con la experiencia de usuario de Docker.

+1 para docker-compose up --user o usuario ejecutor ....

¿Hay alguna solución o noticias sobre este problema?

No, y abrí esta función contra el motor acoplable hace bastante tiempo: https://github.com/docker/docker/issues/22415

Creo que este es un problema de mucho mayor impacto de lo que se reconoce actualmente. Ser capaz de alterar qué usuario toca el contenedor en el sistema de archivos sin tener que hacer que el contenedor sea consciente de los sistemas de permisos abriría bastantes puertas.

Si esto es algo que le interesa, sugiero compartir y votar el boleto que vinculé.

esto me funciona: user: "1000:1000"

@jovanialferez Para su información, si lo codifica de esa manera, tendrá problemas si otras personas están involucradas en el proyecto que no tienen su UID y GID configurados en 1000. Creo que OSX comienza a contar usuarios regulares en 500, y cualquier Linux la instalación con varios usuarios terminaría con un UID superior a 1000.

@jovanialferez que solo funcionará en Linux.

señalado. gracias @nfm @luispabon

Recientemente me mudé de Mac a Linux y me golpeó esto, realmente no entiendo cómo esto aún no se resuelve

Mencionando este problema nuevamente para que los recién llegados lo vean: https://github.com/moby/moby/issues/22415

Realmente necesitamos la capacidad de mapear externamente los procesos de la ventana acoplable a un usuario específico. Énfasis en lo externo . No elegir el UID/GID del proceso en el contenedor. Pero asigne el proceso del contenedor a un UID/GID local desde el exterior.

Sí, de hecho. Asignar el uid/gid del usuario actual al contenedor solo funciona en Linux. Sin embargo, parece un problema de Docker.

Nos encontramos con un problema un poco más esotérico en Windows. Usamos una instancia local de OrientDB, que escribe los archivos en el sistema de archivos del host, y en Windows parece que no lo hace. Oh... ¿puede ser porque el volumen del host no es un volumen de bloque?

Hace casi un año, cuando estaba tratando de resolver esto, encontré este tema. Dado que no se proporcionó ninguna solución en ese momento, creé un montón de scripts bash de ajuste para ejecutar su docker-compose.

Ahora después de un año es todo lo mismo. Me pregunto cuántas veces se tarda en resolver un problema tan simple para un software como docker-compose, que ni siquiera es un proveedor real, sino un contenedor.

$UID no se exporta en Linux de forma predeterminada, ¿de acuerdo? Esto nos impide crear un docker-compose universal, lo cual es algo extraño en sí mismo, ya que se supone que esta pieza de software es una solución de front-end, ¿verdad?

Si no les gusta perder el tiempo con tonterías, y lo entiendo, ¿por qué no nos dejan ejecutar un comando de host aleatorio antes de ejecutar un servicio, eh? Podríamos hacer algo como esto:

services:
  web:
     ...
     host_command: export UID

¿No es eso obvio?

+1

Este problema no tiene suficientes Me gusta y +1 y, para mí, es algo que se pasa por alto pero que muchos usuarios necesitan y solicitan, incluido yo mismo.

Estoy aquí para dar mi +1 también porque estoy afectado por esto. Actualmente no quiero que mis contenedores se ejecuten como raíz, pero quiero que compartan un volumen en el host que mi usuario puede escribir. Esto no se puede hacer si no configuro el usuario y la expansión sería la forma más natural de hacerlo en lugar de user: 1000:1000 porque, como se indicó anteriormente, causará conflictos con los usuarios con otro entorno. $UID, incluso si no se exporta, demuestra ser una mejor solución ya que se basa en el entorno que en la exposición acoplable.

Sólo mis 2 centavos. Entonces, ¿alguien encontró una manera de hacer esto de todos modos?

@darkguy2008 : asegúrese de promocionar este: https://github.com/moby/moby/issues/22415

Sospecho que se necesitará una función dentro de Docker antes de que Compose pueda construir sobre ella.

No estoy seguro de entender, docker-compose run --user es una opción, y docker-compose.yml admite la clave user (http://docs.docker.com/compose/yml/ #working95dir-entrypoint-user-hostname-domainname-mem95limit-privileged-restart-stdin95open-tty-cpu95shares).

Supongo que necesitaríamos admitir la resolución de variables de entorno en el campo user para que pueda configurarlo en $UID ¿no es así? #1377

El enlace está roto.

Descubrí que agregar una variable obligatoria ayudó como solución alternativa:

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

Mostraría:

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

Especificando que el archivo debe ejecutarse así:

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

Descubrí que agregar una variable obligatoria ayudó como solución alternativa:

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

Mostraría:

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

Especificando que el archivo debe ejecutarse así:

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

El problema es que mis servicios requieren root de acceso para comenzar. P.ej:

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