在Docker容器中进行开发时如何管理权限？

When developing in a Docker container on Linux, there is a problem with permissions: how to manage file ownership and permissions between the host and the container.

在Linux上的Docker容器中进行开发时,权限存在问题:如何管理主机和容器之间的文件所有权和权限。

Imagine that I have a Docker image that runs Ubuntu and an Apache server. Using the default settings for (recent versions of) Apache, the document root will be /var/www/html and Apache will be run as the www-data user.

想象一下,我有一个运行Ubuntu和Apache服务器的Docker镜像。使用(最新版本)Apache的默认设置,文档根目录为/ var / www / html,Apache将作为www-data用户运行。

In order to do some development, I expose the document root via Docker with -v /path/to/my/files:/var/www/html. And this is where the problem arises:

为了进行一些开发,我通过Docker将文档根目录暴露在-v / path /到/ my / files:/ var / www / html。这就是出现问题的地方:

The files in /path/to/my/files are owned by the containers www-data user. If I'm lucky and my host has a www-data user, it will be that user; otherwise, it will be a distinct user local to the container. The permissions on those files will (probably) be 0755.

/ path / to / my / files中的文件由容器www-data user拥有。如果我很幸运,我的主机有一个www-data用户,那将是该用户;否则,它将是容器本地的独特用户。这些文件的权限(可能)为0755。

So, when I'm working away as myself (a user called jsmith), those files cannot be edited by me because of incorrect file permissions & ownership.

所以,当我作为自己(一个名为jsmith的用户)工作时,由于文件权限和所有权不正确,我无法编辑这些文件。

• I could change the ownership of the files to jsmith, but that will cause problems with Apache - it will have difficulty accessing files in the document root.

  我可以将文件的所有权更改为jsmith,但这会导致Apache出现问题 - 它将难以访问文档根目录中的文件。

• I could change the permissions to 0777, but any new files I create in the course of my work will be owned by jsmith.

  我可以将权限更改为0777,但我在工作过程中创建的任何新文件都将归jsmith所有。

The end result is that it is necessary to constantly adjust ownership & permissions on the development files. Other people must have this problem, but every post I've seen on the topic of using Docker in a development workflow just kind of overlooks this problem.

最终结果是必须不断调整开发文件的所有权和权限。其他人一定有这个问题,但是我在开发工作流程中使用Docker这个主题的每篇文章都忽略了这个问题。

I do have a solution, but I'm not entirely happy with it:

我确实有一个解决方案,但我对此并不满意:

• I set up a folder at /src/myproject. This holds my development files and is owned by www-data:www-data.

  我在/ src / myproject设置了一个文件夹。这包含我的开发文件,由www-data:www-data拥有。

• Using BindFS, I mount /src/myproject at ~/myproject, mapping www-data:www-data to jsmith:jsmith. This allows me to edit files in ~/myproject without messing around with permissions.

  使用BindFS,我在〜/ myproject上挂载/ src / myproject,将www-data:www-data映射到jsmith:jsmith。这允许我编辑〜/ myproject中的文件而不必弄乱权限。

• The Apache Docker container mounts the /src/myproject directory with -v /src/myproject:/var/www/html. Apache sees the www-data ownership of the files and has no problems.

  Apache Docker容器使用-v / src / myproject:/ var / www / html安装/ src / myproject目录。 Apache看到文件的www-data所有权并没有问题。

This works well, but seems overly complicated. How do other people solve this problem?

这很好用,但看起来过于复杂。其他人如何解决这个问题?

1 个解决方案

#1

I can think of two solutions:

我可以想到两个解决方案:

Use a common group id among all developers and images. The uid may end up being numeric in the container, but the gid would give at least read access, and optionally write access, without giving it out globally. Use the setgid bit on the containing directories to have files automatically created with this gid. This isn't the cleanest approach, and may lead to giving out access to other group members, but it may be much easier to manage depending on your organization's workflow.

在所有开发人员和图像中使用公共组ID。 uid可能最终在容器中成为数字,但gid将至少提供读访问权限,并可选择写访问权,而不是全局赋予它。使用包含目录上的setgid位来使用此gid自动创建文件。这不是最干净的方法,可能会导致访问其他组成员,但根据组织的工作流程管理可能要容易得多。

The second option is named volumes, which I believe were added after you asked this question. They let you have the data exist with the uid/gid's known to the containers. This has the downside of moving the data into the internal docker directories where it's less easy to manage outside of a container. However, there are microservices approaches that keep the volume synchronized with an outside source (git pull, rsync, etc) using a dedicated container that mounts the same volume. You essentially move all of the reads and writes of the data into containers, including any backups, update routines, and testing scripts.

第二个选项是命名卷,我相信在你提出这个问题之后会添加它。它们允许您使用容器已知的uid / gid存在数据。这具有将数据移动到内部docker目录的缺点,在容器外部管理它不太容易。但是,有一些微服务方法可以使用安装相同卷的专用容器使卷与外部源(git pull,rsync等)保持同步。您基本上将数据的所有读取和写入移动到容器中,包括任何备份,更新例程和测试脚本。