He estado jugando con Docker por un tiempo y sigo encontrando el mismo problema cuando trato con datos persistentes.

Creo mi Dockerfiley expongo un volumen o lo uso --volumes-frompara montar una carpeta de host dentro de mi contenedor .

¿Qué permisos debo aplicar al volumen compartido en el host?

Se me ocurren dos opciones:

• Hasta ahora les he dado a todos acceso de lectura / escritura, para poder escribir en la carpeta desde el contenedor Docker.

• Asigne los usuarios del host al contenedor, para que pueda asignar permisos más granulares. Sin embargo, no estoy seguro de que esto sea posible y no he encontrado mucho al respecto. Hasta ahora, todo lo que puedo hacer es ejecutar el contenedor como un usuario: docker run -i -t -user="myuser" postgrespero este usuario tiene un UID diferente que mi host myuser, por lo que los permisos no funcionan. Además, no estoy seguro si mapear a los usuarios planteará algunos riesgos de seguridad.

¿Hay otras alternativas?

¿Cómo están ustedes / chicas lidiando con este problema?

ACTUALIZACIÓN 2016-03-02 : A partir de Docker 1.9.0, Docker ha nombrado volúmenes que reemplazan los contenedores de solo datos . La respuesta a continuación, así como mi publicación de blog vinculada, todavía tiene valor en el sentido de cómo pensar sobre los datos dentro de la ventana acoplable, pero considere usar volúmenes con nombre para implementar el patrón que se describe a continuación en lugar de los contenedores de datos.

Creo que la forma canónica de resolver esto es mediante el uso de contenedores solo de datos . Con este enfoque, todo el acceso a los datos del volumen es a través de contenedores que usan -volumes-fromel contenedor de datos, por lo que el host uid / gid no importa.

Por ejemplo, un caso de uso dado en la documentación es hacer una copia de seguridad de un volumen de datos. Para hacer esto, se usa otro contenedor para hacer la copia de seguridad a través tar, y también se usa -volumes-frompara montar el volumen. Entonces, creo que el punto clave para asimilar es: en lugar de pensar en cómo obtener acceso a los datos en el host con los permisos adecuados, piense en cómo hacer lo que necesite: copias de seguridad, navegación, etc., a través de otro contenedor . Los contenedores en sí mismos necesitan usar uid / gids consistentes, pero no necesitan mapearse a nada en el host, por lo que permanecen portátiles.

Esto también es relativamente nuevo para mí, pero si tiene un caso de uso en particular, no dude en comentar y trataré de ampliar la respuesta.

ACTUALIZACIÓN : para el caso de uso dado en los comentarios, es posible que tenga una imagen some/graphitepara ejecutar grafito y una imagen some/graphitedatacomo contenedor de datos. Entonces, ignorando los puertos y demás, la Dockerfileimagen some/graphitedataes algo así como:

FROM debian:jessie
# add our user and group first to make sure their IDs get assigned consistently, regardless of other deps added later
RUN groupadd -r graphite \
  && useradd -r -g graphite graphite
RUN mkdir -p /data/graphite \
  && chown -R graphite:graphite /data/graphite
VOLUME /data/graphite
USER graphite
CMD ["echo", "Data container for graphite"]

Construye y crea el contenedor de datos:

docker build -t some/graphitedata Dockerfile
docker run --name graphitedata some/graphitedata

El some/graphiteDockerfile también debería obtener los mismos uid / gids, por lo tanto, podría verse así:

FROM debian:jessie
# add our user and group first to make sure their IDs get assigned consistently, regardless of other deps added later
RUN groupadd -r graphite \
  && useradd -r -g graphite graphite
# ... graphite installation ...
VOLUME /data/graphite
USER graphite
CMD ["/bin/graphite"]

Y se ejecutaría de la siguiente manera:

docker run --volumes-from=graphitedata some/graphite

Ok, ahora eso nos da nuestro contenedor de grafito y el contenedor de solo datos asociados con el usuario / grupo correcto (tenga en cuenta que también puede reutilizar el some/graphitecontenedor para el contenedor de datos, anulando el entradapoing / cmd cuando lo ejecute, pero tenerlos como imágenes separadas IMO es más claro).

Ahora, supongamos que desea editar algo en la carpeta de datos. Entonces, en lugar de vincular el montaje del volumen al host y editarlo allí, cree un nuevo contenedor para hacer ese trabajo. Vamos a llamarlo some/graphitetools. También creemos el usuario / grupo apropiado, al igual que la some/graphiteimagen.

FROM debian:jessie
# add our user and group first to make sure their IDs get assigned consistently, regardless of other deps added later
RUN groupadd -r graphite \
  && useradd -r -g graphite graphite
VOLUME /data/graphite
USER graphite
CMD ["/bin/bash"]

