Add blank lines before lists per CommonMark

01_introduction/1.3_why.md

@@ -101,6 +101,7 @@ $ docker compose up
 #### 3. 资源效率
 
 Docker 容器共享宿主机内核，无需为每个应用运行完整的操作系统。以一台 64GB 内存的物理服务器为例：
+
 - **传统虚拟机方案**：每个虚拟机都需要运行完整的操作系统（每个额外占用如 2GB 内存），产生大量资源开销，实际可用于应用的内存可能只有约 18GB。
 - **Docker 方案**：容器直接共享宿主机系统，只需付出很少的基础开销（OS 及引擎约 4GB），即可将约 60GB 的内存全部用于实际应用。
 

02_basic_concept/2.2_container.md

@@ -27,6 +27,7 @@ flowchart TD
     end
 ```
 这种隔离主要通过 Linux 内核的 **Namespace** 实现，资源限制通常与 **cgroups** 配合。具体表现为：
+
 - **进程空间**：容器看不到宿主机上的其他进程。
 - **网络**：在默认网络模式下，容器通常拥有独立的网络命名空间，并可分配独立 IP；使用 `host` 或 `container:` 等模式时则例外。
 - **文件系统**：容器拥有独立的 root 目录。

03_install/README.md

@@ -23,6 +23,7 @@ Docker Engine 主要提供 `stable` 和 `test` 两个更新频道；`test.docker
 ### 国内用户的网络优化建议
 
 值得注意的是，国内直接访问 Docker 官方源速度较慢，建议：
+
 - **安装过程**：使用阿里云、腾讯云等国内镜像源
 - **镜像拉取**：安装完成后配置 Docker 镜像加速器（详见 [3.9 镜像加速器](3.9_mirror.md)），这一步对日常开发的体验提升最明显
 

06_repository/README.md

@@ -24,6 +24,7 @@
 - 推荐使用专业级方案（Nexus 3、Harbor）而非简单的 Registry
 
 本章涵盖的方案从简到复杂：
+
 - Docker Registry：最小化部署（适合简单场景）
 - 私有仓库高级配置：添加认证、HTTPS 等生产必需项
 - Nexus 3：企业级完整解决方案，支持权限管理、备份等

07_dockerfile/7.2_copy.md

@@ -5,6 +5,7 @@
 `COPY` 是在构建镜像时，将构建上下文（Dockerfile 所在目录及其子目录）中的文件或目录复制到容器内的指令。它是处理应用代码、配置文件最常用的方式。
 
 典型场景：
+
 - 复制应用源码：`COPY . /app`
 - 复制配置文件：`COPY nginx.conf /etc/nginx/nginx.conf`
 - 复制静态资源：`COPY public /app/public`

07_dockerfile/7.4_cmd.md

@@ -5,6 +5,7 @@
 在深入 CMD 的细节之前，我们需要理解一个关键问题：**CMD 和 ENTRYPOINT 应该在什么时候使用？**
 
 这是 Dockerfile 使用中最常见的困惑之一。简单的答案是：
+
 - **CMD**：定义容器的”默认命令”。如果用户在 `docker run` 时提供命令，CMD 会被覆盖
 - **ENTRYPOINT**：定义容器的”入口脚本”。通常用于启动应用的某个特定部分
 

16_cloud/16.2_tencentCloud.md

@@ -21,6 +21,7 @@
 #### 1. 创建集群
 
 登录腾讯云控制台，进入容器服务模块：
+
 - 选择 “创建集群”，配置集群名称、地域和网络
 - 选择节点配置（云服务器规格和数量）
 - 设置 Kubernetes 版本和安全组

16_cloud/16.3_alicloud.md

@@ -26,6 +26,7 @@
 #### 1. 创建集群
 
 登录阿里云控制台，进入容器服务 > Kubernetes 集群：
+
 - 点击 “创建集群”，选择集群配置
 - 配置集群名称、地域、可用区和节点类型
 - 选择节点规格和数量（支持弹性伸缩）

17_ecosystem/17.5_skopeo.md

@@ -62,6 +62,7 @@ $ skopeo copy docker://docker.io/library/alpine:latest docker://registry.example
 $ skopeo copy docker://docker.io/library/alpine:latest oci:alpine-oci
 ```
 如果我们要将本地的某个目录下的打包好的镜像再次推向 Registry 或转换为其它存储类型也是完全支持的，诸如：
+
 - `docker://` 远端 Registry
 - `docker-archive:` / `docker-daemon:` Docker 对应的归档文件或本地守护进程
 - `oci:` / `oci-archive:` OCI 相关文件格式

17_ecosystem/17.6_containerd.md

