une solution très élégante peut être vue sur le Redis image et en général dans toutes les images officielles.

décrit dans le processus étape par étape:

• Créer redis utilisateur/groupe, avant toute autre chose

Comme on le voit sur Dockerfile commentaires:

ajouter notre utilisateur et groupe d'abord pour s'assurer que leurs ID sont attribués de façon uniforme, quelles que soient les dépendances ajoutées

• Installer gosu avec Dockerfile

gosu est une alternative de su / sudo pour le step-down facile de l'utilisateur root. (Redis est toujours exécuté avec redis user)

• Configurer /data le volume et la définir comme workdir

en configurant le / volume de données avec la commande VOLUME /data , nous avons maintenant un volume séparé qui peut être soit le volume du docker, soit relié à un dir hôte.

le configure comme le workdir ( WORKDIR /data ) le rend le répertoire par défaut d'où les commandes sont exécutées.

• Ajouter un menu fixe-point d'entrée de fichier et de le définir comme point d'entrée par défaut CMD redis-server

par le script docker-entrypoint, et par défaut la commande à exécuter est redis-server.

docker-entrypoint est un script qui fait une fonction simple: changer la propriété du répertoire courant (/données) et passer de root à redis utilisateur pour exécuter redis-server . (Si la commande exécutée n'est pas redis-server, elle sera exécutée directement.)

cela a l'effet suivant

si le répertoire /data est monté par bind sur l'hôte, le docker-entrypoint préparera les permissions de l'utilisateur avant d'exécuter redis-server sous redis user.

cela vous donne la facilité d'esprit qu'il y a zero-setup afin d'exécuter le conteneur sous n'importe quelle configuration de volume.

bien sûr, si vous avez besoin de partager le volume entre différentes images, vous devez vous assurer qu'ils utilisent le même userid / groupid sinon le dernier conteneur sera détourner les permissions de l'utilisateur de la précédente.

ce n'est sans doute pas la meilleure façon pour la plupart des circonstances, mais il n'a pas été mentionné encore, donc peut-être qu'il aidera quelqu'un.

1. Lier mont volume hôte

   Host folder FOOBAR is mounted in container /volume/FOOBAR

2. modifier le script de démarrage de votre conteneur pour trouver GID du volume vous êtes intéressé par

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

3. Assurer votre utilisateur appartient à un groupe avec ce GID (vous pourriez avoir à créer un nouveau groupe). Pour cet exemple, je vais prétendre que mon logiciel fonctionne comme l'utilisateur nobody à l'intérieur du conteneur, donc je veux m'assurer que nobody appartient à un groupe avec un id de groupe égal à TARGET_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

j'aime cela parce que je peux facilement modifier les permissions de groupe sur mes volumes hôtes et je sais que ces permissions mises à jour appliquer à l'intérieur du conteneur docker. Cela se produit sans aucune permission ou modification de propriété de mes dossiers/fichiers hôtes, ce qui me rend heureux.

Je n'aime pas cela parce qu'il suppose qu'il n'y a aucun danger à s'ajouter à un groupe arbitraire à l'intérieur du conteneur qui se trouve à utiliser un GID que vous voulez. Il ne peut pas être utilisé avec une clause USER dans un fichier Dockerfile (à moins que cet utilisateur ait les privilèges root je suppose). Aussi, il crie travail de piratage; -)

si vous voulez être hardcore vous pouvez évidemment étendre cela de plusieurs façons - par exemple, rechercher tous les groupes sur n'importe quels sous-Fichiers, plusieurs volumes, etc.

Ok, c'est maintenant suivi à docker question n ° 7198

pour l'instant, je m'en occupe en utilisant votre deuxième option:

cartographier les utilisateurs de l'hôte dans le conteneur

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

mise à JOUR je ne suis plus enclin à Hamy réponse

essayez d'ajouter une commande à Dockerfile

RUN usermod -u 1000 www-data

les crédits vont à https://github.com/denderello/symfony-docker-example/issues/2#issuecomment-94387272

tout comme vous, je cherchais un moyen de cartographier les utilisateurs/groupes de l'hôte aux conteneurs docker et c'est le moyen le plus court que j'ai trouvé jusqu'à présent:

  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
        .....

