系统与基础设施blog.jessfraz.com
容器、Zone、Jail 与虚拟机：有何不同
Containers vs. Zones vs. Jails vs. VMs
2017 — 2020，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章比较 Linux 容器、Solaris Zones、FreeBSD Jails 和虚拟机这四种隔离/虚拟化方案，梳理它们的设计差异。文章的核心观点是：所谓“容器”并不是一个独立的系统对象，而是 Linux namespaces 与 cgroups 等机制的组合；Zones 和 Jails 则更接近操作系统内建的隔离抽象。
为什么经久不衰：多年后开发者仍常把容器当成“轻量 VM”，这篇对比能帮助澄清底层隔离机制，以及安全性与复杂度之间的取舍。
HN 评论精选
Jails 与 Linux namespaces 相似，但默认提供安全基线，并通过进程表里的 JID 实现隔离，无需复杂的 UID/PID 映射。
Jails 实际上和 Linux namespaces/unshare 非常相似，比这个讨论串里大多数人以为的相似得多。区别在于：使用 namespaces 时，你从零隔离开始，再按需添加 mount、PID、网络、hostname、user、IPC 等命名空间；使用 jail 时，你从一个合理的安全基线开始，进程、用户、POSIX IPC 和挂载默认隔离，但文件系统根、网络、SysV IPC 等仍可灵活配置。与 namespace 靠奇怪的 UID 映射实现用户隔离不同，jail 本质上是进程表里多出的一列 JID（宿主为 JID 0），系统调用会直接考虑 JID，无需复杂映射。顺便说，你完全可以在 jail 里跑 X11 应用，甚至硬件加速图形。
floatboth查看英文原文
Jails are actually very similar to Linux namespaces / unshare. Much more similar than most people in this thread think. There's one difference though: In namespaces, you start with no isolation, from zero, and you add whatever you want — mount, PID, network, hostname, user, IPC namespaces. In jails, you start with a reasonable secure baseline — processes, users, POSIX IPC and mounts are always isolated. But! You can isolate the filesystem root — or not (by specifying /). You can keep the host networking or restrict IP addresses or create a virtual interface. You can isolate SysV IPC (yay postgres!) — or keep the host IPC namespace, or ban IPC outright. See? The interesting parts are still flexible! Okay, not as flexible as "sharing PIDs with one jail and IPC with another", but still. So unlike namespaces, where user isolation is done with weird UID mapping ("uid 1 in the container is uid 1000001 outside") and PID isolation I don't even know how, jails are at their core just one more column in the process table. PID, UID, and now JID (Jail ID). (The host is JID 0.) No need for weird mappings, the system just takes JID into account when answering system calls. By the way, you definitely can run X11 apps in a jail :) Even with hardware accelerated graphics (just allow /dev/dri in your devfs ruleset). P.S. one area where Linux did something years before FreeBSD is resource accounting and limits (cgroups). FreeBSD's answer is simple and pleasant to use though: https://www.freebsd.org/cgi/man.cgi?rctl
容器只是独立内核机制的有用组合；许多开发者并不了解这些机制，因而也无法在容器之外利用它们。
我不完全同意“复杂度==Bug”那一节，但主要观点很准确：容器是一等公民，而它其实是有用的独立机制组合。现实影响是，我聊过的大多数人不知道这些机制存在。他们知道容器，但对底层概念没有根本理解——也不能怪他们，它就是那样被营销的。例如 pid_namespaces 和 subreapers 对管理进程子树非常有用：pid_namespaces 确保父进程出事后子进程被终止，subreapers 解决父进程死亡后孙进程被挂到 init 的问题。这些特性对容器有用，但不只对容器有用。可开发者不会使用他们根本不知道存在的系统调用。
deathanatos查看英文原文
While I'm not sure I agree entirely with the "Complexity == Bugs" section, the main point, that containers are first-class citizens but a (useful) combination of independent mechanisms is spot-on. This has real repercussions: most people I've spoken do don't know these things exist. They know containers do, they have a very vague idea what containers are, but they have no fundamental understanding of the underlying concepts. (And who can blame them? Really, it was marketed that way.) For example, pid_namespaces, and subreapers are an awesome feature¹, and are extremely handy if you have a daemon that needs to keep track of a set of child jobs that may or may not be well behaved. pid_namespaces ensure that if something bad happens to the parent, the children are terminated; they don't ignorantly continue executing after being reparented to init. Subreapers (if a parent dies, reparent the children to this process, not init) solve the problem of grandchildren getting orphaned to init if the parent dies. Both excellent features for managing subtrees of processes, which is why they're useful for containers. Just not only containers. But developers aren't going to take advantage of syscalls they have no idea that they exist, of course. ¹although I wish someone could tell me why pid_namespaces are root-only: what's the security risk of allowing unprivileged users to create pid_namespaces?
Linux 容器是 namespaces/cgroups 加安全补丁的拼装，设计整合度不如 Solaris Zones，并带来持续的安全风险。
作为普通用户：Linux 容器更像围绕 namespaces 和 cgroups 的胶带，而不是乐高。想在 cgroup 里看到真实内存用量，就得挂 FUSE 文件系统；还得用 AppArmor 和 SELinux 去补内核不关心的洞。Solaris Zones 更像有设计的产物，是 FreeBSD Jails 的演化。也许这是死星 vs 乐高，但在真空里，死星大概比用胶带加固的乐高飞船撑得更久。我对做这些工作的人极其尊重，但作为用户，Linux 世界缺少更大概念上的设计和实现令人难过；几年前就能看到警告说，这条路会充满安全漏洞。
nisa查看英文原文
As a lowly user¹: linux containers are more like gaffer tape around namespaces and cgroups than something like lego. You want real memory usage in your cgroup? let's mount some fuse filesystem: https://github.com/lxc/lxcfs - https://www.cvedetails.com/vulnerability-list/vendor_id-4781/product_id-32696/Canonical-Lxcfs.html We have to gaffer tape with AppArmor and SELinux to fix all the holes the kernel doesn't care about: https://github.com/lxc/lxc/blob/master/config/apparmor/container-rules Solaris Zones are more designed and an evolution from FreeBSD Jails. Okay, the military likely paid for that: https://blogs.oracle.com/darren/entry/overview_of_solaris_kernel_zones Maybe it's Deathstar vs. Lego. But I assume you can survive a lot longer in a Deathstar in vacuum than in your Lego spaceship hardened by gaffa tape. 1: I have uttermost respect for anyone working on this stuff. No offense, but as a user sometimes a lack of design and implementation of bigger concepts (not as in more code, but better design, more secure) in the Linux world is sad. It's probably the only way to move forward but you could read on @grsecurity Twitter years ago that this idea is going to be a fun ride full of security bugs. There might be a better way?
许多开发者把容器神秘化并误当成轻量 VM，对 namespaces/cgroups 及真实开销缺乏理解。
> “容器”只是人们用来描述 Linux namespaces 和 cgroups 组合的术语。Linux namespaces 和 cgroups 才是一等对象，不是容器。阿门。略相关：我遇到过的大多数开发者不理解“容器”是什么，它周围有一种魔法和神秘感，并且非常强调 Docker。相当一部分人担心“容器开销”和“可扩展性问题”，却通常无法解释开销是什么、可能由什么造成；不提存储或网络影响，只提 CPU，而且往往没有先测量性能。继续追问时，我最常得到的感觉是：他们认为容器“像 VM，但更轻”。到今天，我只听人提过一次 cgroups。
outworlder查看英文原文
> A “container” is just a term people use to describe a combination of Linux namespaces and cgroups. Linux namespaces and cgroups ARE first class objects. NOT containers. Amen. Somewhat tangential note: most developers I have met do not understand what a 'container' is. There's an aura of magic and mystique around them. And a heavy emphasis on Docker. A sizable fraction will be concerned about 'container overhead' (and "scalability issues") when asked to move workloads to containers. They are usually not able to explain what the overhead would be, and what could potentially be causing it. No mention to storage, or how networking would be impacted, just CPU. That's usually said without measuring the actual performance first. When I press further, what I most commonly get is the sense that they believe that containers are "like VMs, but lighter"(also, I've been told that, literally, a few times, specially when interviewing candidates). To this day, I've heard CGroups being mentioned only once. I wonder if I'm stuck in the wrong bubble, or if this is widespread.
历次讨论
同类还值得读
TTY 揭秘（2008）
The TTY demystified (2008)
经典文章深入剖析了 Unix/Linux 中 TTY 子系统的工作原理，包括线路规程、终端驱动、信号与控制字符等机制。
系统与基础设施上首页 11 次 · 2009–2025linusakesson.net编辑精选为什么 GNU grep 这么快
Why GNU grep is Fast
FreeBSD 邮件列表上一篇广为流传的帖子，解释 GNU grep 为什么快：核心在于 Boyer-Moore 字符串搜索算法配合精心优化的内部循环和 I/O，让程序在搜索时“…
系统与基础设施上首页 9 次 · 2010–2022lists.freebsd.orgXplain：为普通人讲解 X11
Xplain – Explaining X11 for the rest of us
《Xplain》是作者（HN 用户 Jasper_）写的一系列 X11 长文，用他在浏览器中重建的 X11 绘图模型做交互演示，讲解 X11 的绘图模型与窗口系统设计。
系统与基础设施上首页 6 次 · 2013–2020magcius.github.io编辑精选旋风教程：为 Linux 创建极小 ELF 可执行文件（1999）
A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux (1999)
breadbox 写于 1999 年的经典教程，主题是如何为 Linux 手工构造并裁剪出体积极小的 ELF 可执行文件。
系统与基础设施上首页 6 次 · 2007–2025muppetlabs.comPostgreSQL 内部原理
The internals of PostgreSQL
《The Internals of PostgreSQL》是一本免费在线书籍，系统讲解 PostgreSQL 的内部实现，包括查询处理、并发控制、WAL、缓冲区管理等核心机制。
系统与基础设施上首页 5 次 · 2017–2025interdb.jp编辑精选