跳转至

容器是什么,为什么要用 — 全书开篇

这一章讲三件事: 容器这个概念到底是怎么来的(一个运输类比); 它凭什么比上一代办法(虚拟机)强;以及 Docker 这家公司、这套技术今天长什么样。 读完你会拿到全书的起点——后面十九章都在回答这一章提出来的一个问题: 标准化封装之后,怎么把这箱子用得又快又安全。

1. 先看现象:软件交付里的"搬运"一直是个麻烦

开发把程序写完,交给运维去服务器上装。听起来简单,书里描写了它实际的样子:

开发者交出应用,运气好能附一份"还算准确"的安装文档;一个企业里许多团队做不同的应用, 都要装在同一批生产服务器上,每个应用有自己的框架和库, 两个应用可能用同一个框架的不同版本,而这俩版本未必互相兼容1。 运维"装一个新版本"渐渐变成一次要计划好几个月的独立项目。

书里给这个现象起了名字:软件供应链摩擦(friction)。

摩擦的意思是:货本身没坏,是搬运、换装、对不上的环节在持续消耗时间和人力。 这一章的主线例子,就是把这个"搬运"问题从头到尾走一遍,先看物理世界是怎么解决同类问题的。

2. 顶层全景:一条从苹果到服务器的推理链

原书的教法是先讲运输史,再逐格映射到软件。我们把这条链一次画出来:

  农场主的苹果 ──马车──▶ 火车站 ──装卸──▶ 火车 ──装卸──▶ 港口 ──装卸──▶ 船
      │ 每种货有自己的包装,每次转运都要重新装卸,还会被偷、被碰坏
      ▼
  标准化铁箱出现后:货主负责装箱 → 箱子尺寸全球统一 →
  吊车、卡车、火车、轮船全部按箱设计 → 承运人永远不必开箱
      │  原书类比的核心:箱子是黑盒,全球统一尺寸,装卸工具一次投资永久复用
      ▼
  映射到软件:开发者把应用 + 依赖打进容器 → 容器是全球统一标准的黑盒 →
  测试者、运维用同一套工具对待所有容器 → "Build, ship, and run anywhere"[^2]

  图说:左边是原书讲的运输集装箱故事,右边是它映射过去的软件交付链。
  每一格都对应下一节的一个论点。

下面第 3 节按这条链的每一格展开:先讲运输类比(3.1),再讲软件一侧的摩擦与 VM 的不足(3.2、3.3), 然后是容器的安全论据(3.4)、对三类人的好处(3.5),最后交代 Docker 的家底(3.6、3.7)和新动向(3.8)。

3. 核心原理

3.1 运输集装箱:一个铁箱为什么改变了世界

主线例子的前半段,照原书的讲法走一遍。

几百年来,货物运输的麻烦不在"运",而在转运:种苹果的农场主把苹果装上马车, 拉到中央火车站,卸下来;和别的农场主的苹果混在一起装上火车; 到了港口再卸一次,装进船舱3。每个环节都有三个损耗:

损耗 书里对应的描述
每次转运都要重新装卸 "每种产品有自己的包装,必须按自己的方式处理"3
散货容易被偷 "不道德的工人偷窃"的风险3
容易在搬运中损坏 货物"在处理过程中受损"3

集装箱的出现把这三件事一起解决了。它的关键不是"箱子",而是"标准尺寸": 没有全世界统一的长宽高,整套体系根本不成立。统一之后:

  • 货主自己负责装箱(他们知道怎么装自己的货);
  • 承运人把箱子当黑盒——"不关心、也不该关心里面是什么"4;
  • 吊车只需要设计一种,就能处理此后所有箱子;
  • 卡车、火车、轮船也全部围绕箱子标准化4。

原书特意点明:选这个类比是有预谋的,软件容器在软件供应链里扮演的角色, 和运输集装箱在实体货物流通里的角色完全相同5。这就是本书对"容器是什么"的第一层回答: 一个全球统一标准、对使用者透明、装什么都行的封装体。

3.2 翻译过来:容器装的是应用加它的全部依赖

现在把类比落到软件。书里说的容器,装的东西有三样:应用本身、它的框架、它的库和配置6。 开发者把这三样打进容器,交给测试或运维;对测试和运维来说,容器是标准化的黑盒—— 一个容器能在服务器上跑,其他容器也应该能跑(书里也承认存在少数边缘情况)6。

