尝试以非root用户身份从容器内部写入已装入的卷时出现问题

Question

我正在使用一个将运行ZooKeeper的容器，但是我遇到了关于我装入容器的主机卷的权限问题。

这是我的设置：

在主机上（Ubuntu 14.04）：

• 创建了“zookeeper”系统用户（id = 106）和组（id = 111）。
• 创建目录“/ var / log / zookeeper”并将其所有权设置为zookeeper（即chown zookeeper：zookeeper）。 这是我将安装到容器中的目录。

容器内部（Ubuntu 14.04）：

• 还创建了一个“zookeeper”系统用户（id = 102）和group（id = 105），我将其用作在ENTRYPOINT中执行命令的用户。
• 创建将要挂载的相同目录“/ var / log / zookeeper”，并将其所有权设置为zookeeper：zookeeper（虽然我认为这不重要）。

一旦我使用/ var / log / zookeeper mount启动我的容器，我在容器内部打开一个shell作为zookeeper用户（在容器内创建），我发现我得到一个“Permission Denied”错误，如果我尝试在挂载目录/ var / log / zookeeper中创建一个文件。 当我执行“ls -l”查看此目录的所有权（仍然在容器内）时，它看起来像这样：

drwxr-xr-x 2  106  111   4096 Jun 30 17:18 zookeeper

在这种情况下，106和111对应于主机的zookeeper用户和组ID，我认为这是问题所在。 我尝试在容器内部打开一个shell，但这次我以root用户身份进入，上面描述的场景完全正常，只是root是创建的文件的所有者（这是预期的）。

由此我得出结论，我需要：

（a）在我的容器内运行应用程序作为默认的root用户，而不是我创建的zookeeper用户。

（b）在我的主机上和id完全相同的容器内创建一个zookeeper用户和组。

这两种情况都不理想，因为对于（a） ，以root用户身份运行应用程序可能会产生潜在的安全问题（无论如何我都读过），对于（b） ，要使id匹配到期是非常困难的事实上，他们可能已被其他已创建的用户（您无法控制）使用。

有没有人曾经处理过这样的事情？ 我可能会忽略其他可能的解决方案吗？

Answer 1

据我所知，容器内和主机上的用户ID和组ID应该匹配，以便让主机授予您对共享目录的权限。

Answer 2

查看运行生产和开发容器之间的区别非常重要。 Afaik，如果您的Docker容器以root身份运行，即使在生产中也没有真正的问题。 但是，您永远不应该或者需要安装大量的生产。 如果您想以动物园管理员的身份运行它，请随意这样做。

//编辑：我读的越多，我就越相信在以root身份运行东西时可能存在安全问题，所以最好不要在生产中这样做。

尝试匹配uid和gid的解决方案仅适用于小型/本地项目 - 它确实使其无法移植。 您可以尝试设置任意高的uid和gid ，然后在每台开发机器上执行相同操作，但这并不意味着它总是很好。

tl; dr ： 开发时在现有文件上运行chmod -R 0777 ，然后使用umask 0000来设置稍后创建的文件和目录的权限。 然后，无论用户创建文件，您都可以随意安装和编辑文件。