Je crée une image Docker pour mon Symfonyapplication et je dois autoriser le serveur Apache à écrire dans les dossiers de cache et de journal

#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

Lorsque je crée cette image avec docker build -t myname/symfony_apps:latest .et exécute le conteneur avec docker run -p 8080:80 myname/symfony_apps:latest. Le journal Apache est inondé d'erreurs d'autorisation refusée, la chose étrange avec laquelle j'ai vérifié ls -aet les autorisations sont très bien. et quand j'exécute chmod depuis bash du conteneur, les problèmes d'autorisation apache ont disparu et l'application fonctionne bien

La situation

Exécution des commandes chmod à partir de dockerfile: les autorisations sont modifiées mais apache se plaint toujours de l'autorisation refusée. Exécution de mêmes commandes chmod avec bash à l'intérieur du conteneur: les autorisations sont modifiées et mon application est en cours d'exécution

Une idée, est-ce que je manque quelque chose, peut-être devrais-je ajouter un utilisateur root quelque part dans le Dockerfile?

J'ai eu le même problème et il semble qu'il y ait un bug dans docker ou overlay2 si le contenu du répertoire est créé dans une couche et ses autorisations sont modifiées dans l'autre.

Pour contourner ce problème, vous pouvez copier les sources dans un répertoire temporaire:

COPY . /src

Ensuite, déplacez-le /var/www/htmlet configurez les autorisations (dans une seule RUNcommande):

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

J'ai également créé le problème GitHub .

Le shell par défaut de RUN dans Docker est / bin / sh et c'est là que les autorisations qui ne sont pas définies correctement ont réellement un problème.

Mais vous pouvez changer pour utiliser simplement / bin / bash à la place pour facilement corriger, remarquer avant et après la liste des répertoires

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

Essayez d'ajouter:

USER root

Ça a marché pour moi.

Ce problème est probablement le résultat d'une VOLUMEdéfinition à l'intérieur du Dockerfile en amont. Lorsqu'un volume est défini dans le Dockerfile, vous pouvez ajouter des fichiers avec une commande COPYou ADDdirectement dans l'image. Cependant, une RUNligne:

• Créer un conteneur temporaire en utilisant la définition d'image à partir du point actuel du dockerfile
  • Ce conteneur temporaire aura un volume anonyme monté comme vous ou une image parent spécifiée dans le Dockerfile
  • Le volume anonyme sera initialisé à partir du contenu de l'image
• Votre commande s'exécutera à l'intérieur du conteneur
  • Si vous répertoriez le répertoire au cours de cette RUNcommande, vous verrez vos modifications appliquées, mais ces modifications ont été appliquées au volume
• Lorsque votre commande d'exécution se termine, docker capture les modifications apportées au conteneur
  • Ces modifications sont visibles avec un docker diffsi vous ne supprimez pas les conteneurs temporaires (vous pouvez exécuter une génération avec --rm=falsepour les conserver)
  • Ces modifications n'incluront pas le contenu du volume anonyme car elles n'existent pas à l'intérieur du système de fichiers du conteneur temporaire, les volumes sont séparés

En raison de ce comportement, vous avez les options suivantes:

1. vous pouvez copier vos fichiers dans un autre répertoire et y modifier les autorisations
2. vous pouvez fixer les autorisations sur votre hôte afin qu'il soit copié directement avec ces autorisations
3. vous pouvez supprimer le volume de votre image, obtenir l'image en amont pour supprimer leur définition de volume, ou vous pouvez reconstruire votre propre copie de l'image en amont sans la définition du volume et baser vos images sur celle-ci

Notez qu'à l'intérieur des images php actuelles, il semble que le volume a été supprimé, ce qui signifie que nous avons effectivement l'option 3.

Je viens de faire une expérience avec les éléments suivants:

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

Et cela fonctionne très bien.

pourtant

Lorsque je remplace ce fichier exécutable via des volumes de composition de docker, l' executeautorisation est tout simplement comme annulée - techniquement remplacée par l'autorisation de fichier d'origine.

Le correctif pour le mode dev est simplement chmod a+x yourfilede l'hôte, qui sera hérité lors du montage du volume de composition.