在Docker容器中进行开发时如何管理权限? [英] How do you manage permissions when developing in a Docker container?

问题描述

在Linux上的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.

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

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.

为了进行一些开发，我使用-v /path/to/my/files:/var/www/html通过Docker公开了文档根目录.这就是问题所在的地方:

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:

/path/to/my/files中的文件归容器www-data用户所有.如果我很幸运，并且我的主持人有一个www-data用户，它将是该用户.否则，它将是容器本地的唯一用户.这些文件的权限可能是0755.

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.

因此，当我以自己的身份(称为jsmith的用户)工作时，由于文件权限不正确，我无法编辑这些文件.所有权.

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，但这将导致Apache出现问题-将难以访问文档根目录中的文件.

• 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.

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

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

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

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.

我有有解决方案，但我并不完全满意:

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

• 我在/src/myproject处设置了一个文件夹.这保存了我的开发文件，并由www-data:www-data拥有.

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

使用 BindFS ，我将/src/myproject安装在~/myproject上，将www-data:www-data映射到.这样一来，我就可以在~/myproject中编辑文件，而不会弄乱权限.

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.

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

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.

这很好，但似乎过于复杂.别人如何解决这个问题?

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

推荐答案

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

I can think of two solutions:

在所有开发人员和图像之间使用通用的组ID. uid可能最终在容器中为数字，但gid至少会提供读访问权，并有选择地提供写访问权，而不会在全局范围内给出它.使用包含目录上的setgid位可以使具有此gid的文件自动创建.这不是最干净的方法，并且可能导致授予其他组成员访问权限，但是根据组织的工作流程，管理起来可能会容易得多.

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.

第二个选项是命名卷，我相信是在您问了这个问题之后添加的.它们让您拥有容器已知的uid/gid数据存在.这有将数据移到内部docker目录的弊端，在内部docker目录中，在容器外部进行管理较不容易.但是，有些微服务方法使用安装相同卷的专用容器来使卷与外部源(git pull，rsync等)保持同步.您实际上将所有对数据的读取和写入(包括所有备份，更新例程和测试脚本)移入了容器.

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.

更新:我经常在开发环境中使用的第三个选项是，以root身份运行入口点脚本，该脚本将已安装的卷uid/gid与容器内用户的uid/gid进行比较.如果它们不匹配，则将更新容器内用户的uid/gid以匹配主机.这允许开发人员在多个主机上重用同一映像，其中每个开发人员的uid/gid在他们的位置机器上可能不同.此代码包含在我的bin/fix-perms脚本中，该脚本是我的示例基本图像.我的入口点脚本的最后一步是，然后使用gosu从root重新回到用户，现在已更改了uid/gid，现在写入的所有文件都将与主机上用户的文件匹配.

Update: A third option I often use for development environments is a run an entrypoint script as root that compares the mounted volume uid/gid to the uid/gid of a user inside the container. If they do not match, the uid/gid of the user inside the container is updated to match the host. This allows developers to reuse the same image across multiple hosts where the uid/gid of each developer may be different on their location machine. The code to do this is included in my bin/fix-perms script that is part of my example base image. The last step of my entrypoint script is to then use gosu to drop from root back to the user, now with the changed uid/gid, and all files written will now match those of the user on the host.

如果您恰巧在MacOS上运行，则有一个称为 osxfs 的最新功能

If you happen to be running on MacOS, a recent feature called osxfs automatically corrects for uid/gid mismatches with host volumes.

这篇关于在Docker容器中进行开发时如何管理权限?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！