在Docker场景中的Docker中挂载`/var/run/docker.sock`是什么结果?

问题描述

我已阅读任何人都可以解释docker.sock 来了解什么/var/run/docker.sock 可以，但是它在GitLab CI的使用Docker套接字绑定让我感到困惑.

I've read Can anyone explain docker.sock to understand what /var/run/docker.sock does, but its use in GitLab CI's Use Docker socket binding has me confused.

这是他们用于 gitlab-runner 注册的示例命令:

Here is their example command for the gitlab-runner registration:

sudo gitlab-runner register -n \
  --url https://gitlab.com/ \
  --registration-token REGISTRATION_TOKEN \
  --executor docker \
  --description "My Docker Runner" \
  --docker-image "docker:19.03.12" \
  --docker-volumes /var/run/docker.sock:/var/run/docker.sock

我看到生成的容器可以从两个地方获取 docker 的地方.

I see two places that the resulting container could obtain docker from.

1. Unix套接字/var/run/docker.sock .
2. 基本映像 docker:19.03.12 中包含的 docker 二进制文件.

1. The unix socket /var/run/docker.sock.
2. The docker binary included in the base image docker:19.03.12.

这不是 PATH 冲突吗?我以为应该是其中之一，我可以从主机的unix套接字或基础映像中使用 docker .

Isn't this a PATH conflict? I thought it should be one or the other, where I obtain the ability to use docker from either the host's unix socket or the base image.

我认为-docker-image 应该改为 ubuntu:latest 或 docker ，因为 PATH 的 docker 已经来自主机套接字.另外，也可以删除docker套接字安装.

I would think that --docker-image should instead be ubuntu:latest or something along those lines that doesn't come with docker, since the PATH's docker would already come from the host socket. Alternatively, the docker socket mount would be removed.

关于双重包含 docker 的内容，实际上发生了什么?

What is actually happening here in regards to this double inclusion of docker?

推荐答案

Unix套接字文件/var/run/docker.sock 通常是由Docker守护进程创建的.如果您将其他内容作为主容器进程运行，则不会创建套接字.您可以通过运行具有非Docker主进程的容器来直接查看，例如/bin/ls :

The Unix socket file /var/run/docker.sock is normally created by the Docker daemon. If you run something else as the main container process, the socket won't get created. You can directly look by running a container with a non-Docker main process, like /bin/ls:

docker run --rm docker:19.03.12 ls -l /var/run
docker run --rm docker:19.03.12 ls -l /run

/usr/bin/docker 二进制文件必须存在于容器文件系统中(如果要使用它).容器永远不能调用主机上的二进制文件，套接字API也不会生成二进制文件.(在很早的使用主机的Docker套接字"一文中，有人提倡将二进制文件绑定安装到容器中，但这会导致库依赖关系出现问题，并使图像不自成体系.)

The /usr/bin/docker binary must exist in the container filesystem, if you're going to use it. Containers can never call binaries that are on the host, and the socket API won't produce a binary either. (Some of the very early "use the host's Docker socket" posts advocated bind-mounting the binary into the container, but this leads to trouble with library dependencies and makes images not be self-contained.)

因此，如果您实际需要的只是一个带有 docker 二进制文件的Docker容器，该容器可以调用主机的Docker套接字，则需要类似 docker ，其中 image 具有/usr/bin/docker ，此外，您还需要将主机的/var/run/docker.sock 绑定安装到容器中.

So if all you actually need is a Docker container, with a docker binary, that can invoke the host's Docker socket, you need an image like docker where the image has a /usr/bin/docker, plus you need to bind-mount the host's /var/run/docker.sock into the container.

docker run \
  --rm \
  -v /var/run/docker.sock:/var/run/docker.sock \
  docker:19.03.12 \
  docker ps

---

您链接到的GitLab设置似乎是人为的.使用 docker 图像运行作业意味着，构建步骤可以运行的 only 几乎是一个 docker 命令.从技术上讲，您必须先启动 docker 二进制文件并访问正在运行的Docker守护程序，才能启动 docker 容器.该页面顶部描述的shell-executor方法似乎更简单，并且没有任何不利之处.

---

The GitLab setup you link to seems rather contrived. Using the docker image to run jobs means that pretty much the only thing a build step can run is a docker command. At a technical level, you can't start the docker container without already having a docker binary and access to a running Docker daemon; the shell-executor approach described at the top of that page seems simpler and there aren't really any downsides to it.

您也可能会发现拥有构建时依赖项的Docker映像(编译器，头文件，静态检查工具等)很方便.这样一来，您无需更新整个构建集群就可以更新这些依赖项.如果您的构建脚本本身需要调用 docker ，则您的构建工具映像需要安装Docker，只需使用常规的 RUN apt-get install 命令即可.您需要以相同的方式将主机的Docker套接字推入容器，因此无需启动单独的Docker守护程序.

You also also might find it convenient to have a Docker image of build-time dependencies (compilers, header files, static checking tools, ...). That would let you update these dependencies without having to roll out an update to your entire build cluster. If your build scripts themselves need to invoke docker then your build-tools image needs to install Docker, just using a normal RUN apt-get install command. You need to push the host's Docker socket into the container in the same way, and so you don't need to start a separate Docker daemon.

这篇关于在Docker场景中的Docker中挂载`/var/run/docker.sock`是什么结果?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！