SymfonyアプリのDockerイメージを構築していて、Apacheサーバーにキャッシュおよびログフォルダーへの書き込み権限を与える必要があります

#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

私はこのイメージを構築する場合docker build -t myname/symfony_apps:latest .とで、コンテナを実行しますdocker run -p 8080:80 myname/symfony_apps:latest。Apacheログは、アクセス許可拒否エラーで溢れていますls -a。私が確認した奇妙なことと、アクセス許可は問題ありません。コンテナのbashからchmodを実行すると、Apacheの権限の問題がなくなり、アプリは正常に動作します

状況

dockerfileからのchmodコマンドの実行：権限は変更されましたが、Apacheは依然として権限の拒否について不満を述べています。 コンテナー内でbashを使用してchmodと同じコマンドを実行すると、権限が変更され、アプリが実行されます

任意のアイデア、何か不足していますか、Dockerfileのどこかにrootユーザーを追加する必要がありますか？

同じ問題があり、ディレクトリコンテンツが1つのレイヤで作成され、その権限が他のレイヤで変更された場合、dockerまたはoverlay2にいくつかのバグがあるようです。

回避策として、ソースを一時ディレクトリにコピーできます。

COPY . /src

次に、移動して/var/www/html権限を設定します（1つのRUNコマンドで）。

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

また、GitHub号も作成しました。

DockerでのRUNのデフォルトシェルは/ bin / shであり、これは実際に正しく設定されていないアクセス許可に問題がある場所です。

ただし、簡単に修正するには、代わりに/ bin / bashを使用するように変更できます。ディレクトリリストの前後に注意してください。

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

追加してみてください：

USER root

それは私のために働いた。

この問題はVOLUME、上流のDockerfile内の定義の結果である可能性があります。ボリュームがDockerfileで定義されている場合、COPYまたはADDコマンドを使用してファイルをイメージに直接追加できます。ただし、RUN行は次のようになります。

• dockerfileの現在の時点でのイメージ定義を使用して一時コンテナーを作成します
  • その一時的なコンテナには、あなたまたはDockerfile内で指定された親イメージとして匿名のボリュームがマウントされます
  • 匿名ボリュームは、イメージのコンテンツから初期化されます
• コマンドはコンテナ内で実行されます
  • このRUNコマンド中にディレクトリを一覧表示すると、変更が適用されたことが表示されますが、それらの変更はボリュームに適用されています
• runコマンドが完了すると、Dockerはコンテナへの変更をキャプチャします
  • これらの変更はdocker diff、一時コンテナーを削除しない場合に表示されます（ビルドを実行--rm=falseしてそれらを残すことができます）
  • これらの変更は、一時的なコンテナーファイルシステム内に存在しないため、ボリュームの内容は別個であるため、匿名ボリュームの内容は含まれません。

この動作のため、次のオプションがあります。

1. ファイルを別のディレクトリにコピーして、そこでアクセス許可を変更できます
2. ホストの権限を修正して、それらがそれらの権限とともに直接コピーされるようにすることができます
3. イメージからボリュームを削除するか、アップストリームイメージを取得してボリューム定義を削除するか、ボリューム定義なしでアップストリームイメージの独自のコピーを再構築し、それに基づいてイメージを作成できます。

現在のphp画像内では、ボリュームが削除されているように見えます。これは、オプション3が事実上あることを意味します。

私は次のことを試してみました：

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

そして、それは素晴らしい働きをします。

しかしながら

docker-composeボリュームを介してその実行可能ファイルをオーバーライドすると、execute権限は単純にロールバックされたようなものになります-技術的には元のファイル権限にオーバーライドされます。

chmod a+x yourfile開発モードの修正は、単にホストからのものであり、構成ボリュームのマウント時に継承されます。