Add blank lines before lists per CommonMark

01_introduction/1.1_quickstart.md

@@ -36,6 +36,7 @@ COPY index.html /usr/share/nginx/html/index.html
 ```bash
 $ docker build -t my-hello-world .
 ```
+
 * `docker build`：构建命令
 * `-t my-hello-world`：给镜像起个名字 (标签)
 * `.`：指定上下文路径为当前目录
@@ -47,6 +48,7 @@ $ docker build -t my-hello-world .
 ```bash
 $ docker run -d -p 8080:80 my-hello-world
 ```
+
 * `docker run`：运行命令
 * `-d`：后台运行
 * `-p 8080:80`：将宿主机的 8080 端口映射到容器的 80 端口

01_introduction/1.2_what.md

@@ -93,6 +93,7 @@ flowchart LR
         runC --> OCI["OCI<br/>标准化"]
     end
 ```
+
 - **LXC** (2013)：Docker 最初基于 Linux Containers
 - **libcontainer** (2014，Docker 0.9)：Docker 自研的容器运行时
 - **runC** (2015，Docker 1.11 整合)：捐献给 OCI 的标准容器运行时

02_basic_concept/2.1_image.md

@@ -41,6 +41,7 @@ Docker 镜像是一个特殊的文件系统，包含：
 | **元数据** | 启动命令、暴露端口、数据卷定义 |
 
 **关键特性**：
+
 - ✅ 镜像是 **只读** 的
 - ✅ 镜像 **不包含** 动态数据
 - ✅ 镜像构建后 **内容不会改变**

03_install/3.5_raspberry-pi.md

@@ -7,16 +7,19 @@
 树莓派是 Docker 在边缘计算的一个优秀用例。但在安装前，笔者建议你了解几个实际情况：
 
 **性能特性**：
+
 - Raspberry Pi 4 及以上才能流畅运行 Docker 和基本容器
 - Raspberry Pi Zero 2 可以运行，但性能受限
 - 磁盘 I/O 是主要瓶颈（特别是使用 microSD 卡时）
 
 **镜像可用性**：
+
 - 并非所有 Docker 镜像都有 ARM 版本（arm64 或 armv7）
 - 官方镜像通常提供多架构支持，但第三方镜像可能没有
 - 某些依赖 Intel 特定指令的应用无法在 ARM 上运行
 
 **存储和内存**：
+
 - 容器镜像会占用较多存储空间，128GB microSD 卡建议最多运行 3-4 个中等大小的容器
 - 512MB 或 1GB 内存的树莓派运行多个容器会非常吃力
 

03_install/3.7_mac.md

@@ -5,11 +5,13 @@
 macOS 上没有原生 Linux 内核，Docker 需要运行在一个轻量级虚拟机中。Docker Desktop 完全封装了这个复杂性，让 Mac 用户可以像 Linux 用户一样使用 Docker。但有几点需要特别了解：
 
 **性能特性**：
+
 - Apple Silicon（M 系列芯片）比 Intel Mac 的性能更好，且拥有原生支持
 - 文件 I/O 性能：macOS 与容器之间的卷挂载性能不如 Linux（这是虚拟化的代价）
 - 内存使用：Docker Desktop 本身会消耗一定内存用于虚拟机管理
 
 **许可考虑**：
+
 - 小型企业（少于 250 名员工且年收入低于 1000 万美元）、个人使用、教育和非商业开源项目可免费使用
 - 超出上述范围的商业用途需要付费订阅
 

03_install/3.8_windows.md

@@ -7,12 +7,14 @@
 与 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
 - 在某些企业网络环境下仍被使用

03_install/README.md

@@ -11,11 +11,13 @@ Docker Engine 主要提供 `stable` 和 `test` 两个更新频道；`test.docker
 ### 生产环境 vs 开发环境
 
 **生产环境**（服务器部署）：
+
 - 优先使用**官方 APT/YUM 源安装**（Ubuntu、Debian、Fedora、CentOS）
 - 优势：获得官方安全更新、长期技术支持、版本管理清晰
 - 安装步骤稍多一些，但这种“麻烦”是值得的——它为你的生产系统争取了稳定性和可维护性
 
 **开发环境**（本地开发机、测试服务器）：
+
 - 使用**脚本自动安装**或**包管理器直接安装**
 - 如果你想快速上手，官方脚本（`get.docker.com`）是最便捷的选择
 - 国内用户注意：这一步一定要选对镜像源，否则网络卡顿会严重影响体验

