Я создаю образ Docker для своего Symfonyприложения, и мне нужно дать разрешение серверу 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и разрешения в порядке. и когда я запускаю chmod из контейнера bash, проблемы с разрешением apache исчезают, и приложение работает хорошо

Ситуация

Выполнение команд chmod из dockerfile: разрешения изменены, но apache по-прежнему жалуется на отказ в доступе . Выполнение одних и тех же команд chmod с bash внутри контейнера: разрешения изменены, и мое приложение работает

Любая идея, я что-то упустил, может быть, я должен добавить пользователя root где-нибудь в Dockerfile?

У меня была та же проблема, и кажется, что есть некоторая ошибка в Docker или Overlay2, если содержимое каталога создается в одном слое, а его разрешения изменяются в другом.

В качестве обходного пути вы можете скопировать исходные коды во временный каталог:

COPY . /src

А затем переместите его /var/www/htmlи настройте права доступа (одной 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 .

Оболочкой по умолчанию для RUN в Docker является / 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команды, вы увидите, что ваши изменения применены, но эти изменения были применены к тому
• Когда ваша команда запуска завершится, 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разрешение просто откатывается - технически переопределяется на исходное разрешение файла.

Исправление для режима dev - это просто chmod a+x yourfileот хоста, который будет наследоваться при монтировании тома.