Puede hacer esto SECO heredando de some/graphiteo some/graphitedataen el Dockerfile, o en lugar de crear una nueva imagen, simplemente reutilice una de las existentes (anulando el punto de entrada / cmd según sea necesario).

Ahora, simplemente ejecutas:

docker run -ti --rm --volumes-from=graphitedata some/graphitetools

y luego vi /data/graphite/whatever.txt. Esto funciona perfectamente porque todos los contenedores tienen el mismo usuario de grafito con uid / gid coincidentes.

Como nunca monta /data/graphitedesde el host, no le importa cómo el uid / gid del host se asigna al uid / gid definido dentro de los contenedores graphitey graphitetools. Esos contenedores ahora se pueden implementar en cualquier host y continuarán funcionando perfectamente.

Lo bueno de esto es que graphitetoolspodría tener todo tipo de utilidades y scripts útiles, que ahora también puede implementar de manera portátil.

ACTUALIZACIÓN 2 : Después de escribir esta respuesta, decidí escribir una publicación de blog más completa sobre este enfoque. Espero que ayude.

ACTUALIZACIÓN 3 : Corrigí esta respuesta y agregué más detalles. Anteriormente contenía algunas suposiciones incorrectas sobre la propiedad y los permisos: la propiedad generalmente se asigna en el momento de la creación del volumen, es decir, en el contenedor de datos, porque es cuando se crea el volumen. Ver este blog . Sin embargo, esto no es un requisito: puede usar el contenedor de datos como "referencia / identificador" y establecer la propiedad / permisos en otro contenedor a través de chown en un punto de entrada, que termina con gosu para ejecutar el comando como el usuario correcto. Si alguien está interesado en este enfoque, comente y puedo proporcionar enlaces a una muestra utilizando este enfoque.

Se puede ver una solución muy elegante en la imagen oficial de redis y, en general, en todas las imágenes oficiales.

Descrito en el proceso paso a paso:

• Crear usuario / grupo redis antes que nada

Como se ve en los comentarios de Dockerfile:

agregue nuestro usuario y grupo primero para asegurarse de que sus ID se asignen de manera consistente, independientemente de las dependencias que se agreguen

• Instalar gosu con Dockerfile

Gosu es una alternativa de su/ sudopara bajar fácilmente del usuario root. (Redis siempre se ejecuta con el redisusuario)

• Configure el /datavolumen y configúrelo como workdir

Al configurar el volumen de datos / con el VOLUME /datacomando ahora tenemos un volumen separado que puede ser un volumen acoplable o montado en un directorio host.

Configurarlo como workdir ( WORKDIR /data) lo convierte en el directorio predeterminado desde donde se ejecutan los comandos.

• Agregue el archivo docker-entrypoint y configúrelo como ENTRYPOINT con CMD redis-server predeterminado

Esto significa que todas las ejecuciones de contenedores se ejecutarán a través de la secuencia de comandos docker-entrypoint y, de forma predeterminada, el comando que se ejecutará es redis-server.

docker-entrypointes un script que realiza una función simple: cambiar la propiedad del directorio actual (/ datos) y descender de rootun redisusuario a otro para ejecutarlo redis-server. (Si el comando ejecutado no es redis-server, ejecutará el comando directamente).

Esto tiene el siguiente efecto

Si el directorio / data está montado en enlace al host, el punto de entrada de docker preparará los permisos de usuario antes de ejecutar redis-server bajo redisuser.

Esto le da la tranquilidad de que hay una configuración cero para ejecutar el contenedor en cualquier configuración de volumen.

Por supuesto, si necesita compartir el volumen entre diferentes imágenes, debe asegurarse de que usen el mismo ID de usuario / ID de grupo; de lo contrario, el último contenedor secuestrará los permisos de usuario del anterior.

Podría decirse que esta no es la mejor manera para la mayoría de las circunstancias, pero aún no se ha mencionado, por lo que quizás ayude a alguien.

1. Volumen de host de montaje de enlace

   Host folder FOOBAR is mounted in container /volume/FOOBAR

2. Modifique el script de inicio de su contenedor para encontrar el GID del volumen que le interesa

   $ TARGET_GID=$(stat -c "%g" /volume/FOOBAR)

3. Asegúrese de que su usuario pertenezca a un grupo con este GID (puede que tenga que crear un nuevo grupo). Para este ejemplo, fingiré que mi software se ejecuta como el nobodyusuario cuando está dentro del contenedor, por lo que quiero asegurarme de que nobodypertenece a un grupo con una identificación de grupo igual aTARGET_GID

  EXISTS=$(cat /etc/group | grep $TARGET_GID | wc -l)

  # Create new group using target GID and add nobody user
  if [ $EXISTS == "0" ]; then
    groupadd -g $TARGET_GID tempgroup
    usermod -a -G tempgroup nobody
  else
    # GID exists, find group name and add
    GROUP=$(getent group $TARGET_GID | cut -d: -f1)
    usermod -a -G $GROUP nobody
  fi

