3.1 三件套对决一体化 Docker
3.1 三件套对决一体化 Docker
本节摘要：Red Hat 容器工具家族把 Docker 单体引擎的职能拆成三件独立工具：Podman 负责容器运行与管理、Buildah 负责镜像构建、Skopeo 负责镜像传输与检查，三者共享 containers/storage 底座。本节逐个划定领地，再从安全边界、CI 形态、升级粒度三个维度对比两种模型的真实账目。
三块领地，一个底座
先把分工表立起来：
| 工具 | 领地 | 对应 Docker 里的功能 | 典型命令 |
|---|---|---|---|
| Podman | 容器与 Pod 的运行、监控、服务化 | docker run / ps / stop / stats | podman run、podman ps |
| Buildah | 镜像构建，脚本化与 Dockerfile 兼容 | docker build | buildah bud、buildah from |
| Skopeo | 镜像的远程检查、复制、格式转换 | docker pull / push（部分） | skopeo inspect、skopeo copy |
| （共享）containers/storage | 镜像层与容器可写层的存储 | /var/lib/docker | 无命令，是库 |
这张表的关键在最后一行：三件工具读写的是同一套存储。它带来一个与 Docker 完全不同的体验事实——buildah 构建完的镜像不需要"导出再导入"，podman run 直接可见；skopeo 拉到本地存储的镜像，podman 立刻能跑。镜像在这三件工具之间的流转是零拷贝的。
维度一：安全边界怎么画
一体化模型下，"能构建镜像"意味着"能驱动 dockerd"，进一步意味着"接近宿主机 root"（第 1.1 节的 socket 越权链条）。家族模型下构建是独立工具：Buildah 以普通用户身份在用户命名空间里构建，全程无特权参与。落到 CI 就是两种截然不同的构建容器：
# 一体化模型的 CI 构建容器，需要挂 socket（第 1.1 节已批判过） # docker run -v /var/run/docker.sock:/var/run/docker.sock ... # 家族模型的 CI 构建容器：什么特殊权限都不挂 podman run --rm -v "$PWD:/workspace:Z" builder:latest \ buildah bud -f /workspace/Dockerfile -t myapp:ci /workspace # 构建发生在容器内的用户命名空间里， # 能造成的最大破坏 = CI 用户的权限范围
-v ...:Z 这个后缀是 SELinux 重贴标签（第 6 章展开），先记住形态：家族模型的 CI 配置里没有一行需要特殊权限。
维度二：升级与故障粒度
单体的升级是引擎级事件：dockerd 重启，容器管理中断（第 1.1 节第一栏）。家族的升级是包级事件：升级 buildah 不影响 podman，升级 skopeo 不影响任何在跑的容器。故障同理——构建出问题就去查 buildah，不必怀疑引擎；存储出问题三个工具一起表现为"镜像异常"，因为共享底座是单点（家族模型也有单点，只是从"管理进程"变成了"存储库"——这个诚实的对称性值得记住）。
维度三：无守护进程的检查能力
Skopeo 提供了 Docker 工作流里很难顺手做到的事——不下载镜像就检查它：
# 看一个远程镜像的元数据，不拉取任何层 skopeo inspect docker://docker.io/library/nginx:alpine # 输出：创建时间、架构、环境变量、各层摘要、总大小 # "Architecture": "amd64", # "LayersData": [...]， # "Env": [...] # 只看摘要（比完整输出更适合脚本） skopeo inspect --format '{{.Name}} {{.Digest}}' \ docker://quay.io/libpod/alpine:latest # quay.io/libpod/alpine sha256:a1b2c3... # 用途：CI 里把 digest 写进构建产物，实现供应链可追溯（第 6.3 节会用）
镜像在仓库间搬运也不需要本地中转：skopeo copy docker://源 docker://目标 直接在两端之间复制层，还带格式转换（docker 格式与 OCI 格式互转）与签名同步。Docker 里等价的操作得 pull + tag + push 三步走，还要占本地磁盘。
该选谁：一个诚实的判断框架
给三个判断锚点。第一，个人开发机、团队已经深度绑定 Docker 工作流、不碰多租户——单体的心智负担最低，没有强理由换。第二，CI 流水线、共享服务器、安全审计敏感的企业环境——家族模型的无特权构建与独立升级粒度是实打实的收益。第三，混合场景（最常见的现实）——Podman 做运行时、Buildah 做构建、compose 兼容层跑本地编排，逐模块替换而不搞大爆炸迁移，第 9 章会给完整路线。
锚点之外再补一个常被忽略的评估维度：团队的组织方式。工具链的拆分粒度与权限的分配粒度是同构的。如果一个平台团队想做到"构建环境归构建团队管、运行时归运维团队管、镜像分发归安全团队管"，家族模型天然支持这种分权——每个团队拿走一件工具的配置权与升级节奏；单体模型下这些职能挤在一个引擎里，分权只能靠流程约定而不是物理边界。反过来，一两个人的初创团队没有分权需求，拆开的工具反而多两份学习成本。评估工具链选型时把"未来半年团队会怎么分工"放进问题清单，结论往往比单纯比技术特性更贴合实际。
本节要点回顾
- 三件套 = 一体化引擎的职能拆解：运行、构建、传输各归一个工具
- 共享存储是粘合剂：镜像在三工具间零拷贝流转
- 安全边界不同源：单体把权力集中给 root daemon，家族还给用户进程
- 升级与故障粒度不同：引擎级事件 vs 包级事件；存储库是家族模型自己的单点
- skopeo 的独门能力：免拉取检查、免中转复制、格式转换
- 选型三锚点：个人机留单体；CI 与多租户选家族；混合场景逐模块替换