Docker 给这件事起的口号是 "Build, ship, and run anywhere"(构建、运输、随处运行)6。 注意这个口号的重心在 anywhere:同一个黑盒,开发者的笔记本上、测试机、生产服务器, 行为应当一致——3.5 节会看到这直接改写了几类人的日常工作。

3.3 为什么虚拟机不够轻:一条船运一卡车香蕉

容器不是凭空出现的,上一代办法是虚拟机(VM): 一台物理服务器上虚拟出多台"完整电脑",每个应用独占一台虚拟机,兼容性问题就此消失7。

但书里打了一个很狠的比方:虚拟机自己就是个"重量级野兽"—— 每台虚拟机里都装着一整套操作系统(Linux 或 Windows Server),而这一切只为跑一个应用, "就像用一整条船去运一卡车香蕉,太浪费了,不可能有利可图"7。

这里要量化一下浪费在哪。虚拟机每多跑一个应用,就要多付出一整份操作系统的开销: 内核、系统服务、内存占用、启动时间、补丁维护。容器省掉的正是这一整份"为单个应用陪跑的 OS"—— 它不是模拟一台电脑,而是直接住在宿主机的同一个 Linux 内核上(下一节讲靠什么隔开)。 结果就是:一台开发笔记本上同时跑十几个容器很常见,同时跑十几台虚拟机基本不可能。

3.4 容器的三条安全论据:隔离、配额、不可变

书里引用了一份 Gartner 的报告,结论是容器里跑的应用比不在容器里的同款应用更安全8。 注意这是作者转引,原书没给出报告的具体出处——我们把"Gartner 确实这么说过"当作作者引用的说法, 证据强度标在 §4。支撑这条结论的机制有三个:

  1. 沙箱隔离。 容器靠 Linux 内核的两样原语把应用互相隔开,书里点了名字: 内核命名空间(kernel namespaces,如进程 ID 命名空间、网络命名空间)给每个容器一份" private 的系统视图"; 控制组(cgroups)给每个容器划资源配额8。这两个词是全书承重词,先记名字: 命名空间管"看得见什么",控制组管"最多用多少"。第 03 章讲透它们。
  2. 防"吵邻居"。 没有配额时,一个失控的应用可以吃掉整台服务器的资源、饿死其他应用 (书里的原话是 noisy-neighbor,"吵邻居"问题);cgroup 的作用就是给每个容器封顶8。
  3. 镜像不可变 + 可扫描。 容器镜像是不可变的(这个词的确切意思第 04 章讲), 带来的直接好处是:可以对一批内容不会变的文件系统地扫描已知漏洞(CVE, 即"公共漏洞与暴露"的编号清单),还能用内容信任(content trust)机制确认镜像作者的身份、 防止运输途中被篡改(即防中间人攻击)8。

3.5 受益的三种人:开发者、运维,和公司账本

书里按角色算了三笔账:

