Ho giocato con Docker per un po 'e continuo a trovare lo stesso problema quando si tratta di dati persistenti.

Creo il mio Dockerfileed espongo un volume o utilizzo --volumes-fromper montare una cartella host all'interno del mio contenitore .

Quali autorizzazioni devo applicare al volume condiviso sull'host?

Mi vengono in mente due opzioni:

• Finora ho dato a tutti l'accesso in lettura / scrittura, quindi posso scrivere nella cartella dal contenitore Docker.

• Mappare gli utenti dall'host nel contenitore, in modo da poter assegnare autorizzazioni più granulari. Non sono sicuro che ciò sia possibile e non ne ho trovato molto. Finora, tutto ciò che posso fare è eseguire il contenitore come un utente: docker run -i -t -user="myuser" postgresma questo utente ha un UID diverso dal mio host myuser, quindi le autorizzazioni non funzionano. Inoltre, non sono sicuro che la mappatura degli utenti comporti alcuni rischi per la sicurezza.

Ci sono altre alternative?

Come state ragazzi / ragazze ad affrontare questo problema?

AGGIORNAMENTO 2016-03-02 : A partire da Docker 1.9.0, Docker ha denominato i volumi che sostituiscono i contenitori di soli dati . La risposta che segue, così come il mio post sul blog collegato, ha ancora valore nel senso di come pensare ai dati all'interno della finestra mobile ma considera l'utilizzo di volumi con nome per implementare il modello descritto di seguito piuttosto che contenitori di dati.

Credo che il modo canonico per risolverlo sia utilizzare contenitori di soli dati . Con questo approccio, tutto l'accesso ai dati del volume avviene tramite contenitori che utilizzano -volumes-fromil contenitore di dati, quindi l'host uid / gid non ha importanza.

Ad esempio, un caso d'uso riportato nella documentazione è il backup di un volume di dati. Per fare ciò, un altro contenitore viene utilizzato per eseguire il backup tramite tare anch'esso viene utilizzato -volumes-fromper montare il volume. Quindi penso che il punto chiave di Grok sia: piuttosto che pensare a come ottenere l'accesso ai dati sull'host con le autorizzazioni appropriate, pensare a come fare tutto ciò di cui hai bisogno - backup, navigazione, ecc. - tramite un altro contenitore . I container stessi devono usare uid / gid coerenti, ma non devono mappare nulla sull'host, rimanendo così portatili.

Questo è relativamente nuovo anche per me, ma se hai un caso d'uso particolare sentiti libero di commentare e proverò ad espandere la risposta.

AGGIORNAMENTO : per il caso d'uso indicato nei commenti, potresti avere un'immagine some/graphiteper eseguire la grafite e un'immagine some/graphitedatacome contenitore di dati. Quindi, ignorando le porte e simili, l' Dockerfileimmagine di some/graphitedataè qualcosa di simile:

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"]

Compilare e creare il contenitore di dati:

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

Il some/graphiteDockerfile dovrebbe anche avere lo stesso uid / gids, quindi potrebbe assomigliare a questo:

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"]

E sarebbe eseguito come segue:

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

Ok, ora che ci dà il nostro contenitore di grafite e il contenitore associato solo ai dati con l'utente / gruppo corretto (nota che potresti riutilizzare il some/graphitecontenitore anche per il contenitore di dati, sovrascrivendo il entrypoing / cmd durante l'esecuzione, ma avendo come immagini separate IMO è più chiaro).

Ora, supponiamo che tu voglia modificare qualcosa nella cartella dei dati. Quindi, piuttosto che associare il montaggio del volume all'host e modificarlo lì, creare un nuovo contenitore per fare quel lavoro. Chiamiamolo some/graphitetools. Consente inoltre di creare l'utente / gruppo appropriato, proprio come l' some/graphiteimmagine.

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"]

Puoi fare questo DRY ereditando da some/graphiteo some/graphitedatanel Dockerfile, o invece di creare una nuova immagine semplicemente riutilizzare una di quelle esistenti (sovrascrivendo entrypoint / cmd secondo necessità).

Ora corri semplicemente:

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

e poi vi /data/graphite/whatever.txt. Funziona perfettamente perché tutti i contenitori hanno lo stesso utente di grafite con uid / gid corrispondenti.

Dal momento che non esegui mai il mount /data/graphitedall'host, non ti interessa come l'host uid / gid viene mappato sull'uid / gid definito all'interno dei contenitori graphitee graphitetools. Questi contenitori ora possono essere distribuiti a qualsiasi host e continueranno a funzionare perfettamente.

