在GitLab Runner容器中执行docker-compose并绑定仓库文件问题

核心问题 #

当GitLab Runner通过绑定主机/var/run/docker.sock执行docker-compose时，docker-compose实际运行在主机上下文中，而仓库文件仅存在于Runner容器内，主机无法直接访问这些文件，导致挂载config.toml失败。

可行解决方案 #

方案1：绑定挂载Runner工作目录到主机 #

在注册GitLab Runner容器时，将Runner内部的工作目录（默认路径为/builds/<namespace>/<project>）绑定挂载到主机的某个目录，让主机能直接访问仓库文件。

1. 注册Runner时添加挂载参数：

docker run -d \
  --name gitlab-runner \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /host-machine/gitlab-runner-builds:/builds \
  -v /host-machine/gitlab-runner-config:/etc/gitlab-runner \
  gitlab/gitlab-runner:latest

这里/host-machine/gitlab-runner-builds是主机上的目录，会同步Runner容器内的/builds目录（即仓库代码存放的位置）。

2. 修改项目中的docker-compose.yml，使用主机上的绝对路径挂载：

services:
  your-service:
    volumes:
      - /host-machine/gitlab-runner-builds/${CI_PROJECT_NAMESPACE}/${CI_PROJECT_NAME}/config.toml:/target/path/in/container/config.toml

CI_PROJECT_NAMESPACE和CI_PROJECT_NAME是GitLab的预定义环境变量，会自动填充仓库的命名空间和项目名。

方案2：临时复制仓库文件到主机 #

在CI Job中先将仓库内的config.toml复制到主机的临时目录，再修改docker-compose.yml的挂载路径指向该临时文件，执行完成后清理文件。

gitlab-ci.yml示例：

deploy:
  script:
    # 将Runner容器内的config.toml复制到主机临时目录
    - docker cp "$CI_PROJECT_DIR/config.toml" "$(hostname):/tmp/config.toml"
    # 替换docker-compose.yml中的挂载路径
    - sed -i "s|./config.toml|/tmp/config.toml|" docker-compose.yml
    # 启动容器
    - docker-compose up -d
    # 清理临时文件（可选）
    - docker exec "$(hostname)" rm /tmp/config.toml

注意：需要确保Runner容器有执行docker cp和docker exec的权限，可能需要调整Runner的用户权限或Docker组配置。

方案3：使用Docker-in-Docker（DinD）模式 #

让GitLab Runner在独立的Docker环境中执行docker-compose，此时上下文为Runner容器内部，仓库文件可直接被访问，无需依赖主机文件系统。

gitlab-ci.yml示例：

deploy:
  image: docker:latest
  services:
    - docker:dind
  variables:
    DOCKER_HOST: tcp://docker:2375
    DOCKER_DRIVER: overlay2
    DOCKER_TLS_CERTDIR: ""
  script:
    # 安装docker-compose
    - apk add --no-cache docker-compose
    # 直接启动容器，挂载路径使用仓库内的相对路径即可
    - docker-compose up -d

注册Runner时需开启特权模式：

docker run -d \
  --name gitlab-runner \
  --privileged \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /host-machine/gitlab-runner-config:/etc/gitlab-runner \
  gitlab/gitlab-runner:latest

注意：DinD模式需要特权权限，存在一定安全风险，且每次Job会启动新的Docker环境，镜像缓存无法共享，可能影响构建速度。

方案对比 #

• 绑定挂载：性能最优，无安全风险，但需提前配置Runner挂载路径，适合固定部署的Runner。
• 临时复制：无需修改Runner配置，但步骤繁琐，适合临时测试场景。
• DinD：配置简单，上下文一致性最好，但有安全风险和性能损耗，适合对配置复杂度要求低的场景。

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