Docker --volume参数工作原理及GitLab CI挂载失败问题咨询

这个问题的核心是Docker-in-Docker（dind）环境的文件系统隔离特性导致的，我来一步步帮你拆解原因和解决方案：

为什么挂载后/code是空的？ #

你在GitLab CI里用的是docker执行器，并且启用了docker:dind服务。这里要明确两个关键容器的区别：

1. 你的Job脚本是在docker:stable这个Runner容器里执行的，/builds/ben/project是这个容器里的目录，里面有你的代码文件。
2. 而你运行的docker run命令，实际是交给docker:dind服务里的Docker守护进程来执行的，这个dind容器和Runner容器的文件系统是完全隔离的——它根本看不到Runner容器里的/builds/ben/project路径。

Docker有个默认行为：当你用--volume挂载一个不存在的源路径时，它会自动创建一个空目录作为挂载源。这就是为什么你最后看到total 0，而且没有报错的原因。

解决方案 #

这里有两种最实用的解决方法，你可以根据场景选择：

方案1：修改Runner配置，共享工作目录（推荐长期使用） #

修改你的Runner的config.toml文件，把Runner的工作目录/builds挂载到dind容器里，让两个容器共享这个目录：

concurrent = 1
check_interval = 0
[session_server]
session_timeout = 1800
[[runners]]
name = "test"
url = "http://docker.int.com:1040/"
token = "*************"
executor = "docker"
[runners.docker]
tls_verify = false
image = "docker:stable"
privileged = true
disable_entrypoint_overwrite = false
oom_kill_disable = false
disable_cache = false
# 添加/builds:/builds，让Runner容器和dind容器共享工作目录
volumes = ["/var/run/docker.sock:/var/run/docker.sock","/builds:/builds", "/cache"]
extra_hosts = ["mygitlab.com:XXX.XXX.XXX.XXX"]
shm_size = 0
[runners.cache]
[runners.cache.s3]
[runners.cache.gcs]

修改完成后重启GitLab Runner，这样dind容器里也会有/builds/ben/project目录，你原来的docker run命令就能正确挂载代码了。

方案2：用Docker Volume中转代码（适合临时测试，无需修改Runner配置） #

如果不想修改Runner配置，可以先创建一个Docker Volume，把Runner容器里的代码复制到这个Volume，再挂载到目标容器：

# 创建共享Volume
- docker volume create project-code
# 把当前目录的代码复制到Volume里
- docker run --rm -v project-code:/dest -v "$PWD":/src debian:stable cp -r /src/. /dest/
# 挂载Volume到目标容器，查看内容
- docker run --rm -v project-code:/code debian:stable ls -l /code

这个方法通过Volume作为中转，绕开了容器间的文件系统隔离问题。

内容的提问来源于stack exchange，提问作者benjamin.cohen-solal