2015-03-10 9 views
15

Prima di inoltrare un bug, vorrei chiedere a qualcuno di confermare il comportamento strano docker build che ho affrontato di recente.

Consideriamo abbiamo una semplice Dockerfile in cui stiamo cercando di copiare alcuni file nella home directory di un utente non-root:

FROM ubuntu:utopic 

ENV DEBIAN_FRONTEND=noninteractive 

RUN sed -i.bak 's/http:\/\/archive.ubuntu.com\/ubuntu\//mirror:\/\/mirrors.ubuntu.com\/mirrors.txt\//g' /etc/apt/sources.list 
RUN echo "deb http://repo.aptly.info/ squeeze main" >> /etc/apt/sources.list.d/_aptly.list 
RUN apt-key adv --keyserver keys.gnupg.net --recv-keys e083a3782a194991 
RUN apt-get update 
RUN apt-get install -y aptly 

RUN useradd -m aptly 
RUN echo aptly:aptly | chpasswd 

USER aptly 
COPY ./.aptly.conf $HOME/.aptly.conf 

COPY ./public.key $HOME/public.key 
COPY ./signing.key $HOME/signing.key 
RUN gpg --import $HOME/public.key $HOME/signing.key 

RUN aptly repo create -comment='MAILPAAS components' -distribution=utopic -component=main mailpaas 
CMD ["/usr/bin/aptly", "api", "serve"] 

Questo è quello che ho quando sto cercando di costruire questa immagine:

...  
    Step 10 : USER aptly 
    ---> Running in 8639f826420b 
    ---> 3242919b2976 
    Removing intermediate container 8639f826420b 
    Step 11 : COPY ./.aptly.conf $HOME/.aptly.conf 
    ---> bbda6e5b92df 
    Removing intermediate container 1313b12ca6c6 
    Step 12 : COPY ./public.key $HOME/public.key 
    ---> 9a701a78d10d 
    Removing intermediate container 3a6e40b8593a 
    Step 13 : COPY ./signing.key $HOME/signing.key 
    ---> 3d4eb847abe8 
    Removing intermediate container 5ed8cf52b810 
    Step 14 : RUN gpg --import $HOME/public.key $HOME/signing.key 
    ---> Running in 6e481ec97f74 
    gpg: directory `/home/aptly/.gnupg' created 
    gpg: new configuration file `/home/aptly/.gnupg/gpg.conf' created 
    gpg: WARNING: options in `/home/aptly/.gnupg/gpg.conf' are not yet active during this run 
    gpg: keyring `/home/aptly/.gnupg/secring.gpg' created 
    gpg: keyring `/home/aptly/.gnupg/pubring.gpg' created 
    gpg: can't open `/home/aptly/public.key': No such file or directory 
    gpg: can't open `/home/aptly/signing.key': No such file or directory 
    gpg: Total number processed: 0 

Sembra vuoto $HOME. Ma perché? Mettere il percorso assoluto alla directory principale invece di $HOME non è molto conveniente.

+2

Non penso che questo sia un bug. $ HOME è normalmente impostato dalla shell in cui credo e non hai una shell all'interno di un Dockerfile. Puoi sempre "ENV HOME/home/aptly" e quindi funzionerà sopra. –

risposta

21

Ecco il problema:

Quando si utilizza la direttiva USER, colpisce l'ID utente utilizzato per avviare nuovi comandi all'interno del contenitore. Così, per esempio, se si esegue questa operazione:

FROM ubuntu:utopic 
RUN useradd -m aptly 
USER aptly 
RUN echo $HOME 

Si ottiene in questo modo:

Step 4 : RUN echo $HOME 
---> Running in a5111bedf057 
/home/aptly 

Poiché i comandi RUN inizia una nuova shell all'interno di un contenitore, che viene modificato dalla precedente direttiva USER.

Quando si utilizza la direttiva COPY, non si avvia un processo all'interno del contenitore e Docker non ha modo di sapere quali (eventuali) variabili d'ambiente verranno esposte da una shell.

La cosa migliore è per entrambi i set ENV HOME /home/aptly nel vostro Dockerfile, che funziona, o organizzare i file in una cartella temporanea e poi:

RUN cp /skeleton/myfile $HOME/myfile 

Inoltre, ricorda che quando si COPY i file in essi saranno di proprietà di root; sarà necessario esplicitamente chown per l'utente appropriato.

+2

'WORKDIR/home/aptly' funziona anche – kev

Problemi correlati