第一章: Docker 架构与核心概念解析

在本章中，我们将像剥洋葱一样，层层深入 Docker 的核心：

1. 首先，我们将揭示 Docker 引擎的 C/S 架构，让你明白 docker 命令是如何与后台守护进程通信的。
2. 接着，我们将精准定义 Docker 世界的三大基本元素：镜像、容器和仓库。
3. 然后，我们将深入底层，借助你的 Linux 知识，理解实现资源隔离的两大基石：命名空间 (Namespaces)。
4. 紧接着，我们将探索实现资源限制的另一大基石：控制组 (Cgroups)。
5. 最后，我们将把理论与实践结合，探讨 Docker 在 WSL2 中的资源管理 模式。

1.1. Docker 引擎：客户端-服务端 (C/S) 架构详解

在我们成功安装并运行 hello-world 之后，你可能认为 docker 是一个单一的可执行文件。然而，这只是冰山一角。Docker 实际上是一个标准的 客户端-服务端 (Client/Server) 应用。

本小节核心知识点:

• Docker 引擎 (Docker Engine): 这是 Docker 的核心，一个 C/S 架构的应用，主要由 Docker 守护进程 (Daemon)、REST API 和 Docker CLI 三部分组成。
• 守护进程 (Daemon): 名为 dockerd 的后台进程，它负责处理所有核心工作，如创建和管理镜像、容器、网络和存储卷。守护进程
• Docker CLI: 命令行工具，也就是我们常用的 docker 命令。它扮演客户端的角色，将我们的指令通过 REST API 发送给守护进程。
• REST API: 客户端与守护进程之间的桥梁，允许它们通过一个标准的接口进行通信。默认情况下，在 Linux 系统中，它们通过一个 UNIX 套接字 (socket) /var/run/docker.sock 进行通信。

痛点背景: 当我们在终端输入 docker run nginx 时，这个命令是如何让一个 Nginx 服务器运行起来的？如果 docker 只是一个简单的命令，它关闭后容器为什么还能继续运行？

解决方案: 理解 C/S 架构就能豁然开朗。

1. 我们在 WSL2 终端中输入的 docker 命令，启动了 Docker 客户端。
2. 客户端将 run nginx 这个请求，打包成一个标准的 API 请求，发送给在本机后台持续运行的 Docker 守护进程 `dockerd`。
3. 守护进程接收到请求后，执行所有繁重的工作：检查本地是否存在 nginx 镜像，如果不存在就从远程仓库拉取，然后基于该镜像创建一个新的容器，并启动它。
4. 守护进程将执行结果返回给客户端，客户端在我们的终端上显示容器 ID 等信息，然后退出。
5. 即使客户端退出了，守护进程和它所创建的容器依然在后台运行，这就是为什么关闭终端窗口，我们的 Nginx 服务不会中断的原因。

我们可以在 WSL2 中亲眼验证守护进程的存在：

1
2

# 在 WSL2 终端中执行
ps aux | grep dockerd

1
2
# 输出会包含类似这样的一行，证明 dockerd 进程正在运行
root      1234  0.1  0.5 123456 7890 ?        Ssl  Sep17   1:23 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock

1.2. 核心组件交互：镜像 (Image)、容器 (Container) 与仓库 (Registry)

理解了 C/S 通信模型后，我们再来明确通信内容中的三个核心“名词”：镜像、容器和仓库。对于有编程经验的你来说，一个恰当的类比能让你瞬间理解它们的关系。

本小节核心知识点:

• 镜像 (Image): 一个只读的模板，包含了运行应用所需的所有文件系统内容和配置。它采用分层存储结构，可以被看作是软件交付的“集装箱”本身。
• 容器 (Container): 镜像的一个可运行实例。容器与镜像的关系，就像是面向对象编程中 对象 (Object) 与 类 (Class) 的关系。镜像是静态的定义，容器是动态的运行实体。容器在镜像的只读层之上增加了一个可写层。
• 仓库 (Registry): 集中存储和分发镜像的服务。仓库与镜像的关系，就像是 代码仓库 (如 GitHub) 与 代码 (Code) 的关系。最著名的公共仓库是 Docker Hub。

核心关系链:
开发者在本地构建一个 Image -> 将 Image 推送到远程的 Registry -> 其他开发者或服务器从 Registry 拉取该 Image -> 在本地运行该 Image，创建出一个或多个 Container。

这个流程完美地解决了“在我电脑上明明是好的”这一经典难题，因为它确保了整个团队和所有环境（开发、测试、生产）都使用完全相同的只读模板（镜像）来创建运行环境（容器）。

1.3. 底层技术揭秘 (上)：命名空间 (Namespaces) 如何实现资源隔离

承上启下: 我们已经知道容器是镜像的实例，并且容器之间是相互隔离的。那么，这种“隔离”的魔法究竟是如何实现的？这正是你的 Linux 知识大显身手的时刻。Docker 的隔离能力，主要依赖于 Linux 内核的两大特性，首先是 命名空间 (Namespaces)。

