阅读量:1
Docker好处多多。对用户，最大程度解决环境配置时权限困扰；对运维，方便控制资源分配调度。Docker的科研常用方法为每个用户自行创建容器，代码数据分离，数据以数据卷（Volume）的形式从宿主机（Host）挂载到工作的容器（Container）中。然而，实践中常发现宿主机视角下数据卷中文件权限被设置为root导致无法导出共享。这里分享一个实践思路来规避这个问题。
问题成因
问题在于容器使用者常以root身份进行以下操作
- 从镜像出发启动（run）一个容器
- 在容器内向数据卷写入文件
如此这般，容器内视角看数据卷以及写入文件的权限便被抬至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 解释：基础镜像为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用户组。
