Sto creando un'immagine Docker per la mia Symfonyapp e devo autorizzare il server Apache a scrivere nella cache e nelle cartelle di registro

#Dockerfile
FROM php:7-apache

RUN apt-get update \
&& apt-get install -y libicu-dev  freetds-common freetds-bin unixodbc \
&& docker-php-ext-install intl mbstring \
&& a2enmod rewrite

COPY app/php.ini /usr/local/etc/php/
COPY app/apache2.conf /etc/apache2/apache2.conf
COPY ./ /var/www/html

RUN find /var/www/html/ -type d -exec chmod 755 {} \; 
RUN find /var/www/html/ -type f -exec chmod 644 {} \;
RUN chmod -R 777 /var/www/html/app/cache /var/www/html/app/logs

Quando creo questa immagine con docker build -t myname/symfony_apps:latest .ed eseguo il contenitore con docker run -p 8080:80 myname/symfony_apps:latest. Il registro di Apache è inondato da errori di autorizzazione negata, la cosa strana con cui ho verificato ls -ae le autorizzazioni vanno bene. e quando eseguo chmod dalla bash del container, i problemi di autorizzazione di apache scompaiono e l'app funziona bene

La situazione

Esecuzione dei comandi chmod da dockerfile: le autorizzazioni vengono modificate ma Apache si lamenta ancora delle autorizzazioni negate. Esecuzione di chmod stessi comandi con bash all'interno del contenitore: le autorizzazioni vengono modificate e la mia app è in esecuzione

Qualche idea, mi sto perdendo qualcosa, forse dovrei aggiungere l'utente root da qualche parte nel Dockerfile?

Ho avuto lo stesso problema e sembra che ci sia qualche bug nella finestra mobile o overlay2 se il contenuto della directory viene creato in un livello e le sue autorizzazioni vengono modificate in un altro.

Per ovviare al problema, è possibile copiare le fonti nella directory temporanea:

COPY . /src

E poi spostalo su /var/www/htmle imposta i permessi (in un solo RUNcomando):

RUN rm -rf /var/www/html && mv /src /var/www/html &&\
    find /var/www/html/ -type d -exec chmod 755 {} \; &&\
    find /var/www/html/ -type f -exec chmod 644 {} \; &&\
    chmod -R 777 /var/www/html/app/cache /var/www/html/app/logs

Inoltre ho creato il problema GitHub .

La shell predefinita di RUN in Docker è / bin / sh ed è qui che le autorizzazioni non impostate correttamente hanno effettivamente un problema.

Ma puoi cambiare semplicemente usando / bin / bash invece di aggiustarlo facilmente, notando l'elenco delle directory prima e dopo

Step 7/9 : RUN /bin/bash -c 'ls -la; chmod +x gitlab-properties-builder.sh; ls -la'
---> Running in dc57ae77aa67

drwxr-xr-x. 3 root root      103 Mar  8 17:56 .
drwxr-xr-x. 1 root root       46 Mar  8 17:57 ..
drwxr-xr-x. 2 root root        6 Mar  7 20:47 config
-rw-r--r--. 1 root root     2340 Mar  7 21:20 gitlab-properties-builder.sh
-rw-r--r--. 5 root root 57325770 Mar  5 14:39 gitlab-scm-collector-2.0.5-SNAPSHOT.jar

drwxr-xr-x. 1 root root       42 Mar  8 17:56 .
drwxr-xr-x. 1 root root       61 Mar  8 17:57 ..
drwxr-xr-x. 2 root root        6 Mar  7 20:47 config
-rwxr-xr-x. 1 root root     2340 Mar  7 21:20 gitlab-properties-builder.sh
-rw-r--r--. 5 root root 57325770 Mar  5 14:39 gitlab-scm-collector-2.0.5-SNAPSHOT.jar
---> 8b5de6e348d3

Prova ad aggiungere:

USER root

Ha funzionato per me.

Questo problema è probabilmente il risultato di una VOLUMEdefinizione all'interno del Dockerfile upstream. Quando un volume è definito nel Dockerfile, è possibile aggiungere file con un comando COPYo ADDdirettamente nell'immagine. Tuttavia, una RUNriga:

• Creare un contenitore temporaneo usando la definizione dell'immagine a partire dal punto corrente del file docker
  • Quel contenitore temporaneo avrà un volume anonimo montato come te o un'immagine principale specificata nel Dockerfile
  • Il volume anonimo verrà inizializzato dal contenuto dell'immagine
• Il tuo comando verrà eseguito all'interno del contenitore
  • Se si elenca la directory durante questo RUNcomando, verranno visualizzate le modifiche applicate, ma tali modifiche sono state applicate al volume
• Al termine del comando di esecuzione, la finestra mobile acquisirà le modifiche nel contenitore
  • Queste modifiche possono essere visualizzate con un docker diffse non si eliminano i contenitori temporanei (è possibile eseguire una build con --rm=falseper farli rimanere)
  • Queste modifiche non includeranno i contenuti del volume anonimo perché non esistono all'interno del filesystem contenitore temporaneo, i volumi sono separati

A causa di questo comportamento, hai la possibilità di:

1. puoi copiare i tuoi file in un'altra directory e modificare le autorizzazioni lì
2. puoi correggere le autorizzazioni sul tuo host in modo che vengano copiate direttamente con quelle autorizzazioni
3. puoi rimuovere il volume dall'immagine, ottenere l'immagine a monte per rimuovere la definizione del volume, oppure puoi ricostruire la tua copia dell'immagine a monte senza la definizione del volume e basare le tue immagini su di essa

Si noti che all'interno delle attuali immagini php, sembra che il volume sia stato rimosso, il che significa che abbiamo effettivamente l'opzione 3.

Ho appena fatto un esperimento con il seguente:

FROM alpine

LABEL MAINTAINER="YIMGA YIMGA Salathiel Genèse"
RUN apk add --no-cache inotify-tools
CMD [ "./script.sh" ]
WORKDIR /opt/app/
COPY src/ /opt/app/
RUN chmod a+x *.sh

E funziona alla grande.

tuttavia

Quando eseguo l'override di quel file eseguibile tramite volumi comporre docker, l' executeautorizzazione è semplicemente come ripristinata - tecnicamente ignora l'autorizzazione del file originale.

La correzione per la modalità dev è semplicemente chmod a+x yourfiledall'host, che verrà ereditato al montaggio del volume di composizione.