chmod nie działa poprawnie w Docker

19

Tworzę obraz Dockera dla mojej Symfonyaplikacji i muszę zezwolić serwerowi Apache na zapisywanie w folderach pamięci podręcznej i dzienników

#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

Kiedy buduję ten obraz docker build -t myname/symfony_apps:latest .i uruchamiam kontener za pomocą docker run -p 8080:80 myname/symfony_apps:latest. Dziennik Apache jest zalany błędami odmowy uprawnień, dziwna rzecz, którą sprawdziłem ls -ai uprawnienia są w porządku. a kiedy uruchamiam chmod z bash kontenera, problemy z uprawnieniami do apache znikają, a aplikacja działa dobrze

Sytuacja

Uruchamianie komend chmod z pliku dockerfile: uprawnienia są zmieniane, ale Apache wciąż narzeka na odmowę dostępu . Uruchamianie chmod tych samych poleceń z bash wewnątrz kontenera: uprawnienia są zmieniane i moja aplikacja jest uruchomiona

Każdy pomysł, czy coś mi brakuje, może powinienem dodać użytkownika root gdzieś w Dockerfile?

burza
źródło
Przydałoby się zobaczyć polecenie dokera uruchamiające wbudowany obraz.
Mike
Widzę dodatkową przestrzeń w twoim ostatnim poleceniu (jestem na telefonie, więc nie jestem pewien). Ponieważ wydaje się, że problem z uprawnieniami dotyczy katalogu dziennika, zmień ostatni wiersz na: `` RUN chmod -R 777 / var / www / html / app / cache / var / www / html / app / logs ``
Mike
1
Ok .. Zredagowałem pytanie :)
burza
ta dodatkowa przestrzeń była literówką
burza
Nie mogę odtworzyć Twojego problemu. Jeśli użyję twojego pliku docker i skonfiguruję lokalnie niektóre fikcyjne pliki, uprawnienia są prawidłowe i wszystko po prostu działa. Mogę uruchomić kontener i uzyskać dostęp do zawartości za pośrednictwem przeglądarki internetowej. Czy możesz zaktualizować swoje pytanie, aby zawierało określone komunikaty o błędach? Czy jesteś pewien, że twoja konfiguracja Apache ( apache2.conf) nie powoduje problemu? Czy błędy znikną, jeśli nie zostaną zainstalowane apache2.conf?
larsks

Odpowiedzi:

16

Miałem ten sam problem i wydaje się, że jest jakiś błąd w oknie dokowanym lub nakładce2, jeśli zawartość katalogu jest tworzona w jednej warstwie, a uprawnienia w drugiej są zmieniane.

Aby obejść ten problem, możesz skopiować źródła do katalogu tymczasowego:

COPY . /src

A następnie przenieś go /var/www/htmli skonfiguruj uprawnienia (jednym RUNpoleceniem):

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

Stworzyłem również problem z GitHub .

mixel
źródło
Tej nocy zamierzałem zagłębić się w mój stary kod źródłowy, aby zobaczyć, jak to rozwiązałem, a potem przypomniałem sobie tę sztuczkę z katalogiem tmp. Mam nadzieję, że nie zajęło ci to dużo czasu na rozwiązanie XD
burza
7

Domyślna powłoka RUN w Dockerze to / bin / sh i właśnie w tym przypadku problem z nieprawidłowymi ustawieniami uprawnień.

Ale możesz zmienić na po prostu użyj / bin / bash, aby łatwo to naprawić, zauważ przed i po liście katalogów

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
Thad Guidry
źródło
2
Dlaczego /bin/bash -c 'chmod +x file'działa a nie /bin/sh -c 'chmod +x file'?
burza
twoje jest lepsze rozwiązanie. zadziałało dla mnie. dzięki .
user1427944
Ponadto korzystanie z nowego zestawu narzędzi pomaga w wielu obszarach, w tym w tym. Spróbuj. docs.docker.com/develop/develop-images/build_enhancements
Thad Guidry
6

Spróbuj dodać:

USER root

To zadziałało dla mnie.

secavfr
źródło
To powinna być zaakceptowana odpowiedź.
Vladimir Kornea
2
Jeśli przełączysz się na root, powinieneś prawdopodobnie powrócić do poprzedniego użytkownika po zakończeniu lub zmniejszeniu bezpieczeństwa i kompatybilności kontenera. Niektóre implementacje Kubernetes domyślnie nie uruchamiają kontenera na przykład jako root.
flickerfly
2

