更新Docker安装、镜像、Dockerfile和Compose等文档内容

01_introduction/1.1_quickstart.md

@@ -2,6 +2,16 @@
 
 本节将通过一个简单的 Web 应用例子，带你快速体验 Docker 的核心流程：构建镜像、运行容器。
 
+### 为什么选择 Nginx + HTML 作为入门例子？
+
+在学习 Docker 之前，我们先来理解为什么这个例子是最适合初学者的。Docker 的核心价值在于**一致性交付**——无论你在本地、云端还是他人的机器上运行容器，应用的行为都是完全一致的。这个 Nginx + 静态 HTML 的例子之所以被广泛采用，是因为它展现了 Docker 工作流的三个核心阶段：
+
+1. **镜像定义（Image Layer）**：通过 Dockerfile 描述如何把应用打包成一个自包含的单元
+2. **镜像构建（Build）**：执行 `docker build`，Docker 根据 Dockerfile 逐层构建镜像
+3. **容器运行（Runtime）**：通过 `docker run` 启动容器实例，应用真正开始提供服务
+
+Nginx 是一个轻量级、使用广泛的 Web 服务器，学习完这个例子后，你可以轻松扩展到部署 Node.js、Python、Go 等任何语言的应用。
+
 ### 1.1.1 准备代码
 
 创建一个名为 `hello-docker` 的文件夹，并在其中创建一个 `index.html` 文件：

03_install/3.1_ubuntu.md

@@ -2,6 +2,17 @@
 
 Ubuntu 是 Docker 最常用的运行环境之一。本节将介绍如何在 Ubuntu 系统上安装 Docker，并配置国内镜像加速。
 
+### 为什么推荐 APT 源安装而不是脚本？
+
+虽然 Docker 官方提供了便捷的安装脚本（`get.docker.com`），但笔者在生产环境中**强烈推荐 APT 源安装**，原因如下：
+
+- **版本管理**：通过 APT 源安装的 Docker，后续可以像管理其他系统软件包一样进行更新和版本管理
+- **安全补丁**：Ubuntu 官方仓库会及时推送 Docker 的安全更新，这在生产环境中至关重要
+- **一致性**：同一 Ubuntu 版本上的团队成员安装的 Docker 版本完全一致，避免了"在我的机器上可以运行"的问题
+- **卸载干净**：APT 包管理系统会负责清理所有相关文件，脚本安装的清理往往不够彻底
+
+如果你只是想快速尝试 Docker，脚本安装没有问题；但一旦涉及持久运维，APT 源是更成熟的选择。
+
 > 警告：切勿在没有配置 Docker APT 源的情况下直接使用 apt 命令安装 Docker。
 
 ### 3.1.1 准备工作

03_install/3.2_debian.md

@@ -2,6 +2,10 @@
 
 Debian 以其稳定性著称，是 Docker 的理想宿主系统。本节将指导你在 Debian 上完成 Docker 的安装。
 
+### APT 源安装的必要性
+
+与 Ubuntu 类似，Debian 用户在安装 Docker 时同样应该优先选择 APT 源安装。Debian 对系统稳定性的极致追求，使得通过官方仓库来管理 Docker 生命周期变得尤为重要。特别是在服务器环境，APT 源提供的版本控制和安全更新流程是不可或缺的。
+
 > 警告：切勿在没有配置 Docker APT 源的情况下直接使用 apt 命令安装 Docker。
 
 ### 3.2.1 准备工作

03_install/3.3_fedora.md

@@ -2,6 +2,10 @@
 
 Fedora 作为技术前沿的 Linux 发行版，对 Docker 有着良好的支持。本节介绍在 Fedora 上的安装步骤。
 
+### YUM/DNF 源安装的策略建议
+
+Fedora 的快速发布周期（每 6 个月发布新版本）决定了它的用户群体多为开发者和技术爱好者。虽然通过 DNF 可以直接安装 Docker，但笔者建议仍然通过 Docker 官方 YUM 源进行安装，原因是：Fedora 官方仓库的 Docker 版本往往滞后，而官方源能确保你获得最新的 Docker 功能和安全补丁。特别是在开发环境需要用到最新 Docker 特性时，这一点显得尤为重要。
+
 > 警告：切勿在没有配置 Docker dnf 源的情况下直接使用 dnf 命令安装 Docker。
 
 ### 3.3.1 准备工作

03_install/3.4_centos.md