04_image/4.5_build.md

@@ -59,6 +59,7 @@ FROM scratch
 ```docker
 RUN echo '<h1>Hello, Docker!</h1>' > /usr/share/nginx/html/index.html
 ```
+
 * *exec* 格式：`RUN ["可执行文件", "参数1", "参数2"]`，这更像是函数调用中的格式。
 
 在会修改文件系统的指令里，`RUN` 是最典型的一类。每一个 `RUN` 的行为，都可以类比为我们刚才手工建立镜像的过程：先基于当前结果启动一个临时构建环境，在其上执行这些命令，再把这一步产生的文件系统变化保存为新的结果层。

04_image/4.7_internal.md

@@ -38,6 +38,7 @@ flowchart TD
     end
     Note["所有的写操作都在容器层这里"] -.-> L4
 ```
+
 *   **读取文件**：当容器需要读取文件时，Docker 会从最上层 (容器层) 开始向下层 (镜像层) 寻找，直到找到该文件为止。
 *   **修改文件**：当容器需要修改某个文件时，Docker 会从下层镜像中将该文件复制到上层的容器层，然后对副本进行修改。这被称为 **写时复制 (Copy-on-Write，CoW)** 策略。
 *   **删除文件**：当容器删除某个文件时，Docker 并不是真的去下层删除它 (因为下层是只读的)，而是在容器层创建一个特殊的 “白障 (Whiteout)” 文件，用来标记该文件已被删除，从而在容器视图中隐藏它。

06_repository/6.1_dockerhub.md

@@ -82,6 +82,7 @@ Docker Hub 对不同类型用户实施拉取速率限制（2025 年 4 月起更
 除了上述针对特定账号拉取镜像数量的 Pull Rate Limit 之外，Docker Hub 对所有用户（包含已认证及付费用户）还实施了 **滥用保护限流 (Abuse Rate Limiting)**。它是根据网络出口 IP (IPv4 或 IPv6 /64 子网) 计算整体请求频率，阈值动态触发（通常为每分钟数千级别请求）。
 
 **两类的差异与排查方法**：
+
 - **Pull Rate Limit**：针对拉取量达到上限。报错返回 `429 Too Many Requests`，并且 HTTP 返回体/CLI 错误提示中会带有明确的 `toomanyrequests: You have reached your pull rate limit` 提示，常附有账户升级链接。
 - **Abuse Rate Limit**：防范接口频率打击。报错仅返回简化的 `429 Too Many Requests`。这一限流不分付费与否，常发生在“多终端共享出口 IP”的企业局域网或者第三方云 CI 服务（如 GitHub Actions 等）中，即使你已正常配置 `docker login` 也依旧可能触发。
 

06_repository/README.md

@@ -11,15 +11,18 @@
 在讨论具体的安装和配置前，让我们先理解：**什么时候你应该建设私有仓库？**
 
 **开发团队**（有专利代码、不能公开）：
+
 - 需要私有仓库存储内部镜像
 - 涉及访问控制和审计
 - 强烈推荐使用托管方案（如 Harbor 或云厂商提供的镜像仓库）
 
 **开源项目或个人学习**：
+
 - Docker Hub 公开仓库足够
 - 无需自建私有仓库的成本
 
 **企业级部署**：
+
 - 需要高可用、备份、灾难恢复
 - 推荐使用专业级方案（Nexus 3、Harbor）而非简单的 Registry
 

07_dockerfile/7.1_run.md

@@ -28,6 +28,7 @@ RUN ["executable", "param1", "param2"]
 ```docker
 RUN apt-get update
 ```
+
 - **特点**：默认通过 `/bin/sh -c` 执行。
 - **优势**：可以使用环境变量、管道、重定向等 Shell 特性。
 - **示例**：
@@ -40,6 +41,7 @@ RUN apt-get update
 ```docker
 RUN ["apt-get", "update"]
 ```
+
 - **特点**：直接调用可执行文件，不经过 Shell。
 - **优势**：避免 Shell 字符串解析问题，适用于参数中包含特殊字符的情况。
 - **注意**：无法使用 `$VAR` 环境变量替换 (除非显式调用 shell)。

07_dockerfile/7.4_cmd.md

@@ -10,6 +10,7 @@
 - **ENTRYPOINT**：定义容器的”入口脚本”。通常用于启动应用的某个特定部分
 
 **决策树**：
+
 1. **你的容器是否有不可变的启动逻辑？** 比如需要先做一些初始化工作，然后才运行应用 → 使用 ENTRYPOINT
 2. **用户经常会在 `docker run` 时传入不同的命令吗？** → 使用 CMD（让用户灵活覆盖）
 3. **大多数情况下，你希望容器始终以相同的方式启动？** → 使用 ENTRYPOINT

11_compose/11.4_commands.md

@@ -7,21 +7,25 @@ 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 命令对象与格式

11_compose/11.8_wordpress.md

@@ -114,6 +114,7 @@ max_execution_time = 600
 ```bash
 $ docker compose up -d
 ```
+
 2. 访问安装界面：
    打开浏览器访问 `http://localhost:8000`
 

