解决数据卷root权限问题的Docker科研向实践思路

Docker好处多多。对用户，最大程度解决环境配置时权限困扰；对运维，方便控制资源分配调度。Docker的科研常用方法为每个用户自行创建容器，代码数据分离，数据以数据卷（Volume）的形式从宿主机（Host）挂载到工作的容器（Container）中。然而，实践中常发现宿主机视角下数据卷中文件权限被设置为root导致无法导出共享。这里分享一个实践思路来规避这个问题。

问题成因

问题在于容器使用者常以root身份进行以下操作

1. 从镜像出发启动（run）一个容器
2. 在容器内向数据卷写入文件

如此这般，容器内视角看数据卷以及写入文件的权限便被抬至root。然而，容器和宿主机共享同一个Linux内核，Linux管理文件权限使用的是uid和gid，因此，宿主机视角下数据卷及其文件的读写权限也被设置为容器内root的uid和gid。更进一步，宿主机视角下root的uid和gid与容器内root的uid与gid相同。于是宿主机下数据卷及其文件的读写权限也被抬到了root

解决思路

总体思路

使数据卷及其内容的所有者的uid和gid在容器和宿主机上保持同步

已有方案的缺陷

已有方案为在使用命令docker run时使用-u和-g传入指定uid与gid，于此同时使用-v指定数据卷挂载。然而，使用该方案，进入容器时会提示I have no name!,且除数据卷外没有任何权限。这是因为在容器视角下-u和-g并没有相对应的用户。这不利于进一步运用容器开展科研工作。

改进方案

使用dockerfile构建”用户态“镜像。基于基础镜像，在镜像内创建与宿主机用户uid与gid相同的用户和对应工作目录，定制该用户专属的镜像。下为例子：

FROM slicer/conda_maven:v1.2
ARG UID=1001
ARG GID=1002
ARG UNAME=user
RUN groupadd -g $GID -o $UNAME
RUN useradd -m -u $UID -g $GID -o -s /bin/bash -d /home/${UNAME} ${UNAME}
USER ${UNAME}
WORKDIR /home/${UNAME}
CMD /bin/bash
1
2
3
4
5
6
7
8
9

解释：基础镜像为slicer/conda_maven:v1.2（作者自制），UID和GID分别为作者账号在服务器上的uid和gid。UNAME是作者自定义的docker中的用户名（与宿主机无关。宿主机和容器只共享uid和gid，不共享用户名。只要两个id相同，用户名起什么都行）。第一行RUN为创建gid用户组，第二行RUN为创建uid用户及其工作目录。USER指定该镜像默认启动用户（可在docker run时被覆盖），WORKDIR指定该镜像默认启动工作目录（可在docker run时被覆盖），CMD为该镜像默认启动命令（可在docker run时被覆盖）

接下来，在作者的服务器账户内构建(build)镜像，并依据自身需求（端口映射，数据卷挂载）等启动该镜像即可。如有sudo方面需求，还可以root身份登陆容器，并将作者创建的用户加入sudo用户组。