La cosa bella di questo è che graphitetoolspotrebbe avere ogni sorta di utilità e script utili, che ora puoi anche distribuire in modo portatile.

AGGIORNAMENTO 2 : Dopo aver scritto questa risposta, ho deciso di scrivere un post sul blog più completo su questo approccio. Spero possa essere d'aiuto.

AGGIORNAMENTO 3 : ho corretto questa risposta e aggiunto ulteriori dettagli. In precedenza conteneva alcuni presupposti errati sulla proprietà e sui permanenti: la proprietà viene generalmente assegnata al momento della creazione del volume, ad esempio nel contenitore di dati, poiché è in quel momento che viene creato il volume. Vedere questo blog . Questo non è un requisito, tuttavia: è possibile utilizzare il contenitore di dati come "riferimento / handle" e impostare la proprietà / permanenti in un altro contenitore tramite chown in un punto di accesso, che termina con gosu per eseguire il comando come utente corretto. Se qualcuno è interessato a questo approccio, si prega di commentare e posso fornire collegamenti a un campione usando questo approccio.

Una soluzione molto elegante può essere vista sull'immagine redis ufficiale e in generale su tutte le immagini ufficiali.

Descritto in una procedura dettagliata:

• Crea utente / gruppo redis prima di ogni altra cosa

Come visto nei commenti su Dockerfile:

aggiungi prima il nostro utente e il nostro gruppo per assicurarti che i loro ID vengano assegnati in modo coerente, indipendentemente dalle dipendenze aggiunte

• Installa gosu con Dockerfile

gosu è un'alternativa di su/ sudoper un facile passaggio da utente root. (Redis viene sempre eseguito con l' redisutente)

• Configura il /datavolume e impostalo come workdir

Configurando il volume / data con il VOLUME /datacomando, ora abbiamo un volume separato che può essere sia il volume docker che il bind-mount su una directory host.

Configurandolo come workdir ( WORKDIR /data) lo rende la directory predefinita da cui vengono eseguiti i comandi.

• Aggiungi il file docker-entrypoint e impostalo come ENTRYPOINT con redis-server CMD predefinito

Ciò significa che tutte le esecuzioni dei container verranno eseguite tramite lo script docker-entrypoint e, per impostazione predefinita, il comando da eseguire è redis-server.

docker-entrypointè uno script che svolge una semplice funzione: cambia la proprietà della directory corrente (/ dati) e rootpassa da un redisutente all'altro per eseguirlo redis-server. (Se il comando eseguito non è redis-server, eseguirà direttamente il comando.)

Questo ha il seguente effetto

Se la directory / data è montata sull'host, il docker-entrypoint preparerà le autorizzazioni utente prima di eseguire redis-server sotto l' redisutente.

Questo ti dà la facilità di pensare che non ci sia alcuna configurazione per eseguire il contenitore con qualsiasi configurazione di volume.

Naturalmente, se è necessario condividere il volume tra immagini diverse, è necessario assicurarsi che utilizzino lo stesso userid / groupid, altrimenti l'ultimo contenitore dirotterà le autorizzazioni utente da quella precedente.

Probabilmente questo non è il modo migliore per la maggior parte delle circostanze, ma non è stato ancora menzionato, quindi forse aiuterà qualcuno.

1. Associa il volume dell'host di montaggio

   Host folder FOOBAR is mounted in container /volume/FOOBAR

2. Modifica lo script di avvio del tuo contenitore per trovare il GID del volume che ti interessa

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

3. Assicurati che il tuo utente appartenga a un gruppo con questo GID (potrebbe essere necessario creare un nuovo gruppo). Per questo esempio farò finta che il mio software funzioni come nobodyutente quando si trova all'interno del contenitore, quindi voglio assicurarmi che nobodyappartenga a un gruppo con un ID gruppo uguale 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

Mi piace perché posso facilmente modificare le autorizzazioni di gruppo sui miei volumi host e sapere che tali autorizzazioni aggiornate si applicano all'interno del contenitore della finestra mobile. Ciò accade senza alcuna autorizzazione o modifica della proprietà delle mie cartelle / file host, il che mi rende felice.

