☰

在基于 Alpine 的 Docker 中，管理已挂载卷的权限的规定方法是什么？

tag-icon • tag-icon permissions mount docker alpine-linux
在基于 Alpine 的 Docker 中，管理已挂载卷的权限的规定方法是什么？

构建映像时，您可以分配所有权 ( chown) 并更改chmod映像内路径的权限 ( )。但是，当从主机或另一个容器挂载卷时，该卷的权限存在，可能会引入挂载该卷的容器所不知道的用户/组。

我对一种规定性方法（如果存在）感兴趣，该方法用于处理 Alpine Docker 镜像下的用户对主机挂载卷和容器挂载卷的权限。

我能想到的两个可能的选择是：

  1. 在容器和已挂载卷之间使用相同的用户和组。
  2. 使用 ACL 来控制权限。

是否有推荐的方法来解决已挂载卷的权限问题，尤其是当所有者的 uid/gid 与容器内的用户/组不匹配时？例如

在我的 Alpine Docker 镜像中，我的www-data用户的 uid/gid 为 82（参见：nginx www-data 用户 ID1001)，如果我从另一个容器或具有 uid和 gid的用户拥有该卷的主机挂载1001该卷，我该如何处理所有权和权限的差异？

注意：一些应用程序框架（例如Symfony）建议使用类似setfacl[1] 来管理权限，但这在具有 AUFS 的 Alpine Docker 映像下似乎是不可能的，因为该操作“不受支持”。

在 Docker 中使用 ACL 是否是一种反模式？

答案1

注意： 堆栈溢出有以下问题：管理docker共享卷权限的最佳方法是什么？这与上述和众多答案类似，其中最流行的答案是一。

通过实验和阅读大量资料来寻找规范性答案或共同模式，我发现了以下内容：

运行 Docker-outside-of-Docker (DooD) 时，主机数据卷从底层主机挂载。我记得在一篇博客文章中偶然看到了一些关于这一点的提及，但现在我无论如何也找不到它了（如果/当我找到它时，我会更新这个答案）。简而言之：当你通过容器docker.sock内的共享运行 Docker 时，Docker 将尝试从潜在的主机。如果您从另一个容器安装卷，则不会出现此问题。

分配权限和所有权。我上面提到的问题（无法setfacl正常工作）似乎是用户问题。我一定是试图在非 root 用户的权限下运行它，或者针对我的用户没有所有权的目录运行它。为了解决所有权问题，您可以使用一个docker-entrypoint.sh脚本，在以图像用户身份执行命令之前，该脚本chown将以setfaclroot 用户的身份运行。到目前为止，我已经确定了两种可行的选项来处理所有权和权限问题：

  • 用于sudo更改所有权或设置访问控制列表。
  • 允许您的容器使用用户运行root，然后降级到另一个用户以使用以下命令执行命令戈苏或者执行命令。

我选择将上述两种观察结果结合起来，形成我的自我指导方法，所以......

  1. 每当在与主机共享的 Docker 容器中安装主机卷时docker.sock，建议目录应匹配。例如，如果 Dockerfile 中的卷安装声明为，则从主机/var/data安装（例如）。尤其是如果您希望在容器内将文件或目录安装到新容器中，则尤其如此。/var/data-v /var/data:/var/data/var/data
  2. 主动考虑权限，始终包含一个docker-entrypoint.sh至少可以更新已挂载目录的所有权或访问控制的文件。

相关内容