Me gusta esto porque puedo modificar fácilmente los permisos de grupo en mis volúmenes de host y sé que esos permisos actualizados se aplican dentro del contenedor acoplable. Esto sucede sin ningún permiso o modificaciones de propiedad de mis carpetas / archivos de host, lo que me hace feliz.

No me gusta esto porque supone que no hay peligro en agregarse a un grupo arbitrario dentro del contenedor que está usando un GID que desea. No se puede usar con una USERcláusula en un Dockerfile (a menos que ese usuario tenga privilegios de root, supongo). Además, grita trabajo de pirateo ;-)

Si quiere ser hardcore, obviamente puede extender esto de muchas maneras, por ejemplo, buscar todos los grupos en cualquier subarchivo, múltiples volúmenes, etc.

Ok, esto ahora está siendo rastreado en el docker número 7198

Por ahora, estoy lidiando con esto usando su segunda opción:

Asigne los usuarios del host al contenedor

Dockerfile

#=======
# Users
#=======
# TODO: Idk how to fix hardcoding uid & gid, specifics to docker host machine
RUN (adduser --system --uid=1000 --gid=1000 \
        --home /home/myguestuser --shell /bin/bash myguestuser)

CLI

# DIR_HOST and DIR_GUEST belongs to uid:gid 1000:1000
docker run -d -v ${DIR_HOST}:${DIR_GUEST} elgalu/myservice:latest

ACTUALIZACIÓN Actualmente estoy más inclinado a responder Hamy

Intenta agregar un comando a Dockerfile

RUN usermod -u 1000 www-data

los créditos van a https://github.com/denderello/symfony-docker-example/issues/2#issuecomment-94387272

Al igual que usted, estaba buscando una forma de asignar usuarios / grupos desde el host a los contenedores acoplables y esta es la forma más corta que he encontrado hasta ahora:

  version: "3"
    services:
      my-service:
        .....
        volumes:
          # take uid/gid lists from host
          - /etc/passwd:/etc/passwd:ro
          - /etc/group:/etc/group:ro
          # mount config folder
          - path-to-my-configs/my-service:/etc/my-service:ro
        .....

Este es un extracto de mi docker-compose.yml.

La idea es montar (en modo de solo lectura) listas de usuarios / grupos desde el host al contenedor, por lo tanto, después de que el contenedor se inicie, tendrá las mismas coincidencias uid-> username (así como para grupos) con el host. Ahora puede configurar los ajustes de usuario / grupo para su servicio dentro del contenedor como si estuviera funcionando en su sistema host.

Cuando decide mover su contenedor a otro host, solo necesita cambiar el nombre de usuario en el archivo de configuración del servicio a lo que tiene en ese host.

Aquí hay un enfoque que todavía usa un contenedor de solo datos pero no requiere que se sincronice con el contenedor de la aplicación (en términos de tener el mismo uid / gid).

Presumiblemente, desea ejecutar alguna aplicación en el contenedor como un $ USER no root sin un shell de inicio de sesión.

En el Dockerfile:

RUN useradd -s /bin/false myuser

# Set environment variables
ENV VOLUME_ROOT /data
ENV USER myuser

...

ENTRYPOINT ["./entrypoint.sh"]

Luego, en entrypoint.sh:

chown -R $USER:$USER $VOLUME_ROOT
su -s /bin/bash - $USER -c "cd $repo/build; $@"

Para la raíz y el cambio seguro para el envase de una ventana acoplable anfitrión intento utilización ventana acoplable --uidmapy --private-uidsopciones

https://github.com/docker/docker/pull/4572#issuecomment-38400893

También puede eliminar varias capacidades ( --cap-drop) en el contenedor docker por seguridad

http://opensource.com/business/14/9/security-for-docker

El soporte de ACTUALIZACIÓN debería venirdocker > 1.7.0

Versión ACTUALIZADA1.10.0 (2016-02-04) agregar --userns-remapbandera https://github.com/docker/docker/blob/master/CHANGELOG.md#security-2

Mi enfoque es detectar el UID / GID actual, luego crear dicho usuario / grupo dentro del contenedor y ejecutar el script debajo de él. Como resultado, todos los archivos que creará coincidirán con el usuario en el host (que es el script):

# get location of this script no matter what your current folder is, this might break between shells so make sure you run bash
LOCAL_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"

# get current IDs
USER_ID=$(id -u)
GROUP_ID=$(id -g)

echo "Mount $LOCAL_DIR into docker, and match the host IDs ($USER_ID:$GROUP_ID) inside the container."

