GitLab Docker-in-Docker：作业容器Docker client如何发现dind的Docker daemon？

我在GKE上运行GitLab CI/CD流水线时，配置了一个使用Docker-in-Docker（dind）服务容器的作业，具体配置如下：

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

该配置运行正常，但我想了解底层原理：作业容器中的Docker客户端是如何知道要与dind服务容器内的Docker守护进程通信，又如何获取该守护进程的主机与端口信息？

核心逻辑：GitLab Runner的自动配置机制 #

GitLab Runner在启动作业容器和配套服务容器时，会自动完成以下关键配置，让Docker客户端能无缝连接到dind内的守护进程：

1. 网络层面的关联 #

Runner会将作业容器和dind服务容器放入同一个内部网络中，两者可以直接通过服务名互相访问。这里的服务名就是你在services字段中指定的docker（因为配置写的是docker:dind，默认服务名为镜像名的前缀）。

2. 自动注入Docker客户端的连接配置 #

Runner会自动给作业容器注入DOCKER_HOST环境变量，默认值为tcp://docker:2376（dind默认启用TLS加密的端口）或tcp://docker:2375（非加密模式）。

Docker客户端启动时会优先读取DOCKER_HOST环境变量，以此确定要连接的Docker守护进程地址，不需要手动指定。

3. TLS安全认证的自动配置（默认启用） #

如果dind容器使用默认的TLS加密模式，Runner还会自动注入DOCKER_TLS_CERTDIR、DOCKER_CERT_PATH等环境变量，同时将dind容器生成的TLS证书挂载到作业容器的对应目录，确保Docker客户端能通过安全加密的方式连接到守护进程。

简单来说，GitLab Runner已经帮你完成了所有“对接”工作：把两个容器连入同一网络、告诉Docker客户端该连接的地址、搞定安全认证的配置，所以你无需手动编写任何连接相关的命令，就能直接在作业容器里执行Docker操作。

内容的提问来源于stack exchange，提问作者David Wesby