12_implementation/12.1_arch.md

@@ -83,6 +83,7 @@ flowchart TD
   R -->|7. 进程退出| E
   S -->|8. 监控 IO 和退出| P
 ```
+
 1. **CLI** 发送请求给 **Dockerd**
 2. **Dockerd** 解析请求，调用 **Containerd**
 3. **Containerd** 准备镜像，转换为 OCI Bundle
@@ -117,6 +118,7 @@ flowchart TD
         CLI -- "(Socket 映射)" --> Engine
     end
 ```
+
 - 使用轻量级虚拟机 (Apple Virtualization / WSL 2) 运行 Linux 内核
 - 文件挂载 (Bind Mount) 需要跨越 VM 边界 (这也是文件 I/O 慢的原因)
 - 网络端口需要从宿主机转发到 VM

12_implementation/12.4_ufs.md

@@ -102,6 +102,7 @@ Docker 的存储驱动经历了从早期各式各样的机制（如 aufs, device
 #### Classic Graph Drivers 与 Snapshotters 的核心差异
 
 传统模型（如 `overlay2`）将镜像拉取解包的过程由 Docker 的 graph drivers 处理。而新的 `containerd image store` 则将这一职责彻底下放给了 `containerd` 自身的 `snapshotters`（底层在 Linux 发行版通常依然利用操作系统的 overlayfs）。这种架构改变带来了：
+
 1. 本地免拉取查看多平台镜像 index manifest 与 attestations (SBOM、Provenance)。
 2. 避免了以前绕过 CRI 获取本地镜像的问题，带来更好的原生 Kubernetes 生态兼容性。
 
@@ -136,6 +137,7 @@ flowchart TD
     OverlayFS --> Lower2
     OverlayFS --> Lower1
 ```
+
 - **lowerdir**：只读的镜像层 (可以有多个)
 - **upperdir**：可写的容器层
 - **workdir**：OverlayFS 的工作目录

14_kubernetes_setup/14.1_kubeadm.md

@@ -175,6 +175,7 @@ $ sudo kubeadm init \
       --v 5 \
       --ignore-preflight-errors=all
 ```
+
 * `--pod-network-cidr 10.244.0.0/16` 参数与后续 CNI 插件有关，这里以 `flannel` 为例，若后续部署其他类型的网络插件请更改此参数。
 
 > 执行可能出现错误，例如缺少依赖包，根据提示安装即可。

14_kubernetes_setup/14.2_kubeadm-docker.md

@@ -195,6 +195,7 @@ $ sudo kubeadm init --image-repository registry.cn-hangzhou.aliyuncs.com/google_
       --v 5 \
       --ignore-preflight-errors=all
 ```
+
 * `--cri-socket unix:///var/run/cri-dockerd.sock` 参数指定使用 cri-dockerd 作为容器运行时接口。
 * `--pod-network-cidr 10.244.0.0/16` 参数与后续 CNI 插件有关，这里以 `flannel` 为例，若后续部署其他类型的网络插件请更改此参数。
 

16_cloud/16.3_alicloud.md

@@ -140,6 +140,7 @@ docker info | grep -A 5 "Registry Mirrors"
 #### Windows/Mac 配置
 
 在 Docker Desktop 的 Settings 中：
+
 1. 进入 “Docker Engine” 标签
 2. 编辑 JSON 配置，添加 `registry-mirrors` 字段
 3. 点击 “Apply & Restart”

17_ecosystem/17.6_containerd.md

