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“上下文”