为什么？

这个问题涉及 Docker 的工作原理，特别是嵌套容器的行为。让我们逐步分析为什么在容器内部启动其他容器时，文件系统的挂载行为是基于宿主机的路径而不是当前容器的路径。

核心原因：容器运行中的 Docker 进程仍是宿主机上的服务

Docker 的核心架构
Docker 是一种容器化技术，其运行依赖于宿主机上的 Docker 服务（即 dockerd 守护进程）。
在任何容器内部运行 docker 命令，其实际操作依然是通过宿主机上的 Docker 服务来执行。
因此，在容器内运行 Docker 命令时，执行的行为依然是基于宿主机的文件系统，而不是当前容器的文件系统。
容器和宿主机文件系统隔离
Docker 本质上是一个进程隔离技术，每个容器的文件系统是基于层级存储（如 UnionFS 或 OverlayFS），这些是从宿主机挂载出来的。
当你在容器内启动另一个容器时，第二个容器的卷挂载依然是基于宿主机文件系统，而不是第一个容器的文件系统。
卷的挂载逻辑
Docker 的 -v 参数明确指定要将宿主机文件系统中的某个目录挂载到容器内部。
当你在容器内部运行 Docker 命令（如 docker run -v），Docker 守护进程并不会自动解析当前容器内部的文件路径，而是认为路径描述的是宿主机上的文件系统。
如果你使用容器内的路径去挂载卷，Docker 守护进程无法识别这些路径，因为这些路径只存在于第一个容器，并不能直接映射到宿主机文件系统。

容器中的 Docker 运行流程

举例说明，假设你有一个 Jenkins 容器运行在宿主机中：
宿主机路径 /home/yang/jenkins_data 映射到了 Jenkins 容器内路径 /var/jenkins_home。随后你在 Jenkins 容器中运行命令启动另一个容器（Python 容器）：

docker run -u root --rm --name my_python -d \  -v /var/jenkins_home/workspace/pipline_test:/home \  python:3.8 tail -f /dev/null

在这个命令中，你希望把 Jenkins 容器内的 /var/jenkins_home/workspace/pipline_test 挂载到 Python 容器的 /home 路径。然而：

Docker 守护进程运行在宿主机上，它无法识别 /var/jenkins_home/workspace/pipline_test 是 Jenkins 容器的路径。
宿主机上的 dockerd 守护进程只知道宿主机的文件系统，因此它会试图查找宿主机上是否存在 /var/jenkins_home/workspace/pipline_test 路径，而这个路径实际上并不存在于宿主机。

结果：卷挂载失败，因为 dockerd 无法找到对应的宿主机路径。

修正方法：使用宿主机路径
为了解决上述问题，你需要明确指定宿主机路径。回到这个例子：

宿主机路径 /home/yang/jenkins_data/workspace/pipline_test 映射到了 Jenkins 容器的 /var/jenkins_home/workspace/pipline_test。

因此，在 Jenkins 容器内部启动 Python 容器时，命令应写为：

docker run -u root --rm --name my_python -d \  -v /home/yang/jenkins_data/workspace/pipline_test:/home \  python:3.8 tail -f /dev/null

这样就能直接使用宿主机路径，从而让卷挂载成功。
为什么 Docker 不支持容器路径作为卷挂载？

Docker 的设计原则是保持容器的隔离性，以下几点解释了为什么不允许直接使用容器路径：

Docker 容器之间是隔离的
每个容器的文件系统都和宿主机文件系统有独立的层级存储。
如果允许一个容器直接以自身路径的形式传递给另一个容器，会破坏容器的隔离性。
Docker 守护进程基于宿主机运行
Docker 的工作机制决定了所有的 docker 命令最终是通过宿主机上的 dockerd 守护进程完成的。
Docker 守护进程无法识别容器内文件系统的路径，只能处理基于宿主机的路径。
避免复杂的路径解析逻辑
如果 Docker 支持容器路径，Docker 守护进程需要能够访问这些路径的容器上下文信息，并映射到宿主机路径，增加了实现复杂性。

总结