容器运行、网络与存储：从概念到可验证实践
0. 元信息
- 主题路径：
docs/topics/docker-basics/subtopics/container-runtime-network-storage/README.md - 主分类：工程技术
- 辅助分类：安全与可靠性
- 适合对象：完成 Linux 基础并按父主题路线学习的开发者
- 建议周期：5～8 天，每天 1.5～2 小时
- 前置知识：image-build-and-distribution
- 最终目标：能独立完成并解释 生命周期、namespace、cgroup、signal、bridge、DNS、port、volume 与 bind mount 的实验，留下配置、命令和输出证据
1. 学习路线
概念与对象 → 最小正常实验 → inspect/日志验证 → 边界与失败实验 → 自动化配置 → 交付说明
2. 阶段周数分配
精简子主题不固定周数。按概念、正常路径、失败路径、综合实验四段推进，共 5～8 天。
3. 九阶段表
| 阶段 | 核心知识 | 实践产出 | 可观察学会标准 |
|---|---|---|---|
| 1 | 术语与对象边界 | 对象关系图 | 不混淆声明、制品与运行状态 |
| 2 | 默认行为 | 最小正常实验 | 能从空环境重现 |
| 3 | 配置语法 | 可版本化配置 | config/inspect 与预期一致 |
| 4 | 生命周期 | 状态变化记录 | 能解释 create/start/stop/remove 影响 |
| 5 | 隔离与依赖 | 拓扑或 mount 图 | 能指出宿主与容器边界 |
| 6 | 错误路径 | 至少四类故障 | 结论指向日志、事件或状态证据 |
| 7 | 安全与资源 | 最小权限配置 | 默认权限和 limit 有解释 |
| 8 | 可重复性 | 清理后重建记录 | 第三方按 README 可重现 |
| 9 | 综合实验 | 可运行交付物 | 能演示、排错、恢复与清理 |
4. 第一周任务
精简子主题省略逐日表。每天只引入一个变量；先跑正常路径，再做四类失败实验。
5. 阶段通用验收
采用父主题 §5；本页额外要求保存版本、完整配置、关键输出和清理命令。
6. 最终验收
完成一份可运行配置、至少四个失败案例、一次清理后重建，并用 10 分钟解释关键边界。
7. 综合项目
把本页产出合入父主题 Compose Web 应用。单独交付时，提供最小 demo、README、测试记录与 notes/retrospective.md。
本主题贡献
容器运行层最容易翻车的不是 docker run 命令本身，而是 namespace / cgroup / signal / bridge DNS / volume 数据五个交叉边界。本子主题专门补齐”为什么 --cap-drop=ALL 不够”、“为什么 SIGTERM 没到应用”、“为什么 volume 数据会被 prune 一键带走”三个常被跳过的事实，把运行时从”能跑”推到”可排障”。
3 职责
- 用 namespace / cgroup / capability 三件套证明隔离真生效：
/proc/1/status看 Cap、docker stats看 memory、host kernel 看 cgroup path。 - 用
--read-only/--tmpfs/--security-opt seccomp=把最小权限写进 run 命令而非写在文档里，给出 seccomp profile 模板。 - 用 volume + bind mount 区分应用数据与配置数据，定 backup/restore SOP（停机 tar、冷拷贝、LVM snapshot 三选一），并配置 healthcheck 作为 readiness 信号。
4 交付物
- 一份
docker run模板（--cap-drop=ALL --cap-add=NET_BIND_SERVICE --security-opt no-new-privileges --read-only），附/proc/1/status输出对照与 capability 缩减前后对比。 - 一份 user-defined bridge 网络（DNS + 服务名解析）的两容器 demo，附
docker network inspect与nslookup输出，证明 service name 解析来源是 Docker embedded DNS。 - 一份 volume 备份与恢复脚本（
tar+alpine容器），含备份前后 digest 与文件大小对比，证停机 tar 是 P0 兜底。 - 一份 healthcheck 配置（
HEALTHCHECK/docker inspect ... State.Health.Status），覆盖 start_period / interval / retries 三参数与 signal 转发验证。
3 指标
- 容器冷启动到 healthcheck healthy < 5 s（
docker inspect时间差）。 - OOM / crash 事件后恢复 < 30 s（
docker events --since比对，包含 restart policy 触发到 healthy 状态的时间）。 - prune / remove 误删率 0%（backup 校验 + 删前 list + 二次确认 SOP）。
Docker Docs 作主线；OCI 文档用于契约；Moby、BuildKit、containerd、runc 源码只在需要确认实现时查。复制前核对当前 LICENSE。
8. 推荐开源资料
Docker Docs 作主线；OCI 文档用于契约；Moby、BuildKit、containerd、runc 源码只在需要确认实现时查。复制前核对当前 LICENSE。
9. 学习资料汇聚（v0.3 自包含）
9.1 背景与动机
本子主题处理：掌握 run 生命周期、namespace/cgroup、端口、bridge、volume、bind mount 与数据恢复。。Docker 的易用 CLI 会隐藏多层状态。我们通过最小实验、inspect 和失败注入把对象关系变成可观察事实。
9.2 概念地图
flowchart LR
Spec[声明 / Spec] --> Engine[Docker Engine / BuildKit]
Engine --> Artifact[image / config / state]
Artifact --> Runtime[container runtime]
Runtime --> Evidence[inspect / logs / events / metrics]
Failure[故障注入] --> Runtime
Evidence --> Fix[修改与验证]
本页核心概念：生命周期、namespace、cgroup、signal、bridge、DNS、port、volume 与 bind mount。声明经过 engine 产生制品或运行状态，所有判断回到 evidence。
9.3 基础知识讲解
9.3.1 论文 / 规范
| 资料 | 用法 |
|---|---|
| OCI Image Format Specification | 核对 manifest、config 与 layer digest |
| OCI Runtime Specification | 核对 bundle、config.json 与 lifecycle |
| NIST SP 800-190 Application Container Security Guide | 建立镜像、registry、orchestrator、host 风险模型 |
9.3.2 书
| 资料 | 用法 |
|---|---|
| Brendan Burns, Designing Distributed Systems | 学 sidecar、ambassador、adapter 等容器协作模式 |
| Liz Rice, Container Security | 结合 namespace、capability、seccomp 理解隔离边界 |
| Nigel Poulton, Docker Deep Dive | 补 Docker Engine、image、network、volume 主线 |
9.3.3 博客 / 文档
| 资料 | 用法 |
|---|---|
| Docker 官方文档 | 命令、Dockerfile、Compose、BuildKit 主线 |
| OWASP Docker Security Cheat Sheet | 配置安全检查表；并延伸阅读 OWASP Docker Top 10 |
| Kubernetes The Hard Way | 由 Kelsey Hightower 维护，用手工部署理解容器编排边界 |
| Aqua Trivy | 扫 image、filesystem、SBOM 与 misconfiguration |
| Snyk Container | 对照另一套 image dependency 风险视图 |
9.3.4 人物
| 人物 | 关注点 |
|---|---|
| Solomon Hykes | Docker 项目起点与开发者体验 |
| Kelsey Hightower | Kubernetes 教学、The Hard Way 与运维实践 |
| Liz Rice | 容器运行时、安全、eBPF 与隔离边界 |
| Brendan Burns | 容器编排与分布式系统模式 |
9.3.5 方法
| 方法 | 动作 |
|---|---|
| Inspect-first | 用 docker inspect、history、diff 看真实状态，不猜 |
| Immutable build | image 构建一次，按 digest 提升到各环境 |
| Least privilege | 非 root、drop capabilities、只读文件系统、限制资源 |
| Reproducible build | 锁 base digest、依赖版本与 build context，保留 provenance |
| Failure injection | 主动停服务、断网络、损坏健康检查，观察恢复和告警 |
| Evidence-based sizing | 用 metrics 决定 CPU/memory limit，不复制默认值 |
9.4 经典问题与经典案例
| # | 问题 | 最简答案 |
|---|---|---|
| 1 | 容器为什么能看到独立 PID？ | PID namespace 提供进程视图。 |
| 2 | memory limit 超过后会怎样？ | 可能触发 cgroup OOM kill，查 inspect/events/kernel。 |
| 3 | 为什么服务名能解析？ | user-defined network 的内置 DNS 提供名称解析。 |
| 4 | volume 与 bind mount 怎么选？ | 应用数据优先 volume；需直接编辑宿主文件时 bind。 |
| 5 | SIGTERM 为什么没到应用？ | shell form 或 PID 1 转发/收割处理错误。 |
| 6 | 容器端口与发布端口区别？ | EXPOSE 是元数据，-p 才建宿主映射。 |
9.4.1 实战片段：run 生命周期、网络、volume 与备份
# 1. 启动：限制资源、只读 rootfs、临时 PID、关闭多余 capability
docker run -d --name api \
--cpus=1.0 --memory=512m --pids-limit=256 \
--read-only --tmpfs /tmp:size=64m \
--cap-drop=ALL --cap-add=NET_BIND_SERVICE \
--security-opt no-new-privileges \
-p 8080:8080 \
-e LOG_LEVEL=info \
ghcr.io/acme/api:v1
# 2. 看 PID、网络、cgroup 与健康
docker inspect --format '{{.State.Pid}} {{.NetworkSettings.IPAddress}}' api
docker top api
docker stats api --no-stream
docker events --since 10m --filter container=api
# 3. 看日志、进入容器、抓包
docker logs --tail 100 -f api
docker exec -u nonroot -it api sh
docker exec api cat /proc/1/status | grep -E 'Cap|Uid'
# 4. 用户自定义 bridge + 服务名 DNS
docker network create --driver bridge app-net
docker network connect app-net api
docker network connect app-net db
docker run -d --name db --network app-net \
-v pgdata:/var/lib/postgresql/data \
-e POSTGRES_PASSWORD=dev \
postgres:18-alpine
# 5. volume 备份与恢复（停机）
docker run --rm \
-v pgdata:/source:ro \
-v $(pwd)/backup:/backup \
alpine:3.20 \
tar czf /backup/pgdata-$(date +%F).tgz -C /source .
# 停 db，把备份解压到新 volume，再启动
docker stop db && docker run --rm \
-v pgdata-new:/target \
-v $(pwd)/backup:/backup \
alpine:3.20 \
tar xzf /backup/pgdata-2026-07-30.tgz -C /target
# 6. 抓故障时快速核对四元
docker ps -a --filter name=api
docker inspect api | jq '.[0] | {State, NetworkSettings, Mounts, HostConfig}'
9.5 学习难点
概念难点
| 难点 | 为什么会卡 | 突破路径 |
|---|---|---|
| 声明与状态 | 文件正确不代表运行状态正确 | 同时看配置渲染、inspect 和实际 I/O |
| 隔离边界 | UI 隐藏 namespace、mount、network | 画宿主、daemon、runtime、进程四层图 |
| 默认值 | 版本和平台会改变行为 | 记录版本，查官方 reference，显式写关键值 |
思维难点
| 难点 | 为什么会卡 | 突破路径 |
|---|---|---|
| 从错误文本找层级 | client、daemon、runtime、app 都能报错 | 先标错误产生者，再沿调用链检查 |
| 正常路径偏见 | 跑通一次容易误判稳定 | 端口、权限、资源、依赖各造一次故障 |
| 可变状态 | tag、container、volume 会随操作变化 | 每步记录对象 ID/digest 与前后状态 |
工程难点
| 难点 | 为什么会卡 | 突破路径 |
|---|---|---|
| 跨平台与权限 | kernel、filesystem、UID 行为不同 | 在目标平台跑验收，写明已知限制 |
| 清理与数据安全 | remove/prune 可能不可逆 | 先列对象与备份，再执行精确删除 |
| 可观测性 | 单一日志缺上下文 | 关联 inspect、events、stats、health 与应用指标 |
9.6 技术标准与接口
9.6.1 Entity
| 名称 | 发布组织 | 角色 | 状态 / 可访问性 |
|---|---|---|---|
| OCI Image Spec | Open Container Initiative | image manifest、config、layer 格式 | 开放标准，Apache-2.0 |
| OCI Runtime Spec | Open Container Initiative | bundle 与容器运行生命周期 | 开放标准，Apache-2.0 |
| containerd | CNCF | image、snapshot、container、task 管理 | 活跃，Apache-2.0 |
| runc | Open Container Initiative | OCI runtime reference implementation | 活跃，Apache-2.0 |
| CNI | CNCF | 容器网络插件接口 | 活跃，Apache-2.0 |
| CSI | CNCF | 容器编排系统存储接口 | 活跃，Apache-2.0 |
9.6.2 Scope
OCI 定义 image 与 runtime 契约，不定义完整编排。containerd 管高层生命周期，runc 执行 OCI bundle。CNI、CSI 面向编排系统；Docker bridge、volume driver 有自己的实现接口。Docker Compose 处理单机或 context 上的多服务应用，不替代 Kubernetes 的集群调度。
9.6.3 Structure
必须掌握 image manifest/config/layer、content digest、OCI bundle、config.json、namespace、cgroup、capability、seccomp、network namespace、mount、snapshotter。常用接口是 Docker CLI/API、Dockerfile、Compose Specification、registry HTTP API。
9.6.4 Ecosystem
Docker Engine 由 daemon、containerd、runc 等组成。替代或邻接实现有 Podman、Buildah、BuildKit、nerdctl、CRI-O、Kubernetes。扩展点包括 BuildKit frontend/cache exporter、network/volume/logging plugin、CNI 与 CSI driver。Compose 文件规范与具体 engine 支持范围要分开核对。
9.6.5 Depth Tiers
| 层级 | 可观察能力 |
|---|---|
| L0 | 知道 image、container、registry、volume、network、Compose 的职责 |
| L1 | 看懂 Dockerfile、docker run 和 compose.yaml 示例 |
| L2 | 能正确 build、run、push、备份、编排并处理常见参数错误 |
| L3 | 能解释 layer、namespace/cgroup、网络存储路径并用日志、stats、inspect 排错 |
| L4 | 能设计 runtime、plugin、供应链策略或大规模编排平台 |
本计划目标是 L3。
9.6.6 Source
- Docker 官方文档：CLI、Dockerfile、BuildKit、Compose、rootless 与生产建议。
- Moby 项目仓库：Docker Engine 核心实现，Apache-2.0。
- containerd 仓库：runtime 管理实现，Apache-2.0。
- 引用版本快照日期：2026-07-30；实作前运行
docker version与docker compose version。
10. 常见误区
- 只复制命令，不理解对象状态；
- 以 tag 代替 digest；
- 默认 root；
- 把 secret 写进 image 或仓库；
- 用重启掩盖 readiness 和数据问题；
- 只测试正常路径；
- 不记录 Docker/Compose 版本；
- 不区分 Docker 行为、OCI 契约和 Linux kernel 能力；
- 看见报错就重建全部对象；
- 未备份就 remove volume 或 prune。
11. 所有知识点分类（统一规则）
- 编程语言；2. 数据结构与算法；3. 计算机基础；4. 工程技术；5. Web 与后端；6. 前端与客户端；7. 数据与人工智能；8. 项目与职业能力；9. 安全与可靠性。
本计划归属：工程技术 主 + 安全与可靠性 辅。