开发者得到一台"生产级"笔记本。任何应用能容器化,数据库也能—— 原书举的例子是 Oracle:"装过 Oracle 数据库的人都知道那有多不容易、多占地方"9。 用容器,一条命令起一个完整的关系型数据库(以表的形式存数据、用 SQL 语言查询的那类数据库,测完删掉,电脑上不留一丝痕迹9。

运维终于可以只管自己擅长的事。当所有应用都容器化,每台服务器就只是"又一个 Docker 主机": 上面不用装任何特殊的库或框架,只要操作系统加容器运行时; 运维也不必再懂每个应用的内部——应用是自包含的黑盒10。

公司账本上的数字最硬(这也是全章最该记住的一组数):

指标 容器化传统应用 + 全自动供应链之后
关键应用的维护成本 降低 50% 到 60%
新版本之间的间隔时间 缩短最多 90%

这两个数字书里明确说是大型企业客户在 DockerCon 2018 和 2019 上公开披露的11。 参照物:上一行"间隔缩短 90%"的意思是,原来三个月一发的应用,同口径下变成约九天一发。 (换算是我们做的算术,原书只给了百分比。)

3.6 Docker 的家底:Moby、containerd、runc 与产品线

这一节交代"Docker"这个词背后其实有公司、有开源共同体、有一堆产品,名字容易混。

先说为什么有个 Moby。 最早的 Docker Engine 是单体软件,里面什么都有:运行时、网络库、 REST API、命令行。别家(比如 Kubernetes、Red Hat)只拿其中一部分用—— Kubernetes 不用 Docker 的网络库自己另搞一套,Red Hat 给旧版 Engine 打非官方补丁还照样叫 Docker12。 Docker 公司于是决定把开源部分和商业部分切开,顺便防止竞争对手白用"Docker"这个名字—— 这就是 Moby 项目的由来:它是 Docker 开源组件的伞项目,组件不再带 Docker 的名字13。 Docker 自己的形容是:Moby 是一套"乐高积木",加一套拼装框架,用来组装专用容器系统14。

** donated 给 CNCF 的三件套**尤其要记住,后面章节反复用13:

组件 干什么
containerd 容器运行时的高层部分:镜像管理、网络能力、插件扩展
runc 运行时的低层部分:真正创建和管理容器进程
notary 内容信任(3.4 节那个签名校验)

再说产品线。 2019 年之前分社区版(CE,免费开源)和企业版(EE,闭源按年授权); 2019 年 Docker 把 EE 卖给了 Mirantis(企业版里包括 UCP 控制面和 DTR 镜像仓库), 自己收缩回来专心做开发者工具15。面向开发者的核心产品是 Docker Desktop—— macOS、Windows、Linux 上的桌面应用,与操作系统的虚拟化框架、网络、文件系统集成, 是在这三种系统上跑 Docker 最快最稳的方式16。Docker Hub 是找镜像、分享镜像的最大服务, 分免费个人账号和付费组织账号17。Docker Toolbox 已被官方废弃,不要再装16。

顺带一个名字辨析:Docker Swarm 是 Docker Engine 内置的编排功能,不是独立产品, 提供负载均衡、服务发现、滚动更新和多主机网络18。它在第 14 章和 Kubernetes 正面对比。

3.7 一台 Docker 主机的三层结构

书上给了一张全书的"地基图",一层一层看19:

  ┌─────────────────────────────────────────────┐
  │ Docker Engine:网络库、插件支持,对外提供 REST 接口 │
  ├─────────────────────────────────────────────┤
  │ 容器运行时:containerd(管镜像/网络/插件)          │
  │              runc(真正创建容器进程)              │
  ├─────────────────────────────────────────────┤
  │ Linux 操作系统:namespace(隔离视图)、cgroups(配额) │
  └─────────────────────────────────────────────┘

  图说:装 Docker 的电脑叫 Docker 主机。容器存在的原因在最底下一层——
  Linux 内核提供的原语;越往上越是管理和接口。

各层的分工,书里写得很清楚20:

  • Linux 内核提供原语:命名空间(如 pid 命名空间、net 命名空间)封装/沙箱化容器里的进程; 控制组限制每个容器能用的 CPU 时间和内存量,防止吵邻居。
  • 容器运行时(containerd + runc)负责容器的整个生命周期:从注册表拉镜像、 用镜像创建容器、启动运行、应请求停止和删除。两者都是开源的,已捐赠给 CNCF。
  • Docker Engine 在运行时之上加功能:网络库、插件支持,并提供一个 REST 接口, 所有容器操作都能通过这个接口自动化;我们常用的 docker 命令行只是这个 REST 接口的 一个客户端20。

这个分层解释了一件后面会反复遇到的事:为什么 Kubernetes 当年能"甩掉" Docker—— 它只需要最底下两层(符合 CRI 标准的运行时),不需要上面的 Docker Engine(第 14 章展开)。

3.8 2022 年以来的新动向:安全成了主线

原书上一版写于 2022 年,这一版专门用一节盘点生态变化,四条脉络21:

  1. 供应链安全 deepening。 签名与验签工具(Notary v2、Cosign)进入真实生产管道; 构建时生成 SBOM(软件物料清单:镜像里到底装了哪些库、什么版本的"配料表") 成为主流——书里举例说,有 SBOM 才能在新漏洞爆出(如 log4j)时快速排查影响面21。
  2. Kubernetes 调试成熟化。 临时容器(ephemeral containers): 给一个正在生产环境运行的 Pod 现场塞进一个短命诊断容器(装着 curl、netcat 等工具), 不重建、不停机就能排查21。
  3. Docker Desktop 扩展市场。 2022 年中起可一键装第三方扩展,比如在构建本地镜像时 直接跑 Snyk/Trivy 漏洞扫描,把反馈环提前到代码进仓库之前21。
  4. 资源管理进化。 cgroup v2 在 2022 年前后锁定为 Docker 稳定支持; rootless 模式(容器运行时本身不以 root 权限跑)从"实验性"变成 安全敏感企业敢上生产的成熟度21。

这四条的共同指向,书里总结得很直白:容器世界不再围绕单个 Docker Engine 转, 而是一套覆盖"更安全的构建、实时的分布式调试"的快速演化工具链; 容器不再只是开发者顺手,而是韧性、可审计、安全系统的基石22。

4. 作者的判断与证据

把这一章的论断按"证据强度"分三档,读的时候心里要有数:

论断 证据情况
容器 = 封装受限的进程,靠 namespace/cgroup 隔离 机制性事实,后文各章展开验证19
大企业容器化后维护成本降 50–60%、发布间隔缩 90% 作者称来自 DockerCon 2018/2019 客户公开披露,无书面出处可查11
容器中的应用比非容器更安全(Gartner) 作者转引 Gartner"一份已发布的报告",未给报告名和链接8
"如果容器能跑一个就能跑所有"(除边缘情况) 作者明说是"实际上是真的,除了一些总是存在的边缘情况"6

值得注意作者的诚实:他没有说容器是银弹,边缘情况被点名承认; 利益相关处也写得明白——他引用的 ROI 数字出自 Docker 自家大会的客户案例。

5. 边界与局限

  • 这一章全是概念,没有一行命令。 "容器跑起来什么样"要到第 03 章才见真章; namespace/cgroup 在此只给了名字。
  • 类比止步于"标准化封装"。 运输集装箱不涉及"应用之间抢资源""镜像分层"这类软件特有命题, 类比帮不上,得靠后面的机制章节。
  • ROI 数字的适用面窄。 50–60%、90% 说的是"传统应用容器化 + 全自动供应链"的大企业场景; 一个新写的云原生小应用从头就容器化,拿不到同口径的降幅。
  • 新动向一节是 2026 年初的快照。 签名/SBOM/rootless 的工具链版本迭代极快, 具体工具名(Notary v2、Cosign、Syft)以原书成书时为准;方向(供应链透明化)比工具名单稳定。

6. 可带走的

  1. 容器 = 标准化封装体,类比运输集装箱:统一标准、对承运人透明、 装卸工具一次投资永久复用;Docker 的口号是 "Build, ship, and run anywhere"6。
  2. 容器不是轻量虚拟机:VM 每应用陪跑一整份 OS,容器与宿主机共享内核, 靠 namespace(隔离视图)+ cgroup(资源配额)隔开——这是全书的地基19。
  3. 安全红利三件套:沙箱隔离、防吵邻居、不可变镜像可扫描 + 内容信任8。
  4. 记住数字的参照系:维护成本 −50~60%、发布间隔 −90%,是大企业传统应用容器化后的口径11。
  5. Docker 家底:Engine = 网络/插件/REST 接口;运行时 = containerd(高层)+ runc(低层); Moby 是开源组件伞;EE 2019 年卖给 Mirantis;Desktop 是开发者入口;Hub 是镜像市场131617。
  6. 三层架构图(Linux → 运行时 → Engine)解释了 Kubernetes 为何能甩掉 Docker Engine20。
  7. 2022 年后的主线是安全:签名、SBOM、临时容器、cgroup v2、rootless—— 趋势方向比工具名单更值得记21。
  8. Swarm 是 Engine 内置编排,不是独立产品——第 14 章会拿它和 Kubernetes 对比18。

7. 原文地图

主题 原书章 原文位置
运输集装箱类比、标准尺寸、黑盒 What are containers? text/14-fm-what-are-containers.txt:42(搜「metallic box」) · text/14-fm-what-are-containers.txt:48(搜「black box」) · text/14-fm-what-are-containers.txt:65(搜「fulfill the exact same role」)
开发者交运维、依赖冲突、摩擦 What are containers? text/14-fm-what-are-containers.txt:69(搜「hand that application over」) · text/14-fm-what-are-containers.txt:81(搜「friction」)
VM 太重、"一船香蕉" Why are containers important? text/15-fm-why-are-containers-important.txt:8(搜「heavy beasts」) · text/15-fm-why-are-containers-important.txt:11(搜「truckload of bananas」)
Build, ship, run anywhere Why are containers important? text/15-fm-why-are-containers-important.txt:23(搜「Build, ship, and run anywhere」)
Gartner、namespace、cgroups、内容信任 Why are containers important? text/15-fm-why-are-containers-important.txt:34(搜「Gartner」) · text/15-fm-why-are-containers-important.txt:37(搜「namespaces」) · text/15-fm-why-are-containers-important.txt:45(搜「content trust」)
笔记本上跑 Oracle、运维标准化 What is the benefit of using containers for me or my company? text/16-fm-what-is-the-benefit-of-using-containers-for-me-o.txt:7(搜「Oracle」) · text/16-fm-what-is-the-benefit-of-using-containers-for-me-o.txt:17(搜「just another Docker host」)
维护成本降 50–60%、发布间隔降 90% What is the benefit of using containers for me or my company? text/16-fm-what-is-the-benefit-of-using-containers-for-me-o.txt:38(搜「50% to 60%」) · text/16-fm-what-is-the-benefit-of-using-containers-for-me-o.txt:39(搜「90%」)
Moby 的由来、乐高引用、CNCF 捐赠 Docker products text/17-fm-docker-products.txt:8(搜「main reason the Moby」) · text/17-fm-docker-products.txt:24(搜「Lego set」) · text/17-fm-docker-products.txt:17(搜「notary, containerd, and runc」)
CE/EE、卖给 Mirantis、Desktop、Toolbox 废弃 Docker products text/17-fm-docker-products.txt:36(搜「sold it to Mirantis」) · text/17-fm-docker-products.txt:43(搜「complete development environment」) · text/17-fm-docker-products.txt:47(搜「deprecated」)
Docker Hub、EE 细节、Swarm 定位 Container architecture text/18-fm-container-architecture.txt:2(搜「most popular service」) · text/18-fm-container-architecture.txt:16(搜「Universal Control Plane」) · text/18-fm-container-architecture.txt:30(搜「not a separate product」)
三层架构、namespace/cgroup 分工 Container architecture text/18-fm-container-architecture.txt:44(搜「three essential parts」) · text/18-fm-container-architecture.txt:55(搜「pid」) · text/18-fm-container-architecture.txt:58(搜「noisy-neighbor」)
containerd/runc 分工、REST 接口、CLI 是客户端 Container architecture text/18-fm-container-architecture.txt:62(搜「containerd and runc」) · text/18-fm-container-architecture.txt:72(搜「REST interface」)
签名/SBOM、临时容器、扩展市场、cgroup v2/rootless What's new in containerization text/19-fm-what-s-new-in-containerization.txt:14(搜「Notary v2」) · text/19-fm-what-s-new-in-containerization.txt:22(搜「SBOMs」) · text/19-fm-what-s-new-in-containerization.txt:34(搜「ephemeral containers」) · text/19-fm-what-s-new-in-containerization.txt:60(搜「cgroups v2」) · text/19-fm-what-s-new-in-containerization.txt:66(搜「Rootless modes」)

  1. 出处:「What are containers?」第 68–76 段(text/14-fm-what-are-containers.txt:69,搜「hand that application over」;:74,搜「different versions」)。原文:企业里许多开发团队做不同的应用,都要装在同一批生产服务器上;"Sometimes, two applications use the same framework but in different versions that might or might not be compatible with each other"。 ↩

  2. 出处:「What are containers?」第 64–66 段(text/14-fm-what-are-containers.txt:65,搜「fulfill the exact same role」)。原文:"I chose this analogy purposefully since the software containers that we are going to introduce here fulfill the exact same role in the so-called software supply chain as shipping containers do in the supply chain of physical goods." ↩

  3. 出处:「What are containers?」第 19–36 段(text/14-fm-what-are-containers.txt:29,搜「cart full of apples」;:33,搜「complex and tedious process」;:35,搜「stolen」)。 ↩↩↩↩

  4. 出处:「What are containers?」第 48–58 段(text/14-fm-what-are-containers.txt:48,搜「just a black box」;:52,搜「standardized tools」)。 ↩↩

  5. 出处:同2。 ↩

  6. 出处:「Why are containers important?」第 16–23 段(text/15-fm-why-are-containers-important.txt:19,搜「black box」;:21,搜「edge cases」;:23,搜「Build, ship, and run anywhere」)。原文:"For testers and operations engineers, a container is just a black box. It is a standardized black box, though." ↩↩↩↩↩

  7. 出处:「Why are containers important?」第 4–15 段(text/15-fm-why-are-containers-important.txt:8,搜「heavy beasts」;:11,搜「truckload of bananas」;:15,搜「holy grail」)。 ↩↩

  8. 出处:「Why are containers important?」第 30–49 段(text/15-fm-why-are-containers-important.txt:34,搜「Gartner」;:35,搜「kernel namespaces」;:39,搜「noisy-neighbor」;:40,搜「immutable」;:45,搜「content trust」)。Gartner 结论的原文:"In a published report, Gartner found that applications running in a container are more secure than their counterparts that are not running in a container." 原书未给出该报告的名称或链接。 ↩↩↩↩↩↩

  9. 出处:「What is the benefit of using containers for me or my company?」第 4–13 段(text/16-fm-what-is-the-benefit-of-using-containers-for-me-o.txt:7,搜「Oracle」;:11,搜「without leaving a single trace」)。 ↩↩

  10. 出处:「What is the benefit of using containers for me or my company?」第 14–24 段(text/16-fm-what-is-the-benefit-of-using-containers-for-me-o.txt:17,搜「just another Docker host」;:22,搜「black boxes」)。 ↩

  11. 出处:「What is the benefit of using containers for me or my company?」第 34–41 段(text/16-fm-what-is-the-benefit-of-using-containers-for-me-o.txt:38,搜「50% to 60%」;:39,搜「90%」)。同组数字的更详细出处(说明披露场合为 DockerCon 2018/2019)见「Sharing or shipping images」(text/55-fm-sharing-or-shipping-images.txt:4,搜「DockerCon 2018」)。 ↩↩↩

  12. 出处:「Docker products」第 1–5 段(text/17-fm-docker-products.txt:1,搜「their own products」;:3,搜「unofficial patches」)。 ↩

  13. 出处:「Docker products」第 6–21 段(text/17-fm-docker-products.txt:8,搜「main reason the Moby」;:15,搜「notary, containerd, and runc」;:17,搜「container runtime」)。 ↩↩↩

  14. 出处:「Docker products」第 23–25 段(text/17-fm-docker-products.txt:24,搜「Lego set」)。 ↩

  15. 出处:「Docker products」第 28–37 段(text/17-fm-docker-products.txt:36,搜「sold it to Mirantis」);「Container architecture」第 12–24 段(text/18-fm-container-architecture.txt:12,搜「November 2019」)。 ↩

  16. 出处:「Docker products」第 39–48 段(text/17-fm-docker-products.txt:43,搜「complete development environment」;:47,搜「deprecated」)。 ↩↩↩

  17. 出处:「Container architecture」第 1–9 段(text/18-fm-container-architecture.txt:2,搜「most popular service」;:6,搜「commercial licenses」)。 ↩↩

  18. 出处:「Container architecture」第 25–34 段(text/18-fm-container-architecture.txt:30,搜「not a separate product」;:31,搜「rolling updates」)。 ↩↩

  19. 出处:「Container architecture」第 36–60 段(text/18-fm-container-architecture.txt:44,搜「three essential parts」;:55,搜「namespaces」;:58,搜「noisy-neighbor」)。 ↩↩↩

  20. 出处:「Container architecture」第 62–75 段(text/18-fm-container-architecture.txt:62,搜「containerd and runc」;:67,搜「life cycle」;:72,搜「REST interface」)。 ↩↩↩

  21. 出处:「What's new in containerization」第 8–72 段(text/19-fm-what-s-new-in-containerization.txt:14,搜「Notary v2」;:22,搜「SBOMs」;:34,搜「ephemeral containers」;:42,搜「Extensions Marketplace」;:60,搜「cgroups v2」;:66,搜「Rootless modes」)。 ↩↩↩↩↩↩

  22. 出处:「What's new in containerization」第 74–85 段(text/19-fm-what-s-new-in-containerization.txt:81,搜「cornerstones」)。 ↩