尝试以非root用户的身份从容器内写入已装入的卷时出现问题
我正在使用一个将运行ZooKeeper的容器，但是我遇到了有关在我的容器中安装的主机卷的权限问题。
这是我的设置：
在主机上（Ubuntu 14.04）：
- 创build一个“zookeeper”系统用户（id = 106）和组（id = 111）。
- 创build目录“/ var / log / zookeeper”并将其所有权设置为zookeeper（即chown zookeeper：zookeeper）。 这是我要装入我的容器的目录。
在容器内部（Ubuntu 14.04）：
- 还创build了一个“zookeeper”系统用户（id = 102）和group（id = 105），我用它作为用户在进入点执行命令。
- 创build相同的目录“/ var / log / zookeeper”，它将被挂载并将其所有权设置为zookeeper：zookeeper（尽pipe我不认为这很重要）。
一旦我用/ var / log / zookeeper安装启动我的容器，并且在容器内部打开一个作为zookeeper用户（在容器内创build的用户）的shell，我发现如果出现“Permission Denied”错误我尝试在挂载的目录/ var / log / zookeeper中创build一个文件。 当我做一个“ls -l”来查看这个目录的所有权时（仍然在容器中），它看起来像这样：
drwxr-xr-x 2 106 111 4096 Jun 30 17:18 zookeeper 在这种情况下，106和111对应于主机的动物园pipe理员用户和组ID，我认为这是问题所在。 我尝试在容器内部打开一个shell，但是这次我以root用户身份进入，上面描述的场景工作得很好，只是root是创build的文件的所有者（这是预期的）。
从这我得出结论，我需要：
（a）在我的容器中运行应用程序作为默认的root用户，而不是我创build的zookeeper用户。
（b）在我的主机上和在id完全相同的容器内创build一个zookeeper用户和组。
这两种情况都不是理想的，因为对于（a）来说 ，以root用户身份运行应用程序可能会有潜在的安全问题（从我读过的内容来看），对于（b）来说 ，可能很难让id匹配到期事实上，他们可能已经被其他用户创build（你没有任何控制权）。
有没有人曾经处理过这样的事情？ 还有其他可能的解决办法，我可能会忽略？
据我所知，容器内和主机上的用户ID和组ID应该匹配，以便让主机授予你对共享目录的权限。
看到运行生产和开发容器的区别很重要。 Afaik，如果你的Docker容器以root身份运行，甚至在生产环境中都没有问题。 但是，您永远不应该需要或需要安装大量的生产。 如果你想运行它作为一个动物园pipe理员随时这样做。
//编辑：我读得越多，我越坚信，在以root身份运行时，实际上可能存在安全问题，所以最好不要在生产环境中这样做。
尝试和uid和gid匹配的解决scheme只适用于小型/本地项目 – 这确实使其不适用。 你可以尝试设置一个任意高的uid和gid ，然后在你的每个devs机器上都这样做，但是这并不意味着它会一直很好。
tl; dr ： 开发在现有文件上运行chmod -R 0777 ，然后使用umask 0000来设置稍后创build的文件和目录的权限。 然后，无论用户创build了哪个文件，都可以随意装载和编辑文件。