@@ -2,6 +2,10 @@
 
 CentOS (及其替代品 Rocky Linux、AlmaLinux) 是企业级服务器常用的操作系统。本节介绍在这些系统上安装 Docker 的步骤。
 
+### 企业级部署的版本选择
+
+值得注意的是，**CentOS 8 已停止维护，CentOS 7 已停止支持**。如果你正在规划新的生产部署，强烈建议选择 Rocky Linux 或 AlmaLinux——这两个项目是由社区维护的 CentOS 替代品，延续了 CentOS 的企业级特性，同时提供了更长的生命周期承诺。选择稳定的基础系统，才能为 Docker 的长期运维奠定坚实基础。
+
 > 警告：切勿在没有配置 Docker YUM 源的情况下直接使用 yum 命令安装 Docker。
 
 ### 3.4.1 准备工作

03_install/3.5_raspberry-pi.md

@@ -2,6 +2,26 @@
 
 树莓派等 ARM 架构设备在物联网和边缘计算领域应用广泛。本节介绍如何在树莓派上安装 Docker。
 
+### 树莓派运行 Docker 的现实考虑
+
+树莓派是 Docker 在边缘计算的一个优秀用例。但在安装前，笔者建议你了解几个实际情况：
+
+**性能特性**：
+- Raspberry Pi 4 及以上才能流畅运行 Docker 和基本容器
+- Raspberry Pi Zero 2 可以运行，但性能受限
+- 磁盘 I/O 是主要瓶颈（特别是使用 microSD 卡时）
+
+**镜像可用性**：
+- 并非所有 Docker 镜像都有 ARM 版本（arm64 或 armv7）
+- 官方镜像通常提供多架构支持，但第三方镜像可能没有
+- 某些依赖 Intel 特定指令的应用无法在 ARM 上运行
+
+**存储和内存**：
+- 容器镜像会占用较多存储空间，128GB microSD 卡建议最多运行 3-4 个中等大小的容器
+- 512MB 或 1GB 内存的树莓派运行多个容器会非常吃力
+
+**实践建议**：树莓派 Docker 部署最适合轻量级应用——单个微服务、监控代理、Web 服务器等。复杂多容器应用还是应该部署在性能更强的硬件上。
+
 > 警告：切勿在没有配置 Docker APT 源的情况下直接使用 apt 命令安装 Docker。
 
 ### 3.5.1 系统要求

03_install/3.7_mac.md

@@ -1,5 +1,18 @@
 ## 3.7 macOS
 
