在前两章里，我们已经建立了两个关键认识。第一，容器本质上仍然是宿主机上的进程。第二，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。
例如：

• ps
• top
• cat /proc/1/status
• free
• 各类监控工具

问题在于，如果你只是切到了新的 rootfs，却没有在新的 Mount namespace 中正确挂载 /proc，那么这些工具看到的信息可能是错误的、不完整的，或者和新的 namespace 语义对不上。

举个直觉化理解：
你已经给进程换了新的 PID namespace，让它拥有自己的进程世界；但如果它仍然通过错误的 /proc 入口去看系统，那么这个“进程世界”在工具层面就无法正确呈现。

所以在真实容器准备流程里，通常一定会有这样一步：

在容器自己的 Mount namespace 和 rootfs 中，重新挂载一份 /proc

只有这样，容器里的工具才会在新的上下文中“看见正确世界”。

---

3.8 /dev、/sys 和其他特殊文件系统为什么麻烦

当你第一次手搓容器时，往往会发现：
只准备一个 rootfs 目录树还远远不够。因为 Linux 运行环境不仅依赖普通文件，还依赖一系列特殊文件系统和设备接口。

例如：

• /dev：设备文件入口
• /proc：进程和内核信息
• /sys：sysfs，内核和设备树相关信息
• /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 容器为什么“像一套系统”而不仅是“一个目录”

现在可以把前面的内容串起来了。

如果只是给一个进程指定一个目录，让它在这个目录下找文件，这还不够构成容器。
真正让容器像一套系统的，是下面几件事一起发生：

1. 进程进入新的 Mount namespace
   ——获得独立挂载树
2. 它的根目录被切换到新的 rootfs
   ——获得自己的 /
3. /proc 被重新挂载
   ——让系统工具看到正确进程和内核视图
4. /dev、/sys 等特殊入口被按需处理
   ——让程序运行环境完整起来
5. 再结合 PID、UTS、NET 等 namespace
   ——让它不仅文件系统独立，其他系统视图也独立

这样一来，容器才不仅仅是“一个目录里的程序”，而更像一套完整运行中的 Linux 环境。

你可以把这一章的核心重新压缩成一句话：

容器之所以觉得自己拥有独立的 /，不是因为它真的有一台独立机器，而是因为运行时为它准备了独立的 rootfs 和挂载视图。

---

3.11 本章总结

这一章真正要你掌握的，不是几个零散术语，而是一条完整逻辑链。

第一，进程访问文件系统时，永远需要一个“根目录起点”，也就是它眼中的 /。
第二，容器不能直接使用宿主机根目录，否则既没有独立系统感，也缺乏隔离。
第三，rootfs 提供了容器独立的目录树内容。
第四，chroot 能帮助你建立“切换根目录视角”的直觉，但它不等于容器。
第五，真正容器实现更依赖 Mount namespace 与 pivot_root 等机制，来构建独立挂载树和更干净的根切换。
第六，/proc、/dev、/sys 等特殊文件系统的处理，是容器运行环境完整性的关键。
第七，镜像最终还是为了给容器提供 rootfs，只不过它是经过分层和工程化封装后的形式。

---

3.12 本章自测题

为了确认你真的理解了这一章，可以试着回答下面几个问题。

问题 1

为什么容器不能直接使用宿主机的 /？

正确方向应该是：
因为这样进程会直接暴露在宿主机文件系统之上，既没有独立系统感，也会破坏隔离边界。

问题 2

rootfs 的本质是什么？

正确方向应该是：
它是一套提供给容器进程使用的独立根文件系统目录树。

问题 3

chroot 和容器的关系是什么？

正确方向应该是：
chroot 能让进程切换根目录视角，是理解容器文件系统隔离的好入门工具，但它本身不提供 namespace、cgroups、网络隔离等能力，所以不等于完整容器。

问题 4

为什么容器里通常要重新挂载 /proc？

正确方向应该是：
因为 /proc 是内核提供的虚拟文件系统，很多系统工具依赖它观察进程和系统状态；只有在新的挂载视图中正确挂载 /proc，这些工具才能和容器的 namespace 语义保持一致。