手搓一个“容器”

01 / 准备文件

先备 rootfs

rootfs（根文件系统）是一棵目录树。里面要有 shell、工具和依赖库。仅创建一个空目录，无法运行 /bin/sh。

如果需要复习，已有页面解释了容器为何共享内核、镜像与容器的关系，以及docker run 的启动流程。

终端 A · 先用 Docker 取得文件

这一步只借 Docker 导出文件，后面的进程由 Linux 工具启动。alpine:latest 是可变标签；本次先拉取，再把本地镜像 ID 保存到 IMAGE，让导出与对照实验使用同一份镜像。镜像需匹配虚拟机 CPU 架构。

LAB=$(mktemp -d /tmp/scratch-container.XXXXXX)
printf '%s\n' "$LAB"  # 记下此路径，终端 B 会用到
mkdir "$LAB/rootfs"
docker pull alpine:latest
IMAGE=$(docker image inspect --format '{{.Id}}' alpine:latest)
printf '%s\n' "$IMAGE" > "$LAB/image.id"
CID=$(docker create "$IMAGE" /bin/sh)
docker export --output="$LAB/rootfs.tar" "$CID"
docker rm "$CID"

预期（未实测）：rootfs.tar 是容器文件系统的 tar 归档。docker create 没有启动 shell；docker rm 只移除这个用于导出的容器。镜像与归档仍保留。任一命令失败，先解决错误再继续。

root · 在虚拟机里做 在终端 A 解包可信镜像导出的归档，保留其文件属主：

sudo tar --numeric-owner -xpf "$LAB/rootfs.tar" -C "$LAB/rootfs"
sudo mkdir -p "$LAB/rootfs/proc"
sudo test -x "$LAB/rootfs/bin/sh"

预期（未实测）：最后一条检查成功时不打印内容。它只确认 shell 路径可执行，不替代后续启动检查。export 不包含卷里的数据，也不保存镜像的层历史；不要用 docker save 的归档直接充当 rootfs。[1]

Docker 对照：Engine 根据镜像准备容器的根文件系统及可写层；export 得到的是文件树，不会保留这套分层。[2]

02 / 创建视图

unshare 建边界

namespace（命名空间）决定进程看到哪一组系统对象。unshare 创建指定的 namespace，再运行程序。这里分出五种视图；它不会自动准备 rootfs 或限内存。[3]

root · 在虚拟机里做 终端 A 运行下面这段完整命令。它会停在内部 shell，先别退出。宿主的 Bash 负责记录一个 PID，然后用 exec 替换为 chroot 和内部 shell，不额外留下中间 shell。

sudo unshare --mount --uts --ipc --net --pid --fork \
  --propagation private /bin/bash -c '
    set -eu
    read -r outer_pid rest < /proc/self/stat
    printf "%s\n" "$outer_pid" > "$1/host.pid"
    exec chroot "$1/rootfs" /bin/sh
  ' _ "$LAB"

预期（未实测）：进入 rootfs 的 shell；此时 /proc 仍只是空目录。host.pid 记录 shell 在宿主 PID 视图中的编号，终端 B 限内存时会用到它；不要将它猜成固定值。

03 / 让工具看见进程

挂好 /proc

chroot 改的是 /，procfs 提供的是进程信息。procfs 是内核生成的虚拟文件系统，通常挂在 /proc。新挂载的 procfs 对应挂载者所在的 PID namespace。[5]

root · 在虚拟机里做 在终端 A 的内部 shell执行：

hostname scratch-lab
printf 'shell pid: %s\n' "$$"
mount -t proc proc /proc
hostname
ps
ip link
ip route

预期（未实测）：主机名变为你设置的 scratch-lab，shell 的 PID 应为 1。ps 应只列内部 shell、ps 等内部进程，不出现宿主服务。网络应只有回环接口 lo、没有默认路由；它尚未接线，不能访问外网。不要据此排查 DNS。

切到终端 B，在宿主运行 hostname 和 ps -e。预期宿主主机名不变，进程列表仍含宿主服务。宿主能看到内部进程；内部看不到外层进程。这不是双向隐藏。

Docker 对照：运行时设置根文件系统、procfs 等挂载，再执行应用。默认 bridge 网络通常还要连接虚拟网卡与网桥；本实验的空网络更接近 --network none。[6]

04 / 限制资源

cgroup 限内存

cgroup（控制组）把一组进程纳入共同的资源约束。本实验使用 cgroup v2 的 memory.max，设为 64 MiB（67,108,864 字节），并用 memory.swap.max 禁止交换空间。它们不会改变 namespace。[7]

root · 在虚拟机里做 终端 A 保持 shell 空闲。终端 B 设置 LAB 为 A 第一段打印的实际路径，例如用 LAB='你复制的路径'，再运行整段：

sudo bash -s -- "$LAB" <<'HOST'
set -eu
lab_dir=$1
test -f /sys/fs/cgroup/cgroup.controllers
if ! grep -qw memory /sys/fs/cgroup/cgroup.subtree_control; then
  printf '%s\n' '根层未向子组启用 memory；停止本步骤。' >&2
  exit 1
