第三章：rootfs、chroot 与 Mount namespace——容器为什么会觉得自己有独立的根目录

在前两章里我们已经建立了两个关键认识。第一容器本质上仍然是宿主机上的进程。第二namespace 会把全局系统资源切成局部视图让进程觉得自己运行在一个独立环境里。但到这里还有一个非常重要的问题没有回答为什么容器里的进程会觉得/是它自己的系统根目录一个普通进程默认面对的是宿主机的文件系统视图。如果不做额外处理它看到的/bin、/etc、/lib、/usr都属于宿主机本身。这样的进程即使有自己的 PID namespace、UTS namespace也依然不像一台独立机器因为它仍然直接站在宿主机文件系统上。真正让容器变得“像一套系统”的关键步骤是让这个进程拥有自己的根文件系统视角。这就是本章要讲的主题rootfs、chroot、pivot_root以及它们与 Mount namespace 之间的关系。3.1 rootfs容器眼中的“根目录世界”先从一个最基础的词开始rootfs也就是 root filesystem根文件系统。从 Linux 进程的角度看路径解析永远是从/开始的。例如/bin/bash/etc/hosts/usr/lib/proc/1/status这些路径之所以有意义是因为进程心里默认有一个“根目录起点”。这个起点就是它眼中的/。对于普通进程来说这个/通常直接对应宿主机的根文件系统。但容器不能这样。容器必须拥有一套独立的目录结构让容器内进程觉得/bin是它自己的命令目录/etc是它自己的配置目录/lib是它自己的依赖库/usr是它自己的用户空间程序目录于是就需要为容器准备一套独立的根文件系统模板。这套模板就是 rootfs。你可以把 rootfs 理解成一套“最小可运行系统目录树”。它不一定完整到像一台传统 Linux 发行版那样复杂但它至少应该包含让目标程序运行所需的目录和依赖。比如/bin/lib或/lib64/usr/etc/tmp/proc通常运行时再挂/dev通常需要处理目标程序本身和它依赖的动态库所以本质上rootfs 并不是“容器的魔法”它只是给进程准备的一套独立根目录内容。3.2 为什么容器不能直接用宿主机的/假设你现在有了 PID namespace进程已经看不到宿主机完整进程树了有了 UTS namespace也可以设置独立 hostname甚至有了 Network namespace还像拥有自己的网络环境。但如果这个进程看到的/还是宿主机真实根目录那么它依然不是真正意义上的容器。因为此时它仍然会直接面对宿主机文件系统它可能读到宿主机的配置文件它可能执行宿主机的二进制程序它看到的/etc/passwd、/etc/resolv.conf仍然是宿主机那份它访问/proc时也可能处于错误或不一致的上下文里这会带来两个问题。第一隔离感不成立。一个自称“容器”的环境如果其根目录就是宿主机的根目录那它根本不像一套独立系统。第二风险很大。如果容器进程对宿主机文件系统有直接视图和访问能力那么所谓“容器”只是换了个名字的宿主机进程而已谈不上真正的环境隔离。所以 rootfs 的存在不是锦上添花而是容器成立的基础条件之一。没有 rootfs容器很难真正拥有“自己的系统空间”。3.3 chroot最早的“切根目录”办法在 Linux/Unix 世界里一个很经典的技术叫chroot。它的字面意思就是“change root”也就是“改变根目录”。它的作用是把某个进程眼中的/改成指定目录。这样这个进程后续再访问绝对路径时就会从新的根目录开始解析。举个例子假设你在宿主机上有一个目录/myrootfs ├── bin ├── lib ├── etc └── usr如果你对某个进程执行 chroot 到/myrootfs那么这个进程之后看到的/bin其实是/myrootfs/bin/etc其实是/myrootfs/etc从这个进程自己的视角看它并不知道前面还有一个/myrootfs。它会自然地认为/就是自己的系统根目录。这其实已经非常接近容器的体验了。所以从学习路径上讲chroot 是一个非常好的入门工具因为它能帮你快速理解所谓“容器拥有自己的 /”本质上是让进程的根目录视角发生了切换。3.4 chroot 能解决什么不能解决什么虽然 chroot 非常适合建立直觉但你必须明白chroot 不等于容器。它能解决的问题是给进程一个新的根目录视图让进程运行在独立目录树下提供一种最基础的文件系统隔离感但它解决不了很多容器真正关心的问题比如它不自动提供 PID 隔离它不自动提供网络隔离它不自动提供 hostname 隔离它不自动限制 CPU 和内存它不自动处理挂载点传播与运行时挂载逻辑如果配置不当它也不构成强安全边界所以更准确的说法是chroot 是“切换根目录视角”的技术而容器是在此之上叠加 namespace、cgroups、挂载管理和安全控制的一整套体系。你可以把 chroot 当成容器文件系统隔离的启蒙版但不要把它误认为容器本身。3.5 Mount namespace为什么“切根目录”离不开挂载视图隔离上一章我们已经讲过 Mount namespace它隔离的是挂载点视图。现在你可以更深地理解它的重要性了。如果没有独立的 Mount namespace仅仅改变某个进程的根目录并不足以让它真正拥有自己的文件系统世界。因为文件系统不仅仅是“目录内容”还涉及一整套挂载关系。比如哪个设备挂载到了哪里/proc是否是独立挂载/dev如何暴露某些 bind mount 是否只对当前环境可见宿主机后续挂载变化是否会传播进来容器需要的是一棵独立的挂载树而不仅仅是一个目录前缀。Mount namespace 就是为了解决这个问题。一旦进程进入新的 Mount namespace它就拥有了自己独立的挂载视图。在这个视图里可以把某套 rootfs 放到/单独挂载/proc单独挂载/dev添加 bind mount控制某些挂载是否传播给宿主机因此你可以把关系理解成这样rootfs提供内容chroot / pivot_root改变进程眼中的根Mount namespace提供独立挂载树三者结合容器才真正拥有“自己的文件系统世界”3.6 pivot_root比 chroot 更像真正容器的做法虽然 chroot 是入门理解的好工具但真正容器实现里更常用的是pivot_root这样的方式。为什么因为 chroot 的语义更像“把路径解析起点改掉”而 pivot_root 做的事情更接近“把当前挂载树的根真正切换过去”。它不仅是视角变了还会把旧的根和新的根在挂载关系上重新整理。从工程角度讲pivot_root 更适合容器运行时因为它更好地配合 Mount namespace 和挂载管理能够更干净地把进程运行环境切到新的 rootfs 上。学习阶段你不必一下钻进 pivot_root 的系统调用细节但你需要知道chroot 适合建立直觉pivot_root 更接近真实容器 runtime 的做法也就是说如果你是为了理解容器原理可以先用 chroot 建立模型如果你是为了手搓更像样的 mini-docker后面迟早要接触 pivot_root。3.7 为什么容器里必须重新挂载/proc现在我们把/proc单独拿出来讲因为它是很多初学者最容易忽略却又极其关键的地方。/proc不是普通磁盘目录它是内核导出的一个虚拟文件系统。里面包含了大量运行时信息比如进程状态内存信息CPU 信息内核参数cgroup 信息容器里很多工具之所以看起来“像在独立系统里正常工作”依赖的就是/proc。例如pstopcat /proc/1/statusfree各类监控工具问题在于如果你只是切到了新的 rootfs却没有在新的 Mount namespace 中正确挂载/proc那么这些工具看到的信息可能是错误的、不完整的或者和新的 namespace 语义对不上。举个直觉化理解你已经给进程换了新的 PID namespace让它拥有自己的进程世界但如果它仍然通过错误的/proc入口去看系统那么这个“进程世界”在工具层面就无法正确呈现。所以在真实容器准备流程里通常一定会有这样一步在容器自己的 Mount namespace 和 rootfs 中重新挂载一份/proc只有这样容器里的工具才会在新的上下文中“看见正确世界”。3.8/dev、/sys和其他特殊文件系统为什么麻烦当你第一次手搓容器时往往会发现只准备一个 rootfs 目录树还远远不够。因为 Linux 运行环境不仅依赖普通文件还依赖一系列特殊文件系统和设备接口。例如/dev设备文件入口/proc进程和内核信息/syssysfs内核和设备树相关信息/dev/pts伪终端支持/run运行时状态目录这些目录很多都不是简单“复制点文件”就能工作的。它们背后涉及虚拟文件系统挂载设备节点内核导出接口运行时动态内容因此一个真正可用的容器环境往往不仅仅是解压一个 rootfs tar 包还需要在运行时挂/proc适当处理/dev决定是否挂/sys挂临时目录或 tmpfs配置 bind mount这也是为什么容器运行时比表面上看起来复杂得多。表面上只是“换个根目录”实际上是“重建一整套受控的文件系统运行环境”。3.9 rootfs 和镜像是什么关系到这里你可能已经会问“既然容器需要 rootfs那 Docker 镜像和 rootfs 到底什么关系”这个关系可以简单理解成镜像是 rootfs 的可分发、可复用、可分层打包形式。也就是说Docker 镜像并不是“另一种神秘对象”它最终还是为了给容器提供一套 rootfs 内容。只是为了工程化需求Docker 没有把它做成一整个简单目录拷贝而是做成了分层可缓存可共享可远程分发当容器启动时这些镜像层会被组装成一个运行时文件系统视图然后再在最上面叠加可写层。你可以把这个过程理解成“把镜像还原成容器要使用的 rootfs”。所以从学习顺序上rootfs 是概念基础镜像是工程实现增强。先懂 rootfs再学镜像会顺很多。3.10 容器为什么“像一套系统”而不仅是“一个目录”现在可以把前面的内容串起来了。如果只是给一个进程指定一个目录让它在这个目录下找文件这还不够构成容器。真正让容器像一套系统的是下面几件事一起发生进程进入新的 Mount namespace——获得独立挂载树它的根目录被切换到新的 rootfs——获得自己的//proc被重新挂载——让系统工具看到正确进程和内核视图/dev、/sys等特殊入口被按需处理——让程序运行环境完整起来再结合 PID、UTS、NET 等 namespace——让它不仅文件系统独立其他系统视图也独立这样一来容器才不仅仅是“一个目录里的程序”而更像一套完整运行中的 Linux 环境。你可以把这一章的核心重新压缩成一句话容器之所以觉得自己拥有独立的/不是因为它真的有一台独立机器而是因为运行时为它准备了独立的 rootfs 和挂载视图。3.11 本章总结这一章真正要你掌握的不是几个零散术语而是一条完整逻辑链。第一进程访问文件系统时永远需要一个“根目录起点”也就是它眼中的/。第二容器不能直接使用宿主机根目录否则既没有独立系统感也缺乏隔离。第三rootfs 提供了容器独立的目录树内容。第四chroot 能帮助你建立“切换根目录视角”的直觉但它不等于容器。第五真正容器实现更依赖 Mount namespace 与 pivot_root 等机制来构建独立挂载树和更干净的根切换。第六/proc、/dev、/sys等特殊文件系统的处理是容器运行环境完整性的关键。第七镜像最终还是为了给容器提供 rootfs只不过它是经过分层和工程化封装后的形式。3.12 本章自测题为了确认你真的理解了这一章可以试着回答下面几个问题。问题 1为什么容器不能直接使用宿主机的/正确方向应该是因为这样进程会直接暴露在宿主机文件系统之上既没有独立系统感也会破坏隔离边界。问题 2rootfs 的本质是什么正确方向应该是它是一套提供给容器进程使用的独立根文件系统目录树。问题 3chroot 和容器的关系是什么正确方向应该是chroot 能让进程切换根目录视角是理解容器文件系统隔离的好入门工具但它本身不提供 namespace、cgroups、网络隔离等能力所以不等于完整容器。问题 4为什么容器里通常要重新挂载/proc正确方向应该是因为/proc是内核提供的虚拟文件系统很多系统工具依赖它观察进程和系统状态只有在新的挂载视图中正确挂载/proc这些工具才能和容器的 namespace 语义保持一致。