譬如:
docker run -d -v /path/web:/var/www nginx_name
就会出现 volume 权限问题,而 Dockerfile 中的
RUN chown -R nobody:nobody /path
则仅仅在构建的时候生效,或者说,在 -v 挂载 volume 后,就无效了,/path 的权限变为 host 的目录权限。
最恼人的是,各发行版 nobody 、 nginx 等的 UID GID 是不同的数字。就是说,我不能在 ENTRYPOINT 中通过 chown -R nobody:nobody
来解决。
网上搜索了一圈,发现一个 ENTRYPOINT 脚本,
TARGET_GID=$(stat -c "%g" /volume/FOOBAR)
EXISTS=$(cat /etc/group | grep $TARGET_GID | wc -l)
# Create new group using target GID and add nobody user
if [ $EXISTS == "0" ]; then
groupadd -g $TARGET_GID tempgroup
usermod -a -G tempgroup nobody
else
# GID exists, find group name and add
GROUP=$(getent group $TARGET_GID | cut -d: -f1)
usermod -a -G $GROUP nobody
fi
目的很简单,检查挂载 volume 的 GID ,如果不存在,则新建个相同 GID 的 tempgroup ,再加个用户到 tempgroup ;如果 GID 存在,则将 nobody 添加到该 GID 组中。
只不过容器构建的时候出错,提示 usermod groupadd 等命令找不到。况且,该脚本的逻辑本身存在问题,譬如如果 GID 99 能匹配到 GID 999 。
我现在是暴力的在 docker run 中直接运行 chown 命令
大家又是如何优雅的解决这个问题的?
1
JavaFirstMaster 2018-07-17 15:39:16 +08:00
我们跨时空遇到了相同的问题.苦恼
|
2
Bardon OP @JavaFirstMaster 呃,我已经解决了,写一个 entrypoint.sh 脚本,在 ENTRYPOINT 中执行
设置 UID GID 变量,通过 stat -c %u /path/volume 和 stat -c %u /home/volume 来检查 volume 的 uid 与 gid,然后与 UID GID 变量来比对,进而进行 volume 权限的设置。 |
3
Bardon OP |
4
sprite0616 2019-04-03 16:14:42 +08:00
我日,发布镜像的这些人是怎么用的。
|