Non mi piace perché presume che non vi sia alcun pericolo nell'aggiungersi a gruppi arbitrari all'interno del contenitore che utilizzano un GID desiderato. Non può essere utilizzato con una USERclausola in un file Docker (a meno che quell'utente non abbia i privilegi di root suppongo). Inoltre, urla lavoro hack ;-)

Se vuoi essere hardcore puoi ovviamente estenderlo in molti modi - ad es. Cerca tutti i gruppi su qualsiasi sottofile, più volumi, ecc.

Ok, questo è ora monitorato al numero docker # 7198

Per ora, ho a che fare con questo usando la tua seconda opzione:

Mappare gli utenti dall'host nel contenitore

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

AGGIORNAMENTO Al momento sono più propenso alla risposta di Hamy

Prova ad aggiungere un comando a Dockerfile

RUN usermod -u 1000 www-data

i crediti vanno a https://github.com/denderello/symfony-docker-example/issues/2#issuecomment-94387272

Come te, stavo cercando un modo per mappare utenti / gruppi dall'host ai container docker e questo è il modo più breve che ho trovato finora:

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

Questo è un estratto dal mio docker-compose.yml.

L'idea è di montare (in modalità di sola lettura) elenchi di utenti / gruppi dall'host al contenitore, quindi dopo l'avvio del contenitore avrà gli stessi uid-> username (oltre che per i gruppi) corrispondenze con l'host. Ora puoi configurare le impostazioni utente / gruppo per il tuo servizio all'interno del contenitore come se stesse funzionando sul tuo sistema host.

Quando decidi di spostare il container su un altro host, devi solo cambiare il nome utente nel file di configurazione del servizio con quello che hai su quell'host.

Ecco un approccio che utilizza ancora un contenitore di soli dati ma non richiede la sincronizzazione con il contenitore dell'applicazione (in termini di avere lo stesso uid / gid).

Presumibilmente, si desidera eseguire alcune app nel contenitore come $ USER non root senza una shell di accesso.

Nel file Docker:

RUN useradd -s /bin/false myuser

# Set environment variables
ENV VOLUME_ROOT /data
ENV USER myuser

...

ENTRYPOINT ["./entrypoint.sh"]

Quindi, in entrypoint.sh:

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

Per proteggere e cambiare root per il contenitore docker, un host docker prova a utilizzare --uidmape le --private-uidsopzioni

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

Inoltre, è possibile rimuovere diverse funzionalità ( --cap-drop) nel contenitore docker per motivi di sicurezza

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

Il supporto AGGIORNAMENTO dovrebbe entraredocker > 1.7.0

Versione AGGIORNAMENTO1.10.0 (04-02-2016) aggiungi --userns-remapflag https://github.com/docker/docker/blob/master/CHANGELOG.md#security-2

Il mio approccio è di rilevare l'UID / GID corrente, quindi creare tale utente / gruppo all'interno del contenitore ed eseguire lo script sotto di lui. Di conseguenza tutti i file che creerà corrisponderanno all'utente sull'host (che è lo 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"

Immagine di base

Usa questa immagine: https://hub.docker.com/r/reduardo7/docker-host-user

o

Importante: questo distrugge la portabilità del contenitore tra host .

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) Costruisci con docker

4) Corri!

sh run.sh

Nel mio caso specifico, stavo cercando di creare il mio pacchetto di nodi con l'immagine della finestra mobile del nodo in modo da non dover installare npm sul server di distribuzione. Ha funzionato bene fino a quando, fuori dal contenitore e sulla macchina host, ho provato a spostare un file nella directory node_modules che l'immagine della finestra mobile del nodo aveva creato, a cui mi erano negate le autorizzazioni perché era di proprietà di root. Mi sono reso conto che avrei potuto aggirare questo problema copiando la directory dal contenitore sul computer host. Tramite documenti docker ...

I file copiati sul computer locale vengono creati con l'UID: GID dell'utente che ha invocato il comando docker cp.

Questo è il codice bash che ho usato per cambiare la proprietà della directory creata da e all'interno del contenitore 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

Se necessario, è possibile rimuovere la directory con un secondo contenitore finestra mobile.

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

Per condividere la cartella tra l'host docker e il contenitore docker, provare sotto il comando

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

Il flag -v monta la directory di lavoro corrente nel contenitore. Quando la directory host di un volume montato su bind non esiste, Docker creerà automaticamente questa directory sull'host per te,

Tuttavia, ci sono 2 problemi che abbiamo qui:

1. Non è possibile scrivere sul volume montato se si è utenti non root perché il file condiviso sarà di proprietà di un altro utente nell'host,
2. Non dovresti eseguire il processo all'interno dei tuoi contenitori come root ma anche se esegui come utente hardcoded, non corrisponderà comunque all'utente sul tuo laptop / Jenkins,

Soluzione:

Contenitore: crea un utente che dice "testuser", per impostazione predefinita l'id utente inizierà da 1000,

Host: crea un gruppo che dice 'testgroup' con ID gruppo 1000 e chown la directory al nuovo gruppo (testgroup

Se si utilizza Docker Compose, avviare il contenitore in modalità previleged:

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