我一直在玩Docker一段时间,并在处理持久数据时继续寻找相同的问题.
创建我Dockerfile和暴露量或使用--volumes-from来安装我的容器内的主文件夹.
我应该对主机上的共享卷应用哪些权限？
我可以想到两个选择:
到目前为止,我已经给了每个人读/写访问权限,所以我可以从Docker容器写入该文件夹.
将用户从主机映射到容器,这样我就可以分配更细化的权限.不确定这是可能的,但没有找到太多关于它.到目前为止,我所能做的就是以某个用户身份运行容器:docker run -i -t -user="myuser" postgres但是此用户的UID与我的主机不同myuser,因此权限不起作用.此外,我不确定映射用户是否会带来一些安全风险.
还有其他选择吗？
你们这些人/女士如何应对这个问题？
在docker中,在容器内创建的文件在从主机检查时往往具有不可预测的所有权.默认情况下,卷上文件的所有者是root(uid 0),但只要非root用户帐户涉及容器并写入文件系统,所有者就会从主机角度变得或多或少随机.
当您需要使用调用docker命令的同一用户帐户从主机访问卷数据时,这是一个问题.
典型的解决方法是
docker run作为环境变量传递给命令,然后chown在入口点脚本中的卷上运行某些命令.这两种解决方案都可以控制容器外的实际权限.
我希望用户命名空间是这个问题的最终解决方案.我已经使用最近发布的版本1.10和--userns-remap设置到我的桌面帐户运行了一些测试.但是,我不确定它是否可以使安装卷上的文件所有权更容易处理,我担心它实际上可能正好相反.
假设我启动这个基本容器
docker run -ti -v /data debian:jessie /bin/bash
echo 'hello' > /data/test.txt
exit
然后检查来自主机的内容:
ls -lh /var/lib/docker/100000.100000/volumes/<some-id>/_data/
-rw-r--r-- 1 100000 100000 6 Feb 8 19:43 test.txt
这个数字'100000'是我的主机用户的子UID,但由于它与我的用户的UID不对应,我仍然无法在没有权限的情况下编辑test.txt.此子用户似乎与docker之外的实际常规用户没有任何关联.它没有映射回来.
由于UID->sub-UID名称空间中发生的映射,本文前面提到的由主机和容器之间的UID对齐组成的变通方法不再起作用.
那么,有没有办法在启用用户命名空间的情况下运行docker(为了提高安全性),同时仍然可以让运行docker的主机用户拥有在卷上生成的文件？
docker ×2