docker run -v $LOCAL_DIR:/host_mount -i debian:9.4-slim bash -c "set -euo pipefail && groupadd -r -g $GROUP_ID lowprivgroup && useradd -u $USER_ID lowprivuser -g $GROUP_ID && cd /host_mount && su -c ./runMyScriptAsRegularUser.sh lowprivuser"

Imagen base

Utilice esta imagen: https://hub.docker.com/r/reduardo7/docker-host-user

o

Importante: esto destruye la portabilidad del contenedor entre los hosts .

1) init.sh

#!/bin/bash

if ! getent passwd $DOCKDEV_USER_NAME > /dev/null
  then
    echo "Creating user $DOCKDEV_USER_NAME:$DOCKDEV_GROUP_NAME"
    groupadd --gid $DOCKDEV_GROUP_ID -r $DOCKDEV_GROUP_NAME
    useradd --system --uid=$DOCKDEV_USER_ID --gid=$DOCKDEV_GROUP_ID \
        --home-dir /home --password $DOCKDEV_USER_NAME $DOCKDEV_USER_NAME
    usermod -a -G sudo $DOCKDEV_USER_NAME
    chown -R $DOCKDEV_USER_NAME:$DOCKDEV_GROUP_NAME /home
  fi

sudo -u $DOCKDEV_USER_NAME bash

2) Dockerfile

FROM ubuntu:latest
# Volumes
    VOLUME ["/home/data"]
# Copy Files
    COPY /home/data/init.sh /home
# Init
    RUN chmod a+x /home/init.sh

3) run.sh

#!/bin/bash

DOCKDEV_VARIABLES=(\
  DOCKDEV_USER_NAME=$USERNAME\
  DOCKDEV_USER_ID=$UID\
  DOCKDEV_GROUP_NAME=$(id -g -n $USERNAME)\
  DOCKDEV_GROUP_ID=$(id -g $USERNAME)\
)

cmd="docker run"

if [ ! -z "${DOCKDEV_VARIABLES}" ]; then
  for v in ${DOCKDEV_VARIABLES[@]}; do
    cmd="${cmd} -e ${v}"
  done
fi

# /home/usr/data contains init.sh
$cmd -v /home/usr/data:/home/data -i -t my-image /home/init.sh

4) Construir con docker

4) ¡Corre!

sh run.sh

En mi caso específico, estaba tratando de construir mi paquete de nodos con la imagen del acoplador de nodos para no tener que instalar npm en el servidor de implementación. Funcionó bien hasta que, fuera del contenedor y en la máquina host, intenté mover un archivo al directorio node_modules que había creado la imagen del acoplador de nodo, para lo cual se me negaron los permisos porque era propiedad de root. Me di cuenta de que podía solucionar esto copiando el directorio del contenedor en la máquina host. A través de docker docs ...

Los archivos copiados en la máquina local se crean con el UID: GID del usuario que invocó el comando docker cp.

Este es el código bash que utilicé para cambiar la propiedad del directorio creado por y dentro del contenedor acoplable.

NODE_IMAGE=node_builder
docker run -v $(pwd)/build:/build -w="/build" --name $NODE_IMAGE node:6-slim npm i --production
# node_modules is owned by root, so we need to copy it out 
docker cp $NODE_IMAGE:/build/node_modules build/lambda 
# you might have issues trying to remove the directory "node_modules" within the shared volume "build", because it is owned by root, so remove the image and its volumes
docker rm -vf $NODE_IMAGE || true

Si es necesario, puede eliminar el directorio con un segundo contenedor acoplable.

docker run -v $(pwd)/build:/build -w="/build" --name $RMR_IMAGE node:6-slim rm -r node_modules

Para compartir la carpeta entre el host de Docker y el contenedor de Docker, pruebe el siguiente comando

$ docker run -v "$ (pwd): $ (pwd)" -i -t ubuntu

El indicador -v monta el directorio de trabajo actual en el contenedor. Cuando el directorio de host de un volumen montado en enlace no existe, Docker creará automáticamente este directorio en el host para usted,

Sin embargo, hay 2 problemas que tenemos aquí:

1. No puede escribir en el volumen montado si no era usuario root porque el archivo compartido será propiedad de otro usuario en el host,
2. No debe ejecutar el proceso dentro de sus contenedores como root, pero incluso si lo ejecuta como un usuario codificado, no coincidirá con el usuario en su computadora portátil / Jenkins,

Solución:

Contenedor: cree un usuario que diga 'testuser', por defecto la identificación del usuario comenzará desde 1000,

Anfitrión: cree un grupo que diga 'testgroup' con la identificación de grupo 1000 y asigne el directorio al nuevo grupo (testgroup

Si usa Docker Compose, inicie el contenedor en modo anterior:

wordpress:
    image: wordpress:4.5.3
    restart: always
    ports:
      - 8084:80
    privileged: true