Docker使用Gosu与USER [英] Docker using gosu vs USER

问题描述

Docker 总是有一个 USER 命令以特定用户身份运行进程，但总的来说很多事情必须运行

Docker kind of always had a USER command to run a process as a specific user, but in general a lot of things had to run as ROOT.

我已经看到很多图像，这些图像使用 ENTRYPOINT 和 gosu 取消运行的进程。

I have seen a lot of images that use an ENTRYPOINT with gosu to de-elevate the process to run.

对于是否需要 gosu <，我还是有些困惑/ code>。 USER不够吗？

I'm still a bit confused about the need for gosu. Shouldn't USER be enough?

我知道Docker 1.10在安全性方面已经发生了很大变化，但是我仍然不清楚在Docker容器中运行进程的推荐方法。

I know quite a bit has changed in terms of security with Docker 1.10, but I'm still not clear about the recommended way to run a process in a docker container.

有人可以解释我何时使用 gosu 与 USER ？

Can someone explain when I would use gosu vs. USER?

谢谢

编辑：

Docker 最佳实践指南不太明确：它说进程可以没有特权运行，请使用 USER ，如果需要sudo，则可能要使用 gosu 。
令人困惑，因为可以将各种东西作为ROOT安装在 Dockerfile 中，然后创建一个用户并赋予其适当的权限，然后最终切换到该用户并以该用户身份运行 CMD 。
那么为什么我们需要sudo或 gosu ？

The Docker best practice guide is not very clear: It says if the process can run without priviledges, use USER, if you need sudo, you might want to use gosu. That is confusing because one can install all sorts of things as ROOT in the Dockerfile, then create a user and give it proper privileges, then finally switch to that user and run the CMD as that user. So why would we need sudo or gosu then?

推荐答案

Dockerfile用于创建映像。当您无法再在Dockerfile中的运行命令之间更改用户时，我认为gosu作为容器初始化的一部分更有用。

Dockerfiles are for creating images. I see gosu as more useful as part of a container initialization when you can no longer change users between run commands in your Dockerfile.

创建映像后，类似gosu的东西允许您在容器内入口点的末尾放下根权限。您最初可能需要root用户访问权限才能执行一些初始化步骤（修复uid，主机安装的卷权限等）。然后，一旦初始化，就可以在没有root特权的情况下运行最终服务，并以pid 1的形式干净地处理信号。

After the image is created, something like gosu allows you to drop root permissions at the end of your entrypoint inside of a container. You may initially need root access to do some initialization steps (fixing uid's, host mounted volume permissions, etc). Then once initialized, you run the final service without root privileges and as pid 1 to handle signals cleanly.

编辑：
这是在docker和jenkins的映像中使用gosu的简单示例： https://github.com / bmitch3020 / jenkins-docker

entrypoint.sh查找/var/lib/docker.sock文件的gid并更新容器内的docker用户进行匹配。这允许将映像移植到主机上的gid可能不同的其他docker主机。更改组需要在容器内部具有root用户访问权限。如果我在dockerfile中使用 USER jenkins ，我将被镜像中定义的docker组的gid所卡住，如果不匹配，将无法正常工作运行的Docker主机但是，运行gosu所在的应用程序时，可以删除root用户访问权限。

The entrypoint.sh looks up the gid of the /var/lib/docker.sock file and updates the gid of the docker user inside the container to match. This allows the image to be ported to other docker hosts where the gid on the host may differ. Changing the group requires root access inside the container. Had I used USER jenkins in the dockerfile, I would be stuck with the gid of the docker group as defined in the image which wouldn't work if it doesn't match that of the docker host it's running on. But root access can be dropped when running the app which is where gosu comes in.

在脚本结尾处，exec调用可防止Shell分叉gosu，并且而是用该进程替换pid 1。 Gosu依次执行相同的操作，切换uid，然后执行jenkins进程，以使其接替pid1。这允许正确处理信号，否则外壳将忽略该信号为pid 1。

At the end of the script, the exec call prevents the shell from forking gosu, and instead it replaces pid 1 with that process. Gosu in turn does the same, switching the uid and then exec'ing the jenkins process so that it takes over as pid 1. This allows signals to be handled correctly which would otherwise be ignored by a shell as pid 1.

这篇关于Docker使用Gosu与USER的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！