Ten problem jest prawdopodobnie wynikiem VOLUMEdefinicji w głównym pliku Docker. Po zdefiniowaniu woluminu w pliku Docker można dodawać pliki za pomocą polecenia COPYlub ADDbezpośrednio do obrazu. Jednak RUNlinia:

  • Utwórz tymczasowy kontener, używając definicji obrazu od bieżącego punktu pliku dokowania
    • W tym tymczasowym kontenerze będzie zamontowany anonimowy wolumin jako ty lub obraz nadrzędny określony w pliku Docker
    • Anonimowy wolumin zostanie zainicjowany z zawartości obrazu
  • Twoje polecenie uruchomi się w kontenerze
    • Jeśli wymienisz katalog podczas wykonywania tego RUNpolecenia, zobaczysz, że zmiany zostały zastosowane, ale zmiany zostały zastosowane w woluminie
  • Po zakończeniu polecenia uruchamiania doker przechwytuje zmiany w kontenerze
    • Zmiany te można zobaczyć, docker diffjeśli nie usuniesz tymczasowych kontenerów (możesz uruchomić kompilację, --rm=falseaby pozostały)
    • Zmiany te nie będą obejmować anonimowej zawartości woluminu, ponieważ nie istnieją one w tymczasowym systemie plików kontenera, woluminy są osobne

Z powodu tego zachowania masz opcje:

  1. możesz skopiować swoje pliki do innego katalogu i zmienić tam uprawnienia
  2. możesz naprawić uprawnienia na swoim hoście, aby zostały skopiowane bezpośrednio z tymi uprawnieniami
  3. możesz usunąć wolumin ze swojego obrazu, poprosić obraz górny, aby usunął ich definicję wolumenu, lub możesz odbudować własną kopię obrazu górnego bez definicji woluminu i oprzeć na nim swoje obrazy

Zauważ, że wewnątrz obecnych obrazów php wydaje się, że wolumin został usunięty, co oznacza, że ​​faktycznie mamy opcję 3.

BMitch
źródło
0

Właśnie przeprowadziłem eksperyment z następującymi elementami:

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

I to po prostu działa świetnie.

jednak

Kiedy zastępuję ten plik wykonywalny za pomocą woluminów tworzących okno dokowane, executeuprawnienie jest po prostu jak wycofane - technicznie zastępuje pierwotne uprawnienie do pliku.

Poprawką dla trybu deweloperskiego jest po prostu przejście chmod a+x yourfilez hosta, który zostanie odziedziczony po skomponowaniu instalacji woluminu.

Salathiel Genèse
źródło
1
Głównym celem woluminu jest montowanie plików z miejsca innego niż obraz, więc jeśli naprawisz obraz i zamontujesz wolumin nad nim, zgodnie z projektem nie zobaczysz zmian obrazu. W zależności od tego, dlaczego masz wolumin, odpowiedzią może być po prostu brak woluminu.
BMitch
Tak BMitch , całkowicie zgadzam się co do efektu montowania woluminu, który zastępuje fs kontenera z obrazu zbudowanego w oknie dokera , ale ... Podczas programowania z pewnością nie chcesz odbudowywać / restartować kontenera w celu przetestowania każdej zmiany zrobić. W tym ostatnim scenariuszu chcesz zamontować wolumin, który przesłania obraz wbudowany w okno dokowane. I przed tym lądowałem przed tym samym problemem. Nie byłem przekonany ani przez wyjaśnienia odpowiedzi, ani testowałem każdego z nich. Dopiero wtedy zrozumiałem, o co chodzi, i opublikowałem swoje spostrzeżenia ...
Salathiel Genèse,
... i podejrzewam, że scenariusz, którego doświadczyłem, jest taki sam jak ten, który zadał pytanie.
Salathiel Genèse,
OP wskazał, że widzieli problem tylko za pomocą docker runpolecenia i nie podłączono zewnętrznego woluminu.
BMitch
Oups - brakowało mi tego aspektu ... Prawidłowa odpowiedź na właściwy tytuł pytania, ale nie opisany scenariusz. W takim razie mogę wspomnieć, że nie mogłem odtworzyć wyżej wymienionego problemu.
Salathiel Genèse,