一尘不染

管理Docker共享卷权限的(最佳)方法是什么?

docker

我已经和Docker玩了一段时间,在处理持久性数据时继续寻找相同的问题。

我创建我的文件Dockerfile公开一个卷,或使用--volumes-from它[在容器中安装主机文件夹]。

我应该对主机上的共享卷应用什么权限?

我可以想到两种选择:

  • 到目前为止,我已经授予所有人读取/写入访问权限,因此我可以从Docker容器写入该文件夹。

  • 将用户从主机映射到容器,以便我可以分配更多的细化权限。不确定这是否可能,但尚未找到很多相关信息。到目前为止,我只能以某些用户身份运行容器:docker run -i -t -user="myuser" postgres,但是该用户的UID与主机不同myuser,因此权限不起作用。另外,我不确定映射用户是否会带来一些安全风险。

还有其他选择吗?

你们如何处理这个问题?


阅读 294

收藏
2020-06-17

共1个答案

一尘不染

更新2016-03-02 :从Docker
1.9.0开始,Docker已命名卷替换仅数据容器。在我
如何思考docker内部的数据 的意义上,下面的答案以及我的链接博客文章仍然有价值,但是可以考虑使用命名卷而不是数据容器来实现下面描述的模式。


我相信解决这一问题的规范方法是使用仅数据容器。通过这种方法,所有对卷数据的访问都是通过使用-volumes- from数据容器的容器进行的,因此主机uid / gid无关紧要。

例如,文档中给出的一个用例是备份数据量。为此,另一个容器用于通过进行备份tar,它也用于-volumes- from装载卷。因此,我认为grok的关键点在于:与其考虑如何通过适当的权限访问主机上的数据,不如考虑如何通过另一个容器来执行所需的任何操作(备份,浏览等)。
。容器本身需要使用一致的uid / gids,但它们不需要映射到主机上的任何内容,从而保持可移植性。

对于我来说,这也是相对较新的,但是如果您有特定的用例,请随时发表评论,我将尝试扩展答案。

更新
:对于注释中的给定用例,您可能有一个some/graphite运行石墨的图像,以及一个some/graphitedata作为数据容器的图像。因此,忽略端口等,Dockerfile映像some/graphitedata的类似于:

FROM debian:jessie
# add our user and group first to make sure their IDs get assigned consistently, regardless of other deps added later
RUN groupadd -r graphite \
  && useradd -r -g graphite graphite
RUN mkdir -p /data/graphite \
  && chown -R graphite:graphite /data/graphite
VOLUME /data/graphite
USER graphite
CMD ["echo", "Data container for graphite"]

构建和创建数据容器:

docker build -t some/graphitedata Dockerfile
docker run --name graphitedata some/graphitedata

some/graphiteDockerfile也应该得到相同的UID /导报,因此它可能是这个样子:

FROM debian:jessie
# add our user and group first to make sure their IDs get assigned consistently, regardless of other deps added later
RUN groupadd -r graphite \
  && useradd -r -g graphite graphite
# ... graphite installation ...
VOLUME /data/graphite
USER graphite
CMD ["/bin/graphite"]

它将如下运行:

docker run --volumes-from=graphitedata some/graphite

好的,现在这为我们的石墨容器和关联的仅数据容器提供了正确的用户/组(请注意,您也可以将some/graphite容器重新用于数据容器,在运行时覆盖entrypoing
/ cmd,但是将它们作为IMO更加清晰)。

现在,假设您要编辑数据文件夹中的内容。因此,与其将卷绑定到主机上并在其上进行编辑,不如创建一个新容器来完成该工作。叫它吧some/graphitetools。让我们也创建适当的用户/组,就像some/graphite图像一样。

FROM debian:jessie
# add our user and group first to make sure their IDs get assigned consistently, regardless of other deps added later
RUN groupadd -r graphite \
  && useradd -r -g graphite graphite
VOLUME /data/graphite
USER graphite
CMD ["/bin/bash"]

您可以通过从Dockerfile 继承some/graphitesome/graphitedata在Dockerfile中进行此DRY
,或者代替重新创建新映像,而仅重用现有映像之一(必要时覆盖entrypoint / cmd)。

现在,您只需运行:

docker run -ti --rm --volumes-from=graphitedata some/graphitetools

然后vi /data/graphite/whatever.txt。这非常有效,因为所有容器的石墨用户都相同,并且具有匹配的uid / gid。

由于您从未/data/graphite从主机上进行挂载,因此无需关心主机uid /
gid如何映射到graphitegraphitetools容器中定义的uid / gid
。这些容器现在可以部署到任何主机,并且它们将继续正常运行。

这样做的好处是,它graphitetools可能具有各种有用的实用程序和脚本,您现在也可以以可移植的方式进行部署。

更新2 :写完这个答案后,我决定写一篇关于此方法的更完整的博客文章。希望对您有所帮助。

更新3 :我更正了此答案,并添加了更多细节。它先前包含有关所有权和权限的一些错误假设-
所有权通常是在卷创建时即在数据容器中分配的,因为这是在创建卷时分配的。请参阅此博客。不过,这不是必须的-
您可以仅将数据容器用作“引用/句柄”,并通过入口处的chown在另一个容器中设置所有权/权限,最后以gosu身份以正确的用户身份运行命令。如果有人对此方法感兴趣,请发表评论,我可以提供使用该方法的示例链接。

2020-06-17