Разрешение изменено на 1000 на локальном хосте после контейнера Docker с созданным томом - PullRequest
0 голосов
/ 15 марта 2019

После того, как мой контейнер создан с внешним томом, Разрешение становится 1000.

drwxr-x --- 7 1000 1000 4096 02 марта 01:13 my_domain

Каждый раз, когда мне нужно изменить это мой пользователь. Докер AS устанавливается пользователем root. Как я могу избежать этой ситуации? Может кто-нибудь написать что-нибудь?

Ответы [ 2 ]

0 голосов
/ 15 марта 2019

С томами хоста докера вы увидите UID пользователя внутри контейнера, используемого для чтения и записи файлов на хосте, нет перевода UID / GID между контейнером и хостом (это не является функцией linux bind)крепления).Существуют различные обходные пути, в том числе:

  • Просто позволяя контейнеру записывать файлы как разные uid / gid.Это может дать доступ случайным пользователям на хосте к данным контейнера и может привести к ошибкам записи, если каталог хоста не имеет доступа к записи для пользователя контейнера.
  • Изменить uid пользователя, созданного внутриобраз.Это приводит к тому, что для каждого хоста будет использоваться другой образ, на котором вы хотите работать с монтируемыми хостами.
  • Измените uid во время выполнения с чем-то вроде флага -u на docker run.Это может привести к тому, что файлы внутри изображения станут недоступными, а uid внутри контейнера не будет соответствовать файлу / etc / passwd внутри контейнера.

Мое личное решение - динамически изменять пользователя внутриКонтейнер с точкой входа, которая начинается как root и сравнивает uid пользователя контейнера с uid монтирования тома.Когда они различаются, я изменяю uid пользователя в контейнере и рекурсивно исправляю любые файлы, все еще принадлежащие старому uid из изображения.Ключевой частью этой подпрограммы является сценарий исправления ошибок в моем репозитории базовых образов.Вы можете увидеть это вместе с примером того, как изменить существующие образы, чтобы использовать его здесь: https://github.com/sudo-bmitch/docker-base/ (fix-perms находится в bin / fix-perms).

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

0 голосов
/ 15 марта 2019

Не изменяйте его на пользователя с другим UID. Разрешение может быть изменено самим контейнером при запуске. вам может понадобиться просмотреть образ докера, который вы используете в этом случае.

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

Основываясь на теге weblogic12c в вашем вопросе, я заметил следующее в Dockerfile weblogic:

RUN  chown oracle:oracle -R /u01

Если ваши данные сохраняются в контейнере в том же каталоге, то, вероятно, 1000 представляет oracle пользователя внутри контейнера, вы также можете проверить /etc/passwd внутри контейнера.

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

useradd -U -u 1000 oracle

Приведенная выше команда создаст пользователя с именем oracle и группу с тем же именем из-за использования -U, а UID / GID будет 1000 из-за использования -u

  -u, --uid UID                 user ID of the new account
  -U, --user-group              create a group with the same name as the user

Далее, если вы выполнили следующую команду на хосте, вы получите результат, который сообщит вам группу пользователей и uid / gid:

id oracle
uid=1000(oracle) gid=1000(oracle) groups=1000(oracle)
...