@@ -23,6 +23,7 @@
 在早期，Docker 引擎是一个包含了所有功能的单体架构。随着技术的发展和标准化要求，Docker 将底层关于容器运行时的部分解耦出来，形成了 `containerd` 和 `runc`。
 
 当你执行一个 `docker run` 命令时，调用链路大致如下：
+
 1. Docker Client 发送请求给 Docker Daemon（`dockerd`）。
 2. `dockerd` 将请求转发给 `containerd`。
 3. `containerd` 准备好镜像和容器的必要环境，然后调用 `runc`。

18_security/18.2_control_group.md

@@ -25,6 +25,7 @@
 限制内存可以防止应用程序因内存泄漏或恶意载荷导致宿主机 OOM。
 
 **关键参数：**
+
 - `-m, --memory=""`：硬限制，容器可使用的最大内存量。
 - `--memory-swap=""`：限制容器可使用的内存与 Swap 总量。
 
@@ -46,6 +47,7 @@ $ docker run -d \
 限制 CPU 可以防止个别计算密集型的容器垄断 CPU 时间片，保证系统的调度公平性。
 
 **关键参数：**
+
 - `--cpus=<value>`：指定容器可以使用的 CPU 核心数量（可以是小数）。
 - `-c, --cpu-shares=0`：软限制，设置容器使用 CPU 的相对权重（默认是 1024）。
 
@@ -67,6 +69,7 @@ $ docker run -d \
 进程炸弹（Fork Bomb）是一种典型的拒绝服务攻击方式，它通过不断 `fork()` 新进程来耗尽系统的进程表条目，导致系统无法创建任何新任务。
 
 **关键参数：**
+
 - `--pids-limit=<number>`：限制容器内允许创建的最大进程数。
 
 **实战示例：**

18_security/18.3_daemon_sec.md

@@ -33,6 +33,7 @@ dockerd \
   --tlskey=server-key.pem \
   -H=0.0.0.0:2376
 ```
+
 3. 客户端想要连接时，也必须出示客户端证书。
 
 > [!TIP]
@@ -61,14 +62,17 @@ Rootless 模式允许在完全局限于非 `root` 用户的环境中运行 Docke
 ```bash
 $ sudo apt-get install uidmap
 ```
+
 2. 切换到一个没有任何 `sudo` 权限的普通用户（假设用户名为 `testuser`）：
 ```bash
 $ su - testuser
 ```
+
 3. 运行 Docker 官方提供的 Rootless 安装脚本：
 ```bash
 $ curl -fsSL https://get.docker.com/rootless | sh
 ```
+
 4. 配置环境变量指向新创建的私有 socket：
 ```bash
 $ export DOCKER_HOST=unix:///run/user/1000/docker.sock

18_security/18.6_image_security.md

@@ -9,6 +9,7 @@
 Trivy 是由 Aqua Security 开发的开源漏洞扫描器，以其轻量级、快速、准确而闻名，已成为业界标准。
 
 **优点：**
+
 - 零依赖，单个二进制文件
 - 扫描速度快（秒级）
 - 支持镜像、文件系统、Git 仓库多种扫描源
@@ -47,6 +48,7 @@ trivy image --severity HIGH,CRITICAL \
 Grype 由 Anchore 开发，支持更广泛的软件包管理器和语言。
 
 **优点：**
+
 - 支持 Java、Python、Go、Ruby、JavaScript 等多种语言的依赖检测
 - 与 Syft（SBOM 生成器）配合效果好
 - 可自定义漏洞数据库源
@@ -74,6 +76,7 @@ grype dir:/path/to/app
 Snyk 提供了商业级的安全扫描服务，特别适合企业环境。
 
 **特点：**
+
 - 支持开源漏洞和许可证扫描
 - 与多个 Git 平台深度集成（GitHub、GitLab、Bitbucket）
 - 提供修复建议和自动化修复 PR

19_observability/19.3_performance_optimization.md

@@ -9,6 +9,7 @@
 容器性能监控涉及以下关键指标：
 
 **CPU 相关指标：**
+
 - `cpu.usage_usec`：容器 CPU 使用时间（微秒）
 - `cpu.stat.nr_throttled`：CPU 限流发生次数
 - `cpu.stat.throttled_usec`：CPU 限流总时间
@@ -16,6 +17,7 @@
 - `cpu_quota`：CPU 配额设置（微秒）
 
 **内存相关指标：**
