管理Docker共享卷权限的（最佳）方法是什么？

Question

我使用Docker已经有一段时间了，并且在处理持久数据时不断发现相同的问题。

我创建DockerFile并公开卷，或者使用--Volumes-From在容器中装入主机文件夹。

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

我能想到两个选择：

>

到目前为止，我已经为每个人提供了读/写访问权限，因此我可以从Docker容器写入文件夹。

将用户从主机映射到容器中，这样我就可以分配更多的粒度权限。不确定这是可能的，但还没有找到很多关于它。到目前为止，我所能做的只是以某个用户的身份运行容器:docker run-i-t-user=“MyUser”postgres，但是这个用户的UID与我的主机MyUser不同，所以权限不起作用。此外，我不确定映射用户是否会带来一些安全风险。

还有其他选择吗？

你们是怎么处理这个问题的？

Answer 1

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

我相信解决这一问题的规范方法是使用仅有数据的容器。使用这种方法，对卷数据的所有访问都是通过使用-volumes-from数据容器的容器进行的，因此主机UID/GID并不重要。

例如，文档中给出的一个用例是备份数据卷。为此，将使用另一个容器通过tar执行备份，它还使用-volumes-from来装入卷。因此，我认为关键在于：与其考虑如何以适当的权限访问主机上的数据，不如考虑如何通过另一个容器来完成所需的操作--备份、浏览等。容器本身需要使用一致的UID/GID，但它们不需要映射到主机上的任何东西，从而保持可移植性。

这对我来说也是比较新的，但如果您有一个特定的用例，请随意评论，我会尝试扩展答案。

更新：对于注释中的给定用例，您可能有一个imagesome/graphite来运行graphite，并有一个imagesome/graphiteData作为数据容器。因此，忽略端口等，imageSome/GraphiteData的DockerFile类似于：

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

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/graphite或some/graphiteData来解决这个问题，或者不创建新的映像，而是重用现有的映像之一（根据需要重写entrypoint/cmd）。

现在，您只需运行：

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

然后vi/data/graphite/whatever.txt。这可以很好地工作，因为所有容器都具有相同的graphite用户，并且具有匹配的UID/GID。

因为您从不从主机装入/data/graphite，所以您不关心主机UID/GID如何映射到graphite和graphiteTools容器中定义的UID/GID。那些容器现在可以部署到任何主机上，它们将继续完美地工作。

简单的一点是，graphiteTools可以包含各种有用的实用程序和脚本，您现在也可以以可移植的方式部署这些实用程序和脚本。

更新2：写完这个答案后，我决定写一篇关于这个方法的更完整的博文。希望有帮助。

更新3：我修正了这个答案，并添加了更多的细节。它以前包含了一些关于所有权和perms的错误假设--所有权通常在卷创建时分配，即在数据容器中分配，因为那是创建卷的时候。看这个博客。但这不是一个要求--您只需将数据容器用作“引用/句柄”，并通过入口点中的chown在另一个容器中设置所有权/perms，入口点以gosu结尾，以正确的用户身份运行命令。如果有人对这种方法感兴趣，请发表评论，我可以提供使用这种方法的示例链接。