Docker non può scrivere in directory montata usando -v a less che non disponga di 777 autorizzazioni

Sto usando l'image docker-solr con docker, e ho bisogno di montare una directory all'interno di essa che ottengo utilizzando la bandiera -v .

Il problema è che il contenitore deve scrivere nella directory che ho montato in esso, ma non sembra avere le autorizzazioni per farlo a less che non faccio chmod 777 nell'intera directory. Non credo che l'impostazione dell'authorization per consentire a tutti gli utenti di leggere e scrivere è la soluzione, ma solo una soluzione temporanea.

Qualcuno può guidarmi nella ricerca di una soluzione più canonica?

Modifica: ho eseguito il docker senza sudo perché mi sono aggiunto al gruppo docker. Ho appena trovato che il problema è risolto se ho eseguito docker con sudo , ma sono curioso se ci sono altre soluzioni.

Più di recente, dopo aver esaminato alcuni repository ufficiale del docker ho capito che il modo più idiomatico per risolvere questi problemi di authorization è quello di utilizzare qualcosa chiamato gosu in tandem con uno script di punto di entrata. Ad esempio, se prendiamo un progetto docker esistente, ad esempio solr, lo stesso che avevo problemi con prima.

Il file docker su Github crea molto efficacemente l'integer progetto, ma non fa nulla per tenere conto dei problemi di authorization.

Quindi, per superare questo problema, ho aggiunto prima la configuration del gosu al file dockerfile (se implementi questo avviso la versione 1.4 è codificata. È ansible controllare qui le ultime versioni).

 # 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 esattamente come su o sudo , ma funziona molto meglio con il docker. Dalla descrizione per gosu:

Questo è un semplice strumento cresciuto dal semplice fatto che su e sudo hanno molto strano e spesso fastidioso comportmento TTY e di trasmissione del segnale.

Ora le altre modifiche apportte al file dockerfile sono quelle che aggiungono 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 di entrata al contenitore docker.

e rimuovendo la linea:

 USER $SOLR_USER 

Quindi per impostazione predefinita sei l'utente root. (ecco perché abbiamo gosu a scendere dalla radice).

Ora, come per il mio file di entrata, non credo che sia scritto in modo perfetto, ma ha fatto il lavoro.

 #!/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 [email protected] ;; esac 

Un command di esecuzione docker assume la forma:

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

Fondamentalmente il punto di inserimento dice se voglio eseguire solr come al solito passiamo l'argomento start alla fine del command come questo:

 docker run <flags> <image-name> start 

e altrimenti eseguire i comandi da passare come root.

L'opzione di startinnanzitutto la properties; del proprietario di solr delle directory e quindi esegue il command predefinito. Ciò risolve il problema della properties;, perché diversamente dalla configuration del file docker, che è una cosa una volta, il punto di accesso viene eseguito each volta.

Quindi, ora, se monterò le directory usando la bandiera -d, prima che il punto di ingresso effettivamente esegue solr, chown i file all'interno del contenitore docker per te.

Quanto a ciò che fa ai tuoi files fuori dal contenitore ho avuto risultati misti perché il docker agisce un po 'strano su OSX. Per me, non ha cambiato i file al di fuori del contenitore, ma su un altro sistema operativo where il docker gioca più bene con il filesystem, potrebbe cambiare i tuoi file fuori, ma credo che è quello che dovrai occupare se vuoi per montare file all'interno del contenitore invece di copiarli.