+
 - `memory.usage_bytes`：当前内存使用量
 - `memory.max_usage_bytes`：内存使用峰值
 - `memory.limit_in_bytes`：内存限制
@@ -25,6 +27,7 @@
 - `memory.stat.swap`：SWAP 使用量
 
 **网络相关指标：**
+
 - `rx_bytes`：接收字节数
 - `tx_bytes`：发送字节数
 - `rx_packets`：接收包数
@@ -35,6 +38,7 @@
 - `tx_dropped`：发送丢包数
 
 **I/O 相关指标：**
+
 - `io_service_bytes`：I/O 操作字节数
 - `io_service_time`：I/O 操作耗时
 - `io_queued`：I/O 队列长度

21_case_devops/21.5_ide.md

@@ -49,5 +49,6 @@
 
 * Linux 下如果遇到容器内写文件权限问题，优先确保容器内用户与宿主机 UID/GID 对齐。
   VS Code Dev Containers 支持自动处理；手写 Dockerfile/compose 时也可以显式设置用户。
+
 * 如果遇到文件变更监听不生效（常见于 macOS/Windows 的虚拟化文件系统），
   优先使用语言/工具支持的轮询模式或提高 watcher 限制。

appendix/learning_roadmap.md

@@ -9,6 +9,7 @@ Docker 学习可分为四个递进阶段，每个阶段都有明确的学习目
 #### 第一阶段：基础入门（0-2 周）
 
 **学习目标：**
+
 - 理解容器化的基本概念
 - 能够运行、管理基本的容器
 - 了解镜像和仓库的基本操作
@@ -36,11 +37,13 @@ Docker 安装配置
 └── 权限和用户配置
 ```
 **学习资源：**
+
 - [官方教程](https://docs.docker.com/get-started/)
 - 本书第 1-3 章：入门篇基础概念
 - [Docker CLI 参考](https://docs.docker.com/engine/reference/commandline/)
 
 **时间投入：**
+
 - 理论学习：3-4 小时
 - 实操练习：8-10 小时
 - 总计：2 周
@@ -57,6 +60,7 @@ Docker 安装配置
 #### 第二阶段：核心开发（2-6 周）
 
 **学习目标：**
+
 - 掌握 Dockerfile 编写
 - 能够构建自己的应用镜像
 - 理解数据管理和网络配置
@@ -110,11 +114,13 @@ Docker Compose
     └── build / push
 ```
 **学习资源：**
+
 - 本书第 4-11 章：进阶篇
 - [Docker 官方最佳实践](https://docs.docker.com/develop/dev-best-practices/)
 - [Dockerfile 参考](https://docs.docker.com/engine/reference/builder/)
 
 **时间投入：**
+
 - 理论学习：8-10 小时
 - 实操练习：30-40 小时（多个实战项目）
 - 总计：4-6 周
@@ -140,6 +146,7 @@ Docker Compose
 #### 第三阶段：生产优化（6-12 周）
 
 **学习目标：**
+
 - 掌握容器安全最佳实践
 - 理解性能监控和优化
 - 学会容器编排（Kubernetes 基础）
@@ -218,11 +225,13 @@ CI/CD 集成
 └── Kollabot
 ```
 **学习资源：**
+
 - 本书第 12-21 章：深入篇和实战篇
 - [Kubernetes 官方文档](https://kubernetes.io/docs/)
 - [CNCF 学习路线](https://landscape.cncf.io/)
 
 **时间投入：**
+
 - 理论学习：15-20 小时
 - 实操练习：60-80 小时（多个生产级项目）
 - 总计：6-12 周
@@ -254,6 +263,7 @@ CI/CD 集成
 #### 第四阶段：专家深造（12+ 周）
 
 **学习目标：**
+
 - 掌握 Kubernetes 高级特性
 - 理解容器运行时底层实现
 - 能够设计和优化大规模容器平台
@@ -318,6 +328,7 @@ DevOps 工程化
     └── 文档和最佳实践传播
 ```
 **贡献机会：**
+
 - [Kubernetes](https://github.com/kubernetes/kubernetes)
 - [Cilium](https://github.com/cilium/cilium)
 - [Prometheus](https://github.com/prometheus/prometheus)
@@ -484,6 +495,7 @@ docker stats / events / inspect
 #### Kubernetes 认证
 
 **认证路径：**
+
 1. **CKA - Certified Kubernetes Administrator**
    - 难度：高
    - 时间：3 小时（实操）