+### Mac 用户的特殊考虑
+
+macOS 上没有原生 Linux 内核，Docker 需要运行在一个轻量级虚拟机中。Docker Desktop 完全封装了这个复杂性，让 Mac 用户可以像 Linux 用户一样使用 Docker。但有几点需要特别了解：
+
+**性能特性**：
+- Apple Silicon（M 系列芯片）比 Intel Mac 的性能更好，且拥有原生支持
+- 文件 I/O 性能：macOS 与容器之间的卷挂载性能不如 Linux（这是虚拟化的代价）
+- 内存使用：Docker Desktop 本身会消耗一定内存用于虚拟机管理
+
+**许可考虑**：
+- 个人开发和小团队可免费使用
+- 商业企业需要关注许可费用
+
 ### 3.7.1 系统要求
 
 [Docker Desktop for Mac](https://docs.docker.com/desktop/setup/install/mac-install/) 支持当前版本及前两个主要版本的 macOS，并且至少需要 4 GB 内存。对于 Apple Silicon 机型，若需要兼容部分 Intel 命令行工具，官方建议安装 Rosetta 2。

03_install/3.8_windows.md

@@ -2,6 +2,23 @@
 
 在 Windows 平台上，Docker Desktop 提供了完整的 Docker 开发环境。本节介绍在 Windows 10/11 上的安装和配置。
 
+### Windows 上的 Docker：运行原理理解
+
+与 macOS 类似，Windows 也没有原生 Linux 容器支持。Docker Desktop for Windows 有两种运行后端可选：
+
+**WSL 2（Windows Subsystem for Linux 2）** - 推荐：
+- 利用 Hyper-V 虚拟化运行真正的 Linux 内核
+- 性能更好，文件系统集成更深
+- 现代 Windows 10/11 的标准选择
+- 支持在 Linux 和 Windows 之间的无缝文件访问
+
+**Hyper-V** - 传统方案：
+- 纯虚拟化方式
+- 性能略低于 WSL 2
+- 在某些企业网络环境下仍被使用
+
+**实践建议**：如果你的系统支持 WSL 2，强烈推荐使用 WSL 2。在安装 Docker Desktop 时，如果 WSL 2 环境检测无问题，安装程序会自动使用 WSL 2。
+
 ### 3.8.1 系统要求
 
 [Docker Desktop for Windows](https://docs.docker.com/desktop/setup/install/windows-install/) 支持 Docker 官方文档列出的受支持 Windows 10/11 64 位版本。若使用 WSL 2 后端，需要启用 WSL 2，并满足官方要求的 `WSL 2.1.5` 或更高版本；若使用 Hyper-V 后端，则需要启用 Hyper-V 和 Containers 功能。Windows 10 64 位支持 Enterprise、Pro 和 Education 22H2 (build 19045)，Windows 11 64 位支持 Enterprise、Pro 和 Education 23H2 (build 22631) 或更高版本。

03_install/README.md

@@ -4,6 +4,35 @@ Docker 分为 `stable` `test` 和 `nightly` 三个更新频道。
 
 官方网站上有各种环境下的[安装指南](https://docs.docker.com/get-docker/)，这里主要介绍 Docker 在 `Linux`、`Windows 10` 和 `macOS` 上的安装。
 
+## 安装方式选择指南
+
+在开始安装前，笔者建议你根据以下决策树选择最合适的安装方式：
+
+### 生产环境 vs 开发环境
+
+**生产环境**（服务器部署）：
+- 优先使用**官方 APT/YUM 源安装**（Ubuntu、Debian、Fedora、CentOS）
+- 优势：获得官方安全更新、长期技术支持、版本管理清晰
+- 安装步骤稍多一些，但这种"麻烦"是值得的——它为你的生产系统争取了稳定性和可维护性
+
+**开发环境**（本地开发机、测试服务器）：
+- 使用**脚本自动安装**或**包管理器直接安装**
+- 如果你想快速上手，官方脚本（`get.docker.com`）是最便捷的选择
+- 国内用户注意：这一步一定要选对镜像源，否则网络卡顿会严重影响体验
+
+### 国内用户的网络优化建议
+
+值得注意的是，国内直接访问 Docker 官方源速度较慢，建议：
+- **安装过程**：使用阿里云、腾讯云等国内镜像源
+- **镜像拉取**：安装完成后配置 Docker 镜像加速器（详见 [3.9 镜像加速器](3.9_mirror.md)），这一步对日常开发的体验提升最明显
+
+### 特殊场景
+
+- **Raspberry Pi/ARM 平台**：见 [3.5 Raspberry Pi](3.5_raspberry-pi.md)
+- **离线环境**：见 [3.6 Linux 离线安装](3.6_offline.md)
+- **macOS/Windows**：Docker Desktop 是官方推荐的一站式解决方案
+- **需要实验特性**：见 [3.10 开启实验特性](3.10_experimental.md)
+
 ## 详细安装指南
 
 * [Ubuntu](3.1_ubuntu.md)

04_image/README.md

@@ -17,6 +17,6 @@ Docker 运行容器前需要本地存在对应的镜像，如果本地不存在
 * [镜像的实现原理](4.7_internal.md)
 
 > **版本提示：镜像存储后端的变迁**
-> 
+>
 > 在 Docker Engine v29 及后续版本中，Docker 全新安装默认启用了 **containerd image store**（替代了传统的 classic store）。这一底层架构级别的变迁，意味着 Docker 解锁了对 OCI Image Index 和 Attestations （例如原生的 provenance 来源证明与 SBOM 软件物料清单）的全量本地支持。
 > 读者在执行类似 `docker buildx build --provenance=mode=min --sbom=true` 甚至使用后续审查工具（如 `docker buildx imagetools inspect`）时，其元数据能够与镜像数据一并完好地管理于本地存储系统中，为供应链安全验证补齐了最后一块拼图。

06_repository/README.md

@@ -6,6 +6,28 @@
 
 大部分时候，并不需要严格区分这两者的概念。
 
+## 为什么需要私有仓库？
+
+在讨论具体的安装和配置前，让我们先理解：**什么时候你应该建设私有仓库？**
+
+**开发团队**（有专利代码、不能公开）：
+- 需要私有仓库存储内部镜像
+- 涉及访问控制和审计
+- 强烈推荐使用托管方案（如 Harbor 或云厂商提供的镜像仓库）
+
+**开源项目或个人学习**：
+- Docker Hub 公开仓库足够
+- 无需自建私有仓库的成本
+
+**企业级部署**：
+- 需要高可用、备份、灾难恢复
+- 推荐使用专业级方案（Nexus 3、Harbor）而非简单的 Registry
+
+本章涵盖的方案从简到复杂：
+- Docker Registry：最小化部署（适合简单场景）
+- 私有仓库高级配置：添加认证、HTTPS 等生产必需项
+- Nexus 3：企业级完整解决方案，支持权限管理、备份等
+
 ## 本章内容
 
 * [Docker Hub](6.1_dockerhub.md)

07_dockerfile/7.1_run.md

@@ -1,5 +1,16 @@
 ## 7.1 RUN 执行命令
 
+### 何时使用 RUN
+
+`RUN` 是 Dockerfile 中最常用的指令，主要用于在镜像构建阶段执行命令来修改镜像。具体来说：
+
+- **安装依赖**：`RUN apt-get install nginx`
+- **编译程序**：`RUN gcc -o app main.c`
+- **下载文件**：`RUN curl -O https://example.com/file.tar.gz`
+- **配置系统**：`RUN mkdir -p /app/data`
+
+理解 RUN 的核心是理解**镜像分层**：每一个 RUN 都会在当前层之上创建新的一层，这会影响镜像大小。因此，合理使用 RUN（特别是合并多个 RUN）是构建轻量级镜像的关键。
+
 ### 7.1.1 基本语法
 
 ```docker

07_dockerfile/7.2_copy.md

@@ -1,5 +1,16 @@
 ## 7.2 COPY 复制文件
 
+### 何时使用 COPY
+
+`COPY` 是在构建镜像时，将构建上下文（Dockerfile 所在目录及其子目录）中的文件或目录复制到容器内的指令。它是处理应用代码、配置文件最常用的方式。
+
+典型场景：
+- 复制应用源码：`COPY . /app`
+- 复制配置文件：`COPY nginx.conf /etc/nginx/nginx.conf`
+- 复制静态资源：`COPY public /app/public`
+
+**为什么 COPY 比 ADD 更值得推荐？** 笔者建议在 90% 的情况下使用 COPY。原因是 COPY 的语义更清晰——它就是简单地复制文件。而 ADD 有额外的功能（自动解压、支持 URL），这些功能往往会带来意外的行为。除非你明确需要 ADD 的自动解压功能，否则用 COPY。详见 [7.3 ADD 指令](7.3_add.md) 中的详细对比。
+
 ### 7.2.1 基本语法
 
 ```docker

07_dockerfile/7.3_add.md

@@ -1,5 +1,16 @@
 ## 7.3 ADD 更高级的复制文件
 
+### 何时使用 ADD？何时用 COPY？
+
+在开始前，让我们直言不讳：**在大多数情况下，你应该使用 COPY，而不是 ADD**。
+
+`ADD` 在 `COPY` 基础上增加了两个额外功能，但这些功能往往引入复杂性而非便利：
+
+1. 自动解压 tar 压缩包（有时你想复制一个 .tar.gz 本身，而 ADD 会意外地解压它）
+2. 支持从 URL 下载文件（这个功能由于网络不稳定已被广泛认为是反模式）
+
+**实践中的建议**：除非你明确需要自动解压功能（比如官方基础镜像构建根文件系统），否则始终使用 COPY。原因很简单——显式优于隐式。你的 Dockerfile 在 6 个月后被接手维护时，清晰的意图会让团队少走很多弯路。
+
 ### 7.3.1 基本语法
 
 ```docker
@@ -13,7 +24,7 @@ ADD [选项] ["<源路径>", ... "<目标路径>"]
 
 ---
 
-### 7.3.2 ADD vs COPY
+### 7.3.2 ADD vs COPY 详细对比
 
 | 特性 | COPY | ADD |
 |------|------|-----|
@@ -23,7 +34,7 @@ ADD [选项] ["<源路径>", ... "<目标路径>"]
 | 行为可预测性 | ✅ 高 | ⚠️ 低 |
 | 推荐程度 | ✅ **优先使用** | 仅解压场景 |
 
-> 笔者建议：除非需要自动解压 tar 文件，否则始终使用 COPY。明确的行为比隐式的魔法更好。
+> **笔者建议**：除非需要自动解压 tar 文件，否则始终使用 COPY。明确的行为比隐式的魔法更好。
 
 ---
 

07_dockerfile/7.4_cmd.md

@@ -1,5 +1,20 @@
 ## 7.4 CMD 容器启动命令
 
+### 何时使用 CMD，何时使用 ENTRYPOINT？
+
+在深入 CMD 的细节之前，我们需要理解一个关键问题：**CMD 和 ENTRYPOINT 应该在什么时候使用？**
+
+这是 Dockerfile 使用中最常见的困惑之一。简单的答案是：
+- **CMD**：定义容器的”默认命令”。如果用户在 `docker run` 时提供命令，CMD 会被覆盖
+- **ENTRYPOINT**：定义容器的”入口脚本”。通常用于启动应用的某个特定部分
+
+**决策树**：
+1. **你的容器是否有不可变的启动逻辑？** 比如需要先做一些初始化工作，然后才运行应用 → 使用 ENTRYPOINT
+2. **用户经常会在 `docker run` 时传入不同的命令吗？** → 使用 CMD（让用户灵活覆盖）
+3. **大多数情况下，你希望容器始终以相同的方式启动？** → 使用 ENTRYPOINT
+
+更多细节见 [7.5 ENTRYPOINT 指令](7.5_entrypoint.md)。
+
 ### 7.4.1 什么是 CMD
 
 `CMD` 指令用于指定容器启动时默认执行的命令。它定义了容器的 “主进程”。

07_dockerfile/7.5_entrypoint.md

@@ -1,5 +1,33 @@
 ## 7.5 ENTRYPOINT 入口点
 
+### 何时使用 ENTRYPOINT：从"容器"到"命令"
+
+如果说 CMD 是"容器中的默认程序"，那么 ENTRYPOINT 就是"把容器变成一个命令"。这个思维转变决定了你何时使用 ENTRYPOINT。
+
+**使用 ENTRYPOINT 的典型场景**：
+
+1. **命令行工具**：你想让镜像像 `curl` 或 `wget` 一样使用
+   ```dockerfile
+   ENTRYPOINT ["curl"]
+   # docker run myimage http://example.com → curl http://example.com
+   ```
+
+2. **应用启动脚本**：你有一个初始化脚本，需要接收命令行参数
+   ```dockerfile
+   ENTRYPOINT ["/app/entrypoint.sh"]
+   # docker run myimage --debug → /app/entrypoint.sh --debug
+   ```
+
+3. **与 CMD 结合**：ENTRYPOINT 定义入口，CMD 定义默认参数
+   ```dockerfile
+   ENTRYPOINT ["python", "app.py"]
+   CMD ["--port", "8000"]
+   # docker run myimage → python app.py --port 8000
+   # docker run myimage --port 9000 → python app.py --port 9000
+   ```
+
+**对比 CMD**：如果没有这些"把容器当命令用"的需求，通常使用 CMD 就足够了。
+
 ### 7.5.1 什么是 ENTRYPOINT
 
 `ENTRYPOINT` 指定容器启动时运行的入口程序。与 CMD 不同，ENTRYPOINT 定义的命令不会被 `docker run` 的参数覆盖，而是 **接收这些参数**。

07_dockerfile/README.md

@@ -13,6 +13,18 @@ Dockerfile 是一个文本文件，其内包含了一条条的 **指令 (Instruc
 *   **版本控制**：Dockerfile 可以纳入版本控制系统 (如 Git)，便于追踪变更。
 *   **透明性**：任何人都可以通过阅读 Dockerfile 了解镜像的构建过程。
 
+## Dockerfile 编写哲学
+
+在深入每个指令的细节之前，笔者想强调一个至关重要的原则：**Dockerfile 不是脚本，而是镜像的"设计图"**。这个区别决定了你如何思考每条指令的作用。
+
+相比编写 Bash 脚本的思维（"按顺序执行这些命令"），Dockerfile 的思维应该是（"这一层镜像应该如何构建，下一层如何分层"）。这个思维转变会影响你的决策：
+
+- **合并命令**：一个 `RUN apt-get update && apt-get install ...` 应该写在一起，而不是分开成多个 `RUN` 指令，因为它们是同一个"层"的逻辑
+- **选择合适的指令**：`COPY` vs `ADD`、`CMD` vs `ENTRYPOINT` 这些选择不是随意的，而是根据镜像分层的语义来决定的
+- **优化镜像大小**：最后才清理缓存、删除临时文件，让这些"瘦身"操作在同一层完成
+
+这个章节将详细介绍各个指令。在学习指令语法时，请始终思考："这个指令为什么要以这样的方式工作？如果我是 Docker，我应该如何设计它？"
+
 ## Dockerfile 基本结构
 
 Dockerfile 一般分为四部分：基础镜像信息、维护者信息、镜像操作指令和容器启动时执行指令。

09_network/README.md

@@ -11,7 +11,7 @@ graph TD
     subgraph Host [宿主机]
         eth0[物理网卡 eth0<br>192.168.1.100]
         docker0[docker0 网桥<br>172.17.0.1]
-        
+
         subgraph Containers
             subgraph ContainerA [容器 A]
                 eth0_A[eth0<br>172.17.0.2]
@@ -20,12 +20,12 @@ graph TD
                 eth0_B[eth0<br>172.17.0.3]
             end
         end
-        
+
         eth0 <--> docker0
         docker0 <--> eth0_A
         docker0 <--> eth0_B
     end
-    
+
     Internet((互联网)) <--> eth0
 ```
 本章将详细介绍 Docker 网络配置的各个方面。

11_compose/11.4_commands.md

@@ -2,6 +2,28 @@
 
 Docker Compose 提供了丰富的命令来管理项目和容器。本节将详细介绍这些命令的使用格式和常用选项。
 
+### 何时用哪个命令：场景化指南
+
+在学习具体命令前，让我们从使用场景出发，这样可以帮助你更快地找到需要的命令：
+
+**项目启动与停止**：
+- `docker compose up`：第一次启动项目，拉取镜像、创建容器
+- `docker compose start`：启动已停止的容器（项目已存在）
+- `docker compose stop`：优雅地停止容器（不删除容器）
+- `docker compose down`：完全清理，删除容器和网络（开发时常用）
+
+**调试与查看**：
+- `docker compose ps`：查看项目中的容器状态
+- `docker compose logs`：查看容器日志（排查问题的第一步）
+- `docker compose exec`：进入正在运行的容器执行命令
+
+**构建与更新**：
+- `docker compose build`：重新构建镜像（修改 Dockerfile 后）
+- `docker compose pull`：更新所有镜像到最新版本
+
+**配置验证**：
+- `docker compose config`：验证 docker-compose.yml 格式是否正确
+
 ### 11.4.1 命令对象与格式
 
 对于 Compose 来说，大部分命令的对象既可以是项目本身，也可以指定为项目中的服务或者容器。如果没有特别的说明，命令对象将是项目，这意味着项目中所有的服务都会受到命令影响。

11_compose/README.md

@@ -3,9 +3,22 @@
 `Docker Compose` 是 Docker 官方编排 (Orchestration) 项目之一，负责快速的部署分布式应用。
 
 > ⚠️ **重要提示：Compose V1 已停止支持**
-> 
+>
 > 早期基于 Python 编写的 Compose V1（命令为 `docker-compose`）已于 2023 年中正式停止支持。现已全面升级为基于 Go 编写的 Compose V2，作为 Docker CLI 的官方插件提供（命令为 `docker compose`，中间为空格）。本书强烈推荐且后续章节均以 V2 为核心标准进行讲解。
 
+## Docker Compose 解决什么问题？
+
+在学习 Compose 之前，笔者想强调它的真正价值。假设你正在开发一个微服务应用——前端、后端、数据库三个服务。如果你用 Docker 容器分别运行它们，你会遇到这些问题：
+
+1. **启动顺序**：需要先启数据库，再启后端，最后启前端
+2. **网络连接**：三个容器需要能彼此通信
+3. **卷挂载**：本地代码需要映射到容器内
+4. **环境变量**：每个服务的配置需要逐个设置
+
+使用 `docker run` 逐个启动的话，需要记住 3 条复杂的命令。而 **Docker Compose 的核心价值就是用一个 YAML 文件来定义整个应用**，然后一条命令 `docker compose up` 启动所有服务。这是 Compose 被广泛采用的原因——它极大地简化了本地开发和测试的复杂性。
+
+**谁应该学 Compose？** 任何使用 Docker 进行本地开发的人，以及需要快速部署多容器应用的团队。
+
 本章将介绍 `Compose` 项目情况以及安装和使用。
 
 * [简介](11.1_introduction.md)

18_security/README.md

@@ -15,7 +15,7 @@ flowchart LR
         Host["Host OS"]
         Guest --> Hyper --> Host
     end
-    
+
     subgraph Container ["容器安全模型：<br/>进程隔离（轻量但需加固）"]
         direction TB
         Proc["容器进程<br/>(共享内核)"]