ceci est un extrait de ma Docker-composition.yml.

l'idée est de monter (en mode Lecture seule) des listes d'utilisateurs/groupes de l'hôte vers le conteneur ainsi, après le démarrage du conteneur, il aura le même UID->nom d'utilisateur (ainsi que pour les groupes) appariements avec l'hôte. Maintenant, vous pouvez configurez les paramètres utilisateur/groupe pour votre service à l'intérieur du conteneur comme s'il fonctionnait sur votre système hôte.

lorsque vous décidez de déplacer votre conteneur vers un autre hôte, vous avez juste besoin de changer le nom d'utilisateur dans le fichier de configuration service en ce que vous avez sur cet hôte.

Voici une approche qui utilise toujours un conteneur de données seulement mais qui n'exige pas qu'il soit synchronisé avec le conteneur d'application (en termes d'avoir le même uid/gid).

probablement, vous voulez exécuter une application dans le conteneur comme un utilisateur $non-root sans shell de login.

dans le fichier Dockerfile:

RUN useradd -s /bin/false myuser

# Set environment variables
ENV VOLUME_ROOT /data
ENV USER myuser

...

ENTRYPOINT ["./entrypoint.sh"]

puis, en entrypoint.sh:

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

pour sécuriser et changer la racine pour Docker container un hôte docker essayer d'utiliser --uidmap et --private-uids options

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

vous pouvez également supprimer plusieurs fonctionnalités ( --cap-drop ) dans Docker container pour la sécurité

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

mise à JOUR soutien doit venir dans docker > 1.7.0

mise à JOUR Version 1.10.0 (2016-02-04) ajouter --userns-remap drapeau https://github.com/docker/docker/blob/master/CHANGELOG.md#security-2

Image De Base

utilisez cette image: https://hub.docker.com/r/reduardo7/docker-host-user

ou

Important: cela détruit la portabilité des conteneurs entre les hôtes .

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) Construire avec docker

4) courez!

sh run.sh

pour partager le dossier entre l'hôte docker et le conteneur docker, essayez sous la commande

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

le drapeau-v monte le répertoire courant dans le conteneur. Lorsque le répertoire hôte d'un volume monté sur bind n'existe pas, Docker créera automatiquement ce répertoire sur l'hôte pour vous,

cependant, il y a 2 problèmes que nous avons ici:

1. vous ne pouvez pas écrire au volume monté si vous étiez utilisateur non root parce que le fichier partagé sera la propriété d'un autre utilisateur dans l'hôte,
2. vous ne devriez pas exécuter le processus à l'intérieur de vos conteneurs en tant que root, mais même si vous exécutez comme un utilisateur codé dur, il ne correspond toujours pas à l'utilisateur sur votre ordinateur portable/Jenkins,

Solution:

conteneur: créer un utilisateur dire 'testuser', par défaut l'ID de l'Utilisateur sera à partir de 1000,

Host: créer un groupe Dire 'testgroup' avec le groupe id 1000, et parcourir le répertoire vers le nouveau groupe(testgroup

mon approche est de détecter uid/GID courant, puis de créer un tel utilisateur / groupe à l'intérieur du conteneur et d'exécuter le script sous lui, alors tous les fichiers qu'il va créer correspondra à l'utilisateur qui exécute le 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"

dans mon cas particulier, j'essayais de construire mon paquet node avec l'image node docker pour ne pas avoir à installer npm sur le serveur de déploiement. Cela a bien fonctionné jusqu'à ce que, à l'extérieur du conteneur et sur la machine hôte, j'ai essayé de déplacer un fichier dans le répertoire node_modules que l'image du docker node avait créé, auquel on m'a refusé les permissions parce qu'il appartenait à root. J'ai réalisé que je pouvais contourner ce problème en copiant le répertoire le contenant sur l'ordinateur hôte machine. Via docker docs ...

les fichiers copiés sur la machine locale sont créés avec L'UID: GID du utilisateur qui a invoqué la commande docker cp.

c'est le code bash que j'ai utilisé pour changer la propriété du répertoire créé par et dans le conteneur docker.

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 nécessaire, vous pouvez supprimer le répertoire avec un deuxième conteneur docker.

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

si vous utilisez Docker composer, démarrer le conteneur en mode prévileged:

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