Блог

Главная - Вопросы по программированию - Как вы предоставляете некорневые разрешения при создании тома с помощью docker compose?

Как вы предоставляете некорневые разрешения при создании тома с помощью docker compose?

#docker #docker-compose #volume #user-permissions #write

#докер #docker-compose #docker-volume #пользовательские разрешения

Вопрос:

Я использую Docker Desktop с WSL2, и у меня возникли проблемы с тем фактом, что некоторые из моих контейнеров, использующих некорневого пользователя, не могут создать или вставить файл в том.

Кажется, что при создании тома с docker-compose помощью, он автоматически предоставляет ему право собственности root.

Есть ли способ изменить разрешения тома или разрешить пользователю, не являющемуся пользователем root, записывать в него?

Версия Docker ниже:

 Client: Docker Engine - Community
 Cloud integration: 1.0.2
 Version:           19.03.13
 API version:       1.40
 Go version:        go1.13.15
 Git commit:        4484c46d9d
 Built:             Wed Sep 16 17:00:27 2020
 OS/Arch:           windows/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.13
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.13.15
  Git commit:       4484c46d9d
  Built:            Wed Sep 16 17:07:04 2020
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.3.7
  GitCommit:        8fba4e9a7d01810a393d5d25a3621dc101981175
 runc:
  Version:          1.0.0-rc10
  GitCommit:        dc9208a3303feef5b3839f4323d9beb36df0a9dd
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

Комментарии:

1. Вы должны установить правильный идентификатор владельца, идентификатор группы для подключенного тома извне контейнера. Например, если ваш аргумент mount равен: -v /external/folder:/container/internal/folder , и UID , GID пользователя контейнера 1000 , тогда вам нужно запустить sudo chown -R 1000:1000 /etxternal/folder

2. Это верно для привязки, но это не верно для томов Docker. Подробности см. В моем ответе.

Ответ №1:

Если вы создаете привязку, например:

 version: "3"

services:
  example:
    image: myimage
    volumes:
      - ./host/path:/container/path

Тогда каталог в контейнере будет иметь любые права собственности и разрешения, которые у каталога есть в файловой системе вашего хоста. Как указывает @rzlvmp в комментарии, вы можете настроить разрешения каталога по мере необходимости в соответствии с требованиями вашего контейнера.

Если вы подключаете именованный том:

 version: "3"

services:
  example:
    image: myimage
    volumes:
      - myvolume:/container/path

volumes:
  myvolume:

Том будет наследовать разрешения целевого каталога в контейнере. Если ваш образ был создан из Dockerfile файла, который включает что-то вроде:

 RUN useradd myuser; mkdir -p /container/path; chown myuser /container/path

Тогда каталог в запущенном контейнере будет выглядеть так:

 root@d268cf1fcd7c:/# ls -ld /container/path
drwxr-xr-x. 2 myuser root 6 May 23 03:42 /container/path

Из вышесказанного вы можете видеть, что использование именованных томов будет самым простым способом управления хранилищем: вы получаете каталог с соответствующими разрешениями, не требуя каких-либо специальных сценариев инициализации или каких-либо повышенных привилегий в контейнере.

Если вы находитесь в редкой ситуации, когда именованный том не подходит, одним из вариантов является включение ENTRYPOINT сценария, запускаемого как root , который гарантирует правильные разрешения для ваших каталогов перед выполнением основной команды от имени непривилегированного пользователя. То есть создайте Dockerfile , который включает:

 COPY entrypoint.sh /entrypoint.sh
ENTRYPOINT ["sh", "/entrypoint.sh"]

И в entrypoint.sh :

 #!/bin/sh

chown -R myuser /container/path

exec runuser -u nonrootuser "$@"

Это работает, но для изменения разрешений требуется, чтобы ваш контейнер запускался от имени root (и если вы работаете с существующим образом, это требует, чтобы вы учитывали любой существующий сценарий точки входа).

Метки: