在Linux上的Docker容器中进行开发时,权限存在问题：如何管理主机和容器之间的文件所有权和权限.
想象一下,我有一个运行Ubuntu和Apache服务器的Docker镜像.使用(最新版本)Apache的默认设置,文档根目录为/ var / www / html,Apache将作为www-data用户运行.
为了进行一些开发,我通过Docker将文档根目录暴露在-v / path /到/ my / files：/ var / www / html.这就是出现问题的地方：
/ path / to / my / files中的文件由容器www-data user拥有.如果我很幸运,我的主人有一个www-data用户,那将是该用户;否则,它将是容器本地的独特用户.这些文件的权限(可能)为0755.
所以,当我像我一样工作时(一个名为jsmith的用户),由于文件权限不正确而导致我无法编辑这些文件.所有权.
>我可以将文件的所有权更改为jsmith,但这会导致Apache出现问题 – 它将难以访问文档根目录中的文件.
>我可以将权限更改为0777,但我在工作过程中创建的任何新文件都将归jsmith所有.
最终结果是必须不断调整所有权和开发文件的权限.其他人一定有这个问题,但是我在开发工作流程中使用Docker这个主题的每篇文章都忽略了这个问题.
我确实有一个解决方案,但我对此并不满意：
>我在/ src / myproject设置了一个文件夹.这包含我的开发文件,由www-data：www-data拥有.
>使用BindFS,我在〜/ myproject上挂载/ src / myproject,将www-data：www-data映射到jsmith：jsmith.这允许我编辑〜/ myproject中的文件而不必弄乱权限.
> Apache Docker容器使用-v / src / myproject：/ var / www / html安装/ src / myproject目录. Apache看到文件的www-data所有权并没有问题.
这很好用,但看起来过于复杂.其他人如何解决这个问题？
在所有开发人员和图像中使用公共组ID. uid可能最终成为容器中的数字,但gid至少会提供读访问权限,并且可选择写访问权,而不会全局赋予它.使用包含目录上的setgid位来使用此gid自动创建文件.这不是最干净的方法,可能会导致访问其他组成员,但根据组织的工作流程,可能更容易管理.
第二个选项是命名卷,我相信在你提出这个问题之后就添加了这个卷.它们允许您使用容器已知的uid / gid存在数据.这具有将数据移动到内部docker目录的缺点,在容器外部管理它不太容易.但是,有一些微服务方法可以使用安装相同卷的专用容器使卷与外部源(git pull,rsync等)保持同步.您基本上将数据的所有读取和写入移动到容器中,包括任何备份,更新例程和测试脚本.
