В настоящее время я работаю над исследовательским инструментом, который должен быть упакован с использованием 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
(Если аргументы не указаны, запускается блестящее приложение, просто чтобы избежать путаницы)
Любая помощь или советы будут высоко оценены! Спасибо.