fi
host_pid=$(cat "$lab_dir/host.pid")
# 先核对 PID 仍指向本次实验，避免用错或复用的 PID。
test "$(readlink "/proc/$host_pid/root")" = "$lab_dir/rootfs"
cg_dir="/sys/fs/cgroup/scratch-container-$host_pid"
mkdir "$cg_dir"
printf '%s\n' "$cg_dir" > "$lab_dir/cgroup.path"
# 缺少控制文件会停止；不要在失败后继续加入进程。
test -f "$cg_dir/memory.max"
test -f "$cg_dir/memory.swap.max"
printf '67108864\n' > "$cg_dir/memory.max"
printf '0\n' > "$cg_dir/memory.swap.max"
printf '%s\n' "$host_pid" > "$cg_dir/cgroup.procs"
cat "$cg_dir/memory.max" "$cg_dir/memory.swap.max"
cat "$cg_dir/cgroup.procs"
cat "/proc/$host_pid/cgroup"
HOST

预期（未实测）：前两个读回值分别等于写入的字节上限和交换空间上限；成员列表包含 host.pid 的编号，进程的 cgroup 路径指向本次实验组。只有读回配置且成员归属正确，才继续。若控制器不可用，先停在此处，换满足条件的虚拟机；不要盲目修改 systemd 管理的父组。

这验证了配置与成员关系，没有实测触发 OOM。OOM（内存不足）时，内核先尝试回收；无法满足限额内的分配时可能杀死组内进程或使分配失败。不保证某条命令一定输出“被杀死”。memory.max 也不是预先分配一块物理内存。[7]

终端 B · 用 Docker 对照同一限额

这条独立实验在宿主运行，不需要 --privileged。读取两个 cgroup v2 文件；使用的仍是刚才保存的镜像 ID：

IMAGE=$(cat "$LAB/image.id")
docker run --rm --network none --memory 64m --memory-swap 64m \
  "$IMAGE" sh -c 'cat /sys/fs/cgroup/memory.max; cat /sys/fs/cgroup/memory.swap.max'

预期（未实测）：在上述 cgroup v2 环境中，两个读回值应与手动设置相同。若宿主或 Docker 使用 cgroup v1，路径不同，此命令不适用。

Docker 对照：--memory 设置内存限额；--memory-swap 表示内存与 swap 的总额度。两者相等才表示不允许 swap；--memory-swap 0 会被视为未设置。Docker 默认不替你设定内存上限。[8]

05 / 收尾与边界

退出并清理

终端 A 输入 exit，先结束内部 shell。PID 1 退出时，内核会终止该 PID namespace 中余下的进程。没有其他引用时，新 namespace 及其中的 proc 挂载随之释放，不需要在宿主上卸载 /proc。[5]

exit

root · 在虚拟机里做 终端 B 只移除本次记录的空控制组。即使前一步设置失败、只创建了空组，这段也可清理：

sudo bash -s -- "$LAB" <<'HOST'
set -eu
lab_dir=$1
if test -f "$lab_dir/cgroup.path"; then
  cg_dir=$(cat "$lab_dir/cgroup.path")
  host_pid=$(cat "$lab_dir/host.pid")
  test "$cg_dir" = "/sys/fs/cgroup/scratch-container-$host_pid"
  test -z "$(cat "$cg_dir/cgroup.procs")"
  rmdir "$cg_dir"
  rm -- "$lab_dir/cgroup.path"
fi
HOST

预期（未实测）：空组被移除；若仍有成员或子组，命令停止，先检查终端 A 是否已退出，不强删或迁移不明进程。文件目录 $LAB、归档和镜像仍保留供核对；确认退出且没有残留挂载后，可从虚拟机文件管理器以管理员权限删除这个明确路径，或直接丢弃实验虚拟机。

06 / 检索练习

记住三条线

• 文件线：rootfs 有程序及依赖，chroot 选择新的路径根。
• 视图线：unshare 创建 namespace；新的 procfs 配合 PID 视图供 ps 读取。
• 资源线：cgroup 先写限额，再核对成员；网络隔离和内存限制各自独立。
• 三条线都由共享内核实现；实验 root 没有变成低权限用户。

来源

核对日期：2026-11-03。Docker 行为以官方文档为准；Linux 机制与控制文件以 man 页及内核文档为准。实验等待虚拟机实测。

1. Docker：docker container export — 文件归档、卷不随 export 导出。
2. Docker：docker container create — 创建可写层、创建后尚未启动。
3. util-linux：unshare(1) — namespace、fork 与挂载传播参数。
4. Linux：proc_pid_stat(5) — stat 第一字段是 PID。
5. Linux：pid_namespaces(7) — PID 1、procfs 视图和退出行为。
6. Docker：docker container run — hostname、网络模式和启动参数。
7. Linux 内核：Control Group v2 — cgroup.procs、memory.max、memory.swap.max、进程继承与内存记账。
8. Docker：Resource constraints — 默认无资源约束、--memory 与 --memory-swap 的关系。
9. Linux：chroot(2) — 路径根的含义及安全边界。
10. Docker：Seccomp security profiles — 默认系统调用过滤策略。