Конфигурирование контейнера docker для использования UID хоста и генерации файлов в хост-системе - желательно во время выполнения - PullRequest
0 голосов
/ 25 января 2020

В настоящее время я работаю над исследовательским инструментом, который должен быть упакован с использованием docker, который, мы надеемся, будет работать на как можно большем количестве различных систем. По большей части это работает нормально, у нас возникла проблема с правами доступа из-за рабочего процесса: инструмент берет входной файл (который мы монтируем в контейнер), оценивает его с помощью сценариев R и затем должен сгенерировать отчет о входной файл точно, откуда файл был взят из хост-системы.

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

Я нашел различные решения, которые включают передачу UID / GID демону docker при построении контейнера тем или иным способом:

docker build --build-arg USER_ID=$(id -u ${USER}) --build-arg GROUP_ID=$(id -g ${USER}) -t IMAGE .

Я также изменил файл docker соответственно, используя руководство который предложил заменить внутреннего www-data пользователя:

[...Package installation steps that are supposed to be run as root...]

ARG USER_ID
ARG GROUP_ID

RUN if [ ${USER_ID:-0} -ne 0 ] && [ ${GROUP_ID:-0} -ne 0 ]; then \
    userdel -f www-data &&\
    if getent group www-data ; then groupdel www-data; fi &&\
    groupadd -g ${GROUP_ID} www-data &&\
    useradd -l -u ${USER_ID} -g www-data www-data &&\
    install -d -m 0755 -o www-data -g www-data /work/ &&\
    chown --changes --silent --no-dereference --recursive \
          --from=33:33 ${USER_ID}:${GROUP_ID} \
      /work \
;fi

USER www-data

WORKDIR     /work
RUN     mkdir files

COPY            data/ /opt/MTB/data/
COPY        helpers/ /opt/MTB/helpers/
COPY        src/www/ /opt/MTB/www/
COPY        tmp/ /opt/MTB/tmp/
COPY        example_data/ /opt/MTB/example_data/
COPY        src/ /opt/MTB/src/

EXPOSE      8080

ENTRYPOINT      ["/opt/MTB/src/starter_s_c.sh"]

Сценарий точки входа starter_s_c.sh представляет собой небольшой bashscript, который передает конечный аргумент в соответствующий R-скрипт в качестве входного файла - R-скрипт пишет отчет .

Это работает, но требует повторной сборки контейнера для каждого нового пользователя. То, что мы ищем, - это решение, которое обрабатывает динамические настройки разрешений c во время выполнения, так что нам нужно создать контейнер только один раз и использовать его со многими различными пользовательскими конфигурациями.

Я обнаружил this , но я не совсем уверен, как его реализовать, поскольку он заменит наш скрипт точки входа, и я не уверен, как интегрировать это решение в наш проект.

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

#!/bin/sh
file="$1"
cd $(dirname $0)/..
if [ $# -eq 0 ]; then
    echo '.libPaths(c("~/lib/R/library", .libPaths())); library(shiny); library(shinyjs); runApp("src")' | R --vanilla 
else
    echo "Rscript --vanilla /opt/MTB/src/localmaster.r "$file"" 
    Rscript --vanilla /opt/MTB/src/localmaster.r "$file"
fi

(Если аргументы не указаны, запускается блестящее приложение, просто чтобы избежать путаницы)

Любая помощь или советы будут высоко оценены! Спасибо.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...