@@ -7,6 +7,7 @@
 [containerd](https://containerd.io/) 是一个行业标准的容器运行时，它最初是由 Docker 引擎中剥离出来的一个核心组件，后来 Docker 将其捐赠给了云原生计算基金会（CNCF），目前已经是一个 CNCF 毕业（Graduated）项目。
 
 它的主要职责是管理单个宿主机上完整的容器生命周期，包括：
+
 - 镜像的传输和存储
 - 容器执行和管理
 - 存储和网络接口的管理
@@ -40,6 +41,7 @@ Kubernetes 作为一个容器编排系统，为了屏蔽底层不同容器运行
 ### 17.6.3 为什么直接使用 containerd？
 
 对普通应用开发者来说，Docker 依然是本地开发和测试的首选。但对于构建云平台、自动化流水线或深度管理 Kubernetes 集群的系统工程师来说，直接使用 containerd 可以带来：
+
 - **更高的性能与更少的开销**：去掉了 Docker Daemon 等附加组件的资源占用，链路更短。
 - **更强的稳定性**：作为专注于运行时的底层组件，它的核心功能极为稳定且更新受控。
 - **直接符合 Kubernetes CRI 标准**：在生产级 Kubernetes 集群中作为标准配置。

18_security/18.2_control_group.md

@@ -9,6 +9,7 @@
 默认情况下，Docker 容器对系统资源的使用是没有限制的：一个容器理论上可以使用宿主机所有的 CPU 计算能力、吃光所有的内存、耗尽所有的系统 PID。
 
 想象一下以下场景：
+
 - 一个恶意用户向你暴露在公网的应用发起海量并发请求。
 - 应用程序逻辑中存在内存泄漏漏洞。
 - 黑客在入侵容器后，在里面运行了挖矿木马程序。

18_security/18.3_daemon_sec.md

@@ -81,6 +81,7 @@ $ docker version
 在企业环境中，对 Docker 守护进程的访问控制往往不仅限于文件系统权限，还需要更细粒度的授权策略。**Authorization Plugin** 机制允许在 API 层级对请求进行拦截和审批。
 
 常见的授权插件包括：
+
 - **OPA/Conftest**：开放策略引擎，支持声明式策略定义。
 - **Prisma Cloud（Twistlock）**：商业容器安全平台。
 - 自定义脚本：根据请求内容（镜像、命令、用户等）做出允许/拒绝决定。

18_security/18.4_kernel_capability.md

@@ -9,12 +9,14 @@
 在默认情况下，即便一个容器是在以 `root` 用户运行，Docker 也只为其内核授予了所有可用能力中的 **一小部分“白名单”能力**。
 
 常见的 Linux Capabilities 包含：
+
 - `CAP_CHOWN`: 修改文件所有者。
 - `CAP_NET_BIND_SERVICE`: 绑定特权端口（即 1024 以下的端口）。
 - `CAP_NET_ADMIN`: 网络管理的最高权限（例如调整路由配置，设置防火墙规则等）。
 - `CAP_SYS_ADMIN`: 被誉为“Linux 内核的特权网管”，允许各种高危操作（挂载磁盘、访问敏感设备等）。
 
 为了在 **“最小特权原则”** 的指导下加强安全，Docker 默认 **移除了** 大量可能导致容器大范围破坏宿主机的能力，例如：
+
 * 完全禁止了任何通过 `CAP_SYS_ADMIN` 进行的核心挂载或设备操作。
 * 禁止修改内核模块。
 * 禁止直接访问硬件套接字。

18_security/18.5_other_feature.md

@@ -43,6 +43,7 @@ chmod: /etc/passwd: Operation not permitted
 传统的 Linux 模型遵循 DAC（自主访问控制），这意味着如果一个文件被赋予了全员读写权限（`777`），普通隔离下任何人便都能修改。但 **MAC（强制访问控制）** 技术，诸如 `AppArmor` (常用于 Ubuntu/Debian) 或 `SELinux` (常用于 CentOS/RHEL)，可以制定比“文件所有权”更宏观且优先的策略控制模块。
 
 在开启了上述机制的机器上：
+
 - **AppArmor**: Docker 为所有启动的应用加载了一个默认的 `docker-default` 模板文件，如果你的某些异常写行为（比如往特殊的内核心脏目录写入配置）不在 AppArmor 许可列表之上，即使拥有物理 Root，写入同样失败。
 - **SELinux**: 所有的 Docker 操作强制附加特殊上下文标识标签。就算把主机的 `/` 绑定给了黑客的某服务，黑客对不属于 Docker 可见的标签的文件进行读写尝试亦会被阻止。
 

18_security/18.6_image_security.md

@@ -530,6 +530,7 @@ push:
 **Q: 扫描报告中有过时的 CVE，如何处理？**
 
 A: 某些 CVE 可能已经被修复但数据库未更新，可以：
+
 - 手动验证安全补丁是否已应用
 - 使用工具的忽略列表功能（如 Trivy 的 `.trivyignore`）
 - 定期更新扫描工具和漏洞数据库
@@ -537,6 +538,7 @@ A: 某些 CVE 可能已经被修复但数据库未更新，可以：
 **Q: 如何平衡镜像大小和安全性？**
 
 A:
+
 - 使用多阶段构建减少最终镜像大小
 - 使用精简基础镜像（Alpine、Distroless）
 - 定期更新依赖而不是一味求小
@@ -545,6 +547,7 @@ A:
 **Q: 如何管理和轮换签名密钥？**
 
 A:
+
 - 在密钥管理系统（如 HashiCorp Vault）中存储密钥
 - 定期轮换密钥（建议每 90 天）
 - 使用 Keyless 签名消除密钥管理复杂性

19_observability/19.3_performance_optimization.md

@@ -122,6 +122,7 @@ networks:
     driver: bridge
 ```
 启动后访问 `http://localhost:8080` 查看：
+
 - 容器性能统计
 - 系统资源使用情况
 - 历史性能数据

appendix/learning_roadmap.md

@@ -419,6 +419,7 @@ Kubernetes 进阶 (Week 24-36)
 **Docker Certified Associate (DCA)**
 
 考试信息：
+
 - 题目数：55 道
 - 时间限制：90 分钟
 - 及格分数：73%（约 41 道题）