Docker non può scrivere nella directory montata utilizzando -v a meno che non disponga di autorizzazioni 777

Question

Sto utilizzando l'immagine docker-solr con finestra mobile e ho bisogno di montare una directory al suo interno che ottengo utilizzando il flag -v.

Il problema è che il contenitore deve scrivere nella directory che ho montato, ma non sembra avere le autorizzazioni per farlo, a meno che non esegua l'operazione chmod 777 sull'intera directory. Non credo che impostare l'autorizzazione per consentire a tutti gli utenti di leggere e scrivere sia la soluzione, ma solo una soluzione temporanea.

Qualcuno può guidarmi nel trovare una soluzione più canonica?

Modifica: ho eseguito la finestra mobile senza sudo perché mi sono aggiunto al gruppo finestra mobile. Ho appena scoperto che il problema è risolto se eseguo la finestra mobile con sudo, ma sono curioso di sapere se ci sono altre soluzioni.

Answer 1

Più recentemente, dopo aver esaminato alcuni repository ufficiali di docker, mi sono reso conto che il modo più idiomatico per risolvere questi problemi di autorizzazione consiste nell'utilizzare qualcosa chiamato gosu in tandem con uno script del punto di ingresso. Ad esempio, se prendiamo un progetto di finestra mobile esistente, ad esempio solr, lo stesso con cui ho avuto problemi in precedenza.

Il su Github crea in modo molto efficace l'intero progetto, ma non fa nulla per giustificare i problemi di autorizzazione.

Quindi, per ovviare a ciò, ho prima aggiunto l'installazione di gosu al file docker (se si implementa questo avviso, la versione 1.4 è hardcoded. È possibile verificare le ultime versioni here).

# grab gosu for easy step-down from root 
RUN mkdir -p /home/solr \ 
    && gpg --keyserver pool.sks-keyservers.net --recv-keys B42F6819007F00F88E364FD4036A9C25BF357DD4 \ 
    && curl -o /usr/local/bin/gosu -SL "https://github.com/tianon/gosu/releases/download/1.4/gosu-$(dpkg --print-architecture)" \ 
    && curl -o /usr/local/bin/gosu.asc -SL "https://github.com/tianon/gosu/releases/download/1.4/gosu-$(dpkg --print-architecture).asc" \ 
    && gpg --verify /usr/local/bin/gosu.asc \ 
    && rm /usr/local/bin/gosu.asc \ 
    && chmod +x /usr/local/bin/gosu 

Ora possiamo usare gosu, che è sostanzialmente la stessa esatta come su o sudo, ma funziona molto più bene con finestra mobile. Dalla descrizione per gosu:

Questo è uno strumento semplice nato dal semplice fatto che su e sudo hanno un comportamento TTY e di inoltro del segnale molto strano e spesso fastidioso.

Ora gli altri cambiamenti che ho fatto al dockerfile erano questi aggiungendo queste righe:

COPY solr_entrypoint.sh /sbin/entrypoint.sh 
RUN chmod 755 /sbin/entrypoint.sh 
ENTRYPOINT ["/sbin/entrypoint.sh"] 

solo per aggiungere il mio file entrypoint al contenitore finestra mobile.

e rimuovendo la linea:

USER $SOLR_USER 

Così che di default si è l'utente root. (che è il motivo per cui abbiamo gosu a scendere dalla radice).

Ora come per il mio file di inserimento, non penso che sia stato scritto perfettamente, ma ha funzionato.

#!/bin/bash 

set -e 

export PS1="\w:\u docker-solr-> " 

# step down from root when just running the default start command 
case "$1" in 
    start) 
     chown -R solr /opt/solr/server/solr 
     exec gosu solr /opt/solr/bin/solr -f 
    ;; 
    *) 
     exec $@ 
    ;; 
esac 

Un comando di marcia finestra mobile assume la forma:

docker run <flags> <image-name> <passed in arguments> 

Fondamentalmente l'entrypoint dice che se voglio correre solr come al solito si passa l'argomento start alla fine del comando in questo modo:

docker run <flags> <image-name> start 

e altrimenti eseguire i comandi passati come root.

L'opzione startprima fornisce la proprietà utente solr delle directory e quindi esegue il comando predefinito. Questo risolve il problema della proprietà perché diversamente dall'impostazione del file docker, che è una cosa sola, il punto di ingresso viene eseguito ogni volta.

Così ora, se monto le directory usando il flag -d, prima che il punto di accesso sia effettivamente eseguito solr, sarà chown i file all'interno di del contenitore finestra mobile per voi.

Per quanto riguarda ciò che questo comporta per i file fuori dal contenitore, ho ottenuto risultati misti perché la finestra mobile agisce in modo un po 'strano su OSX. Per me, non ha cambiato i file al di fuori del contenitore, ma su un altro sistema operativo in cui la finestra mobile funziona meglio con il filesystem, potrebbe cambiare i file all'esterno, ma suppongo che sia quello con cui dovrai affrontare se vuoi per montare i file all'interno del contenitore invece di copiarli semplicemente.