痛点背景:

• 为什么我在容器 A 中启动了一个 Web 服务监听 80 端口，还可以在容器 B 中再次启动一个服务监听 80 端口，而不会产生端口冲突？
• 为什么在容器内部执行 ps aux 只能看到容器自己的进程，而看不到宿主机或其他容器的进程？

解决方案: 命名空间 (Namespaces) 是 Linux 内核提供的一种资源隔离方案。它能让一个进程（以及它的子进程）看起来像是拥有自己独立的全局资源。Docker 正是为每个容器创建了一系列专属的命名空间，从而实现了“欺骗”容器内进程的效果，让它以为自己独占了整个操作系统。

Docker 主要使用了以下几种命名空间：

1.4. 底层技术揭秘 (下)：控制组 (Cgroups) 如何实现资源限制

承上启下: 命名空间为容器提供了隔离的“视野”，解决了“能看到什么”的问题。但这还不够，如果一个容器发生内存泄漏，它可能会耗尽宿主机的所有内存，导致整个系统崩溃。如何限制容器“能用多少”资源？这就是 Linux 内核的第二个法宝——控制组 (Cgroups) 的用武之地。

痛点背景:

• 如何确保一个容器最多只能使用 2 核 CPU 和 1GB 内存？
• 如何防止某个“坏邻居”容器抢占所有资源，影响到同一台宿主机上的其他重要服务？

解决方案: 控制组 (Cgroups) 是 Linux 内核的另一个核心特性，其主要作用是 限制、记录和隔离进程组所使用的物理资源，包括 CPU、内存、磁盘 I/O 等。

当 Docker 创建一个容器时，它不仅会为其创建命名空间，还会为其在 Cgroups 的层级体系中创建一个对应的控制组。所有容器内的进程都会在这个控制组的管辖之下。

我们可以通过 docker run 命令的参数来轻松地利用 Cgroups 的能力：

• 限制内存: docker run --memory=1g ... 这条命令告诉 Docker，创建一个容器，并配置其所属的 Cgroup，确保该容器使用的内存总量不会超过 1GB。
• 限制 CPU: docker run --cpus=2 ... 这条命令则限制容器最多可以使用两个 CPU 核心的计算能力。

🤔 思考一下
我们刚刚剖析了容器依赖的两大 Linux 内核技术。现在，请结合这些知识，思考一下：容器 (Container) 与我们熟知的传统虚拟机 (Virtual Machine) 之间，最本质的区别是什么？

1.5. WSL2 集成模式下的资源管理与性能监控

承上启下: 理解了 Namespaces 和 Cgroups 这两大通用 Linux 原理后，我们把目光拉回到具体的开发环境：Windows + WSL2。Docker Desktop 在 WSL2 上的运行方式非常巧妙，了解它有助于我们更好地管理资源。

痛点背景:

• 开发者普遍担心 Docker Desktop for Windows 会占用大量系统资源，拖慢电脑。
• 在 WSL2 模式下，我们如何精确地控制 Docker 能使用的最大内存和 CPU 数量？

解决方案: Docker Desktop 并没有直接在你的 Windows 系统上运行 dockerd。相反，它在 WSL2 内部启动了一个专用的、轻量级的 Linux 发行版（名为 docker-desktop），Docker 守护进程和所有容器都运行在这个专门的 WSL2 “虚拟机” 中。

这种方式的优势在于性能，因为它利用了 WSL2 提供的完整 Linux 内核，让 Docker 可以原生运行。但这也意味着，Docker 的资源消耗被计入了整个 WSL2 的资源池中。

要精确控制 Docker (以及所有 WSL2 发行版) 的资源上限，我们可以在 Windows 用户目录下创建一个名为 .wslconfig 的文件。

文件路径: C:\Users\<你的用户名>\.wslconfig

在这个文件中，我们可以这样配置：

1
2
3
4
5
6
7
8
9
10
11

# .wslconfig

[wsl2]
# 限制所有 WSL2 "虚拟机"加起来最多能使用 4GB 内存
memory=4GB 

# 限制所有 WSL2 "虚拟机"加起来最多能使用 2 个 CPU 核心
processors=2

# 将 Windows 上的 D:\docker-data 目录挂载到 WSL2 中，可用于存放 Docker 数据
# swap=0 # 如果不需要交换空间，可以设置为0来节省磁盘空间

通过这种方式，我们就为 Docker 设置了一个清晰的资源“天花板”，再也不用担心它会失控并耗尽整个 Windows 系统的资源了。

1.6. 本章核心速查总结

本章我们深入了 Docker 的内部架构与核心概念，为你后续的实战打下了坚实的理论基础。

总结要点:
Docker 并非魔法，它巧妙地运用了成熟的 Linux 内核技术（Namespaces 和 Cgroups）来提供轻量级的应用隔离与资源限制。理解其 C/S 架构和三大核心组件（镜像、容器、仓库）的交互关系，是掌握 Docker 的关键第一步。

1.7. 高频面试题与陷阱