GitLab Runner使用自定义容器时偶发无法连接Docker daemon报错求助

1. GitLab Runner 配置排查 #

• 确认Runner的Docker执行器模式：若采用挂载宿主机/var/run/docker.sock的模式，偶发连接失败大概率是自定义镜像体积更大，拉取/启动时占用过多Docker daemon资源导致响应超时。
• 检查Runner配置文件/etc/gitlab-runner/config.toml的参数配置：
  • 将pull_policy调整为if-not-present，避免每次执行任务都重新拉取镜像，减少Docker daemon压力：

    [runners.docker]
      pull_policy = ["if-not-present"]
    

  • 新增Docker连接超时、共享内存配置，避免资源不足导致的超时：

    [runners.docker]
      docker_connection_timeout = "300s"
      shm_size = 268435456
    

• 排查宿主机Docker daemon状态：查看/var/log/docker.log中对应任务失败时间点的异常日志，执行docker info确认是否存在资源、权限相关报错。

2. 自定义镜像配置排查 #

• 验证镜像启动入口是否正常：本地执行docker run --rm -it 你的自定义镜像地址 bash，若无法正常进入交互终端，说明镜像的ENTRYPOINT/CMD配置错误，存在阻塞进程的默认启动项。可在Dockerfile末尾添加ENTRYPOINT []清空默认入口，或显式设置CMD ["/bin/bash"]修复。
• 精简镜像体积：移除镜像中不必要的依赖、缓存文件，避免大于2G的镜像在解压启动时占用过高宿主机IO资源，触发Docker daemon超时。

3. 修复方案 #

• 临时修复：在.gitlab-ci.yml中为对应任务添加自动重试规则，规避偶发系统故障：

  job_name:
    retry:
      max: 2
      when:
        - runner_system_failure
        - stuck_or_timeout_failure
  

• 永久修复：调整宿主机Docker daemon配置/etc/docker/daemon.json，提升并发处理能力和资源上限：

  {
    "max-concurrent-downloads": 10,
    "default-ulimits": {
      "nofile": {
        "Hard": 65535,
        "Soft": 65535
      }
    }
  }
  

  配置修改完成后执行systemctl daemon-reload && systemctl restart docker重启服务生效。

内容的提问来源于stack exchange，提问作者Gonçalo Marrafa