docker_practice/12_implementation/12.1_arch.md at a780127d482e6c8e7b0437494a97c46e49ed553e

mirror of https://github.com/yeasy/docker_practice.git synced 2026-10-20 09:46:54 +00:00

Files

T

yeasy ef2625531d style: 含中文的括号统一为全角（336 处 / 110 文件）

全书此前是真·五五开：含中文的括号 336 处半角 : 336 处全角，而且**在同一文件
内混用**——`18_security/18.1_kernel_ns.md` 第 11/17/20 行写 `（如 runC）`，
第 31 行写 `(用户命名空间映射)`。这不是体例问题，是它自己跟自己不一致。

集群里其余 13 本都一边倒（llm_internals 5 : 1049、oc_guide 2 : 713、
forward_deployed_engineering_guide 0 : 108），blockchain_guide 已在 2026-08-05
按同一方向统一过 97 处，故取全角，而非另立新规。全角括号前后不留空格，
原先 `概念 (镜像、容器、仓库) 和` 两侧的空格一并收掉。

**纯拉丁内容的半角括号一个没动**——`新建一个层 (Layer)`、`项目 (project)`
保持原样：改动前后「半角且内容纯拉丁」的数量都是 **1163**，而「半角且含中文」
从 **336 变成 0**。

其余验证：改动前后各自抹掉全部空白与圆括号后**逐字节相同**（两侧均 19559 字符）；
左右括号总数改动前后都是 399 : 399，证明没有吞括号也没有配错对。
`check_project_rules` 202/202、`check_emphasis` 202/202、37 tests OK、
根 `format_checker` 与 `validate_codeblocks` 干净、`git diff --check` 干净。

2026-08-24 13:13:23 -07:00

4.5 KiB

Raw Blame History

12.1 基本架构

Docker 的架构设计简洁而高效，主要由客户端和服务端两部分组成。

12.1.1 核心架构图

Docker 采用了 C/S（客户端/服务端） 架构。Client 向 Daemon 发送请求，Daemon 负责构建、运行和分发容器。

graph LR
  C1["客户端"] -->|docker run| D["dockerd<br/>守护进程"]
  C1 -->|docker pull| D
  D -->|管理| C2["Containers<br/>容器"]
  D -->|管理| C3["Images<br/>镜像"]

12.1.2 组件详解

Docker 的内部架构如同洋葱一样分层，每一层专注解决特定问题：

1. Docker CLI：客户端

用户与 Docker 交互的主要方式。它将用户命令（如 docker run）转换为 API 请求发送给 dockerd。

2. Dockerd：守护进程

Docker 的大脑。

监听 API 请求
管理 Docker 对象（镜像、容器、网络、卷）
编排下层组件完成工作

3. Containerd：高级运行时

行业标准的容器运行时（CNCF 毕业项目）。

管理容器的完整生命周期（启动、停止）
镜像拉取与存储
不包含 复杂的与容器无关的功能（如构建、API）
Kubernetes 也可以直接使用 containerd（跳过 Docker）

4. Runc：低级运行时

用于创建和运行容器的 CLI 工具。

直接与内核交互 (Namespaces，Cgroups)
遵循 OCI (Open Container Initiative) 规范
主要职责：根据配置启动一个容器，然后退出（将控制权交给容器进程）

5. Shim

每个容器都有一个 shim 进程。

解耦：允许 dockerd 重启而不影响容器运行
保持 IO：维持容器的标准输入输出
状态汇报：向 containerd 汇报容器退出状态

12.1.3 容器启动流程

当执行 docker run -d nginx 时，内部发生了什么？

flowchart TD
  U["用户"]
  K["docker run -d nginx"]
  D["Dockerd"]
  C["Containerd"]
  B["OCI Bundle"]
  S["Containerd-shim"]
  R["Runc"]
  P["容器进程<br/>nginx"]
  E["退出"]

  U -->|1. REST API| D
  D -->|2. gRPC| C
  C -->|3. 准备镜像和 Bundle| B
  C -->|4. 启动 Shim| S
  S -->|5. 执行| R
  R -->|6. 创建 Namespaces 和 Cgroups| P
  R -->|7. 进程退出| E
  S -->|8. 监控 IO 和退出| P

CLI 发送请求给 Dockerd
Dockerd 解析请求，调用 Containerd
Containerd 准备镜像，转换为 OCI Bundle
Containerd 创建 Shim 进程
Shim 调用 Runc
Runc 与系统内核交互，创建 Namespaces 和 Cgroups
Runc 启动 nginx 进程后退出
Shim 接管容器 IO 和生命周期监控

12.1.4 Docker Engine v29.x 变化

从 Docker Engine v29.x 开始，架构进一步简化和标准化：

Containerd 镜像存储 (Image Store)：在 v29.x 的新安装场景中默认启用。Docker 直接使用 Containerd 的镜像管理能力，不再维护自己的一套 graphdriver。
- 优势：多平台镜像支持更好，可保存 SBOM/Provenance 等 attestations，并可使用 containerd snapshotters 的 lazy pulling 等能力。
实验性 nftables 支持：随着主流 Linux 发行版逐步弃用 iptables，Docker v29.x 引入了实验性 nftables 后端。启用方式为 dockerd --firewall-backend=nftables，可直接创建 nftables 规则而无需依赖 iptables-nft 转换层。生产环境请谨慎使用。

12.1.5 Docker Desktop 架构

在 macOS 和 Windows 上，因为内核差异，架构稍微复杂：

flowchart TD
    subgraph HostOS ["MacOS / Windows"]
        CLI["Docker CLI"]
        subgraph LinuxVM ["Linux VM (虚拟机)"]
            Engine["Dockerd <--> Containerd <--> Runc"]
        end
        CLI -- "(Socket 映射)" --> Engine
    end

使用轻量级虚拟机 (Apple Virtualization / WSL 2) 运行 Linux 内核
文件挂载 (Bind Mount) 需要跨越 VM 边界（这也是文件 I/O 慢的原因）
网络端口需要从宿主机转发到 VM

12.1.6 总结

组件	角色	关键职责
CLI	指挥官	发送指令，展示结果
Dockerd	大管家	API 接口，整体调度
Containerd	经理	容器生命周期，镜像管理
Shim	监工	保持 IO，允许无守护进程重启
Runc	工人	真正干活（创建容器），干完就走

12.1.7 延伸阅读

命名空间：Runc 如何隔离容器
控制组：Runc 如何限制资源
联合文件系统：镜像如何存储

4.5 KiB Raw Blame History Unescape Escape