GitLab Docker-in-Docker：作业容器中的 Docker 客户端如何发现“dind”服务容器中的 Docker 守护进程？

Question

我有一个正在 GKE 上运行的 GitLab CI/CD 管道。

管道中的一项作业使用 Docker-in-Docker 服务容器，以便 Docker 命令可以在作业容器内运行：

my_job:
  image: docker:20.10.7
  services:
    - docker:dind
  script:
    - docker login -u $USER -p $PASSWORD $REGISTRY
    - docker pull ${REGISTRY}:$TAG
    # ...more Docker commands

一切正常，但我想知道为什么。 my_job容器中的 Docker 客户端如何知道它需要与运行在 Docker-in-Docker 服务容器内的 Docker 守护进程通信，它又如何知道该守护进程的主机和端口？

Answer 1

真的没有“发现”过程。 必须通过配置（例如DOCKER_HOST ）告知 docker 客户端有关守护程序主机的信息。 否则，客户端将采用默认配置：

0. 如果存在DOCKER_HOST配置，则使用它。 否则：
1. 如果存在默认套接字（例如unix:///var/run/docker.sock ），则使用默认套接字。
2. 如果默认套接字不存在并且未检测到 TLS 配置，则使用tcp://docker:2375
3. 如果套接字不存在并且存在 TLS 配置，则使用tcp://docker:2376

您可以在docker dockerfile 入口点中明确看到此逻辑。

docker 客户端可以配置多种方式，但 GitLab CI 和官方docker映像中最常见的方式是通过DOCKER_HOST环境变量。 如果您在 YAML 中没有看到此变量，它可能被设置为项目或组设置，或者可能在运行器配置中设置，或者依赖于上述默认行为。

根据您的运行器配置( config.toml )，您的工作也有可能根本没有使用docker:dind服务守护程序。 例如，如果您的跑步者有一个将 docker 套接字（ /var/run/docker.sock ）安装到作业容器中并且没有DOCKER_HOST （或等效）配置的volumes规范，那么您的作业可能甚至没有使用该服务，因为它将使用已安装的套接字（根据上面的配置逻辑）。 您可以在您的工作中运行docker info ，以确保这种方式或其他方式。

附加参考：

• 官方docker图像入口点逻辑
• 保护守护进程套接字
• GitLab docker 在 docker 文档中
• Docker“上下文”