GitLab Pipeline执行Docker部署时偶发失败重试成功是什么原因？

• 核心原因是GitLab CI Pipeline依赖的Docker-in-Docker（dind）服务初始化延迟：首次执行Job时，部署任务的执行容器启动速度远快于dind服务容器的Docker daemon初始化速度，执行Docker相关命令时dind还未完全就绪，因此抛出无法连接daemon的报错。
• 重试Job时，dind服务已经在第一次Job启动过程中完成了初始化，因此再次执行Docker命令可以正常连接daemon，任务运行成功。
• 额外排查点：你日志中显示连接地址为tcp://localhost:2375，若你Pipeline中dind服务的别名不为localhost，也可能是DOCKER_HOST环境变量配置不匹配导致首次连接失败，重试时DNS解析生效后恢复。

方案1：添加dind就绪等待逻辑 #

在部署Job的before_script段添加轮询检查逻辑，等待Docker daemon完全就绪后再执行后续部署命令，示例配置：

before_script:
  - |
    echo "等待Docker daemon启动..."
    until docker info > /dev/null 2>&1; do
      sleep 1
    done

方案2：为dind服务配置健康检查 #

GitLab CI 14.3及以上版本支持服务健康检查配置，可让Runner等待dind服务完全就绪后再启动任务执行容器，示例配置：

services:
  - name: docker:dind
    alias: docker
    healthcheck:
      test: ["CMD", "docker", "info"]
      interval: 1s
      timeout: 3s
      retries: 10
variables:
  DOCKER_HOST: tcp://docker:2375

方案3：挂载宿主机Docker套接字（私有Runner适用） #

如果你使用的是自行维护的私有GitLab Runner，可直接修改Runner的config.toml配置，在[[runners.docker]]的volumes字段添加/var/run/docker.sock:/var/run/docker.sock，同时删除Pipeline中的dind服务配置，直接复用宿主机的Docker daemon，从根源上消除服务启动延迟问题。

注意：使用套接字挂载方案需要注意执行Job的用户有docker.sock的读写权限，避免出现权限拒绝报错。

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