私有GitLab在GCP部署Docker类型Runner遇问题求助

Hey，看起来你已经把基础环境搭得挺到位了——shell类型的Runner跑起来完全正常，说明GitLab和GCE实例之间的通信、权限这些基础环节都没毛病。问题大概率出在Docker类型Runner的配置细节，或者GCP环境的特殊限制上，我给你梳理几个排查和解决的方向：

Docker Runner要正常处理各类CI任务，有两个关键配置项绝对不能少：

• 特权模式（privileged）：如果你的CI任务需要在容器内构建镜像（比如执行docker build），必须开启这个模式，否则容器内无法嵌套运行Docker守护进程。重新注册Runner时可以加上这个参数：

  sudo gitlab-runner register \
    --url "你的私有GitLab主机地址" \
    --registration-token "你的项目注册令牌" \
    --description "GCP Docker Runner" \
    --executor "docker" \
    --docker-image "docker:latest" \
    --docker-privileged \
    --docker-volumes "/var/run/docker.sock:/var/run/docker.sock"
  

• 挂载Docker套接字：/var/run/docker.sock是容器内Docker客户端调用宿主机Docker守护进程的关键路径，没有这个挂载，容器里根本没法操作Docker。

因为你的Runner部署在GCP上，得考虑云环境的特殊规则：

• 服务账号权限补充：虽然你给了项目Editor权限，但如果Docker Runner需要拉取GCR（Google容器注册表）的私有镜像，还得给服务账号加上roles/storage.objectViewer权限，确保它能访问镜像仓库的资源。
• 防火墙与网络连通性：检查GCE实例的防火墙规则，确保允许出站的HTTPS（443端口）流量（用来拉取公共或私有镜像），同时确认私有GitLab主机和Runner之间的网络没有被防火墙阻断。

你提到Docker Runner仅能在stage: build image: ...这类配置下工作，那要看看其他CI任务的配置是不是有疏漏：

• 如果是在job里手动执行docker build/docker push，首先要确保job使用的镜像包含Docker客户端（比如用docker:latest，或者在ubuntu镜像里提前安装docker）。
• 私有镜像拉取的认证：如果任务需要拉取私有镜像，得在CI配置的before_script里添加登录逻辑，比如：

  before_script:
    - echo "$CI_REGISTRY_PASSWORD" | docker login -u "$CI_REGISTRY_USER" --password-stdin "$CI_REGISTRY"
  

如果上面的步骤都没解决问题，直接看Runner的日志是最高效的方式：

sudo gitlab-runner logs

或者查看日志文件（默认路径是/var/log/gitlab-runner/），日志里会明确告诉你是镜像拉取失败、权限不足，还是Docker守护进程通信出了问题，根据错误信息针对性修复就行。

最后检查一下GCE实例上的Docker守护进程有没有特殊限制：

• 查看/etc/docker/daemon.json，确保没有配置iptables: false这类会影响容器网络的参数。
• 重启Docker和GitLab Runner服务，让配置生效：

  sudo systemctl restart docker
  sudo systemctl restart gitlab-runner
  

按照这个流程排查，应该能解决Docker Runner仅有限工作的问题。如果有具体的错误日志，贴出来我再帮你细化分析~

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