Refine words

09_network/summary.md

@@ -12,7 +12,7 @@
 | **网络隔离** | 不同网络默认隔离，增强安全性 |
 | **--link** | 已废弃，使用自定义网络替代 |
 
-### 9.8.1 延伸阅读
+### 延伸阅读
 
 - [配置 DNS](9.1_dns.md)：自定义 DNS 设置
 - [网络类型](9.2_network_types.md)：Bridge、Host、None 等网络模式

10_buildx/README.md

@@ -11,3 +11,6 @@ Docker Buildx 是一个 docker CLI 插件，其扩展了 docker 命令，支持
 * [使用 BuildKit 构建镜像](10.1_buildkit.md)
 * [使用 Buildx 构建镜像](10.2_buildx.md)
 * [构建多种系统架构支持的 Docker 镜像](10.3_multi-arch-images.md)
+
+> **供应链安全与存储后端前瞻**：现代软件供应链中，镜像来源证明（Provenance，在 BuildKit 中默认以 `mode=min` 添加）和软件物料清单（SBOM，可通过 `--sbom=true` 显式开启）已经成为极其重要的构建产出。这些 Attestations 数据会作为 manifest 附着在 **镜像索引 (Image Index)** 上。
+> 正是基于此诉求，自 Docker Engine v29 开始默认启用的 `containerd image store` 提供对 Image Index 的完美本地支持能力，解决了传统经典存储后端（Classic Store）无法有效处理带 Attestations 镜像索引的瓶颈。这使得你可以利用 `docker buildx imagetools inspect` 等手段，甚至做到无需拉取完整镜像内容即可在 Registry 或本地高效校验镜像的安全元数据。

11_compose/summary.md

@@ -13,7 +13,7 @@ Docker Compose 是管理多容器应用的利器，通过 YAML 文件声明式
 | **查看日志** | `docker compose logs` 查看服务日志 |
 | **模板文件** | 支持 `services`、`networks`、`volumes` 等顶级配置 |
 
-### 11.10.1 延伸阅读
+### 延伸阅读
 
 - [Compose 模板文件](11.5_compose_file.md)：详细模板语法参考
 - [Compose 命令说明](11.4_commands.md)：完整命令列表

12_implementation/12.4_ufs.md

@@ -92,32 +92,33 @@ flowchart LR
 
 ### 12.4.4 Docker 支持的存储驱动
 
-Docker 可使用多种联合文件系统实现：
+Docker 的存储驱动经历了从早期各式各样的机制（如 aufs, devicemapper），到被广泛使用的现代经典 graph driver (`overlay2`)，再到当下（Engine v29 及以后）**默认启用的 containerd 镜像存储引擎（containerd image store）**的演进。
 
-| 存储驱动 | 说明 | 推荐程度 |
+| 存储后端 / 驱动 | 核心特性说明 | 推荐程度 |
 |---------|------|---------|
-| **overlay2**| 现代 Linux 默认驱动，性能优秀 | ✅**推荐** |
+| **containerd image store** | (v29+ 新一代默认引擎) 基于 containerd 的 snapshotters，原生支持 OCI image index、多架构镜像与 Attestations 构建溯源元数据存储。 | ✅**强烈推荐 (现代默认)** |
+| **overlay2**| (经典 Graph Driver) 传统架构下的现代 Linux 默认驱动，性能优秀，但在处理复杂溯源元数据（索引）时受限。 | ✅**推荐 (主要后备)** |
 | **aufs** | 早期默认，兼容性好 | 遗留系统 |
-| **btrfs** | 使用 Btrfs 子卷 | 特定场景 |
-| **zfs** | 使用 ZFS 数据集 | 特定场景 |
-| **devicemapper** | 块设备级存储 | 遗留系统 |
+| **btrfs** / **zfs** | 使用原生稳定文件系统快照能力 | 特定场景 |
+| **devicemapper** | 块设备级存储 | 遗留系统 (已被逐步弃用) |
 | **vfs** | 不使用 CoW，每层完整复制 | 仅测试 |
 
-#### 各发行版推荐
+#### Classic Graph Drivers 与 Snapshotters 的核心差异
 
-| Linux 发行版 | 推荐存储驱动 |
-|-------------|-------------|
-| Ubuntu 16.04+ | overlay2 |
-| Debian Stretch+ | overlay2 |
-| CentOS 7+ | overlay2 |
-| RHEL 8+ | overlay2 |
-| Fedora | overlay2 |
+传统模型（如 `overlay2`）将镜像拉取解包的过程由 Docker 的 graph drivers 处理。而新的 `containerd image store` 则将这一职责彻底下放给了 `containerd` 自身的 `snapshotters`（底层在 Linux 发行版通常依然利用操作系统的 overlayfs）。这种架构改变带来了：
+1. 本地免拉取查看多平台镜像 index manifest 与 attestations (SBOM、Provenance)。
+2. 避免了以前绕过 CRI 获取本地镜像的问题，带来更好的原生 Kubernetes 生态兼容性。
 
-#### 查看当前存储驱动
+#### 查看当前存储驱动与后端
 
 ```bash
+## 查看默认存储驱动 (Storage Driver)
 $ docker info | grep "Storage Driver"
 Storage Driver: overlay2
+
+## 在 Engine v29+ 中，可以通过如下输出验证是否开启了 containerd 镜像后端：
+$ docker info | grep "containerd image store"
+ containerd image store: true
 ```
 
 ---

12_implementation/summary.md

@@ -1,5 +1,13 @@
 ## 本章小结
 
+本章深入介绍了 Docker 的底层实现，包括命名空间、控制组和联合文件系统三大核心技术。
+
+| 技术 | 作用 | 要点 |
+|------|------|------|
+| **Namespace** | 资源隔离 | PID、NET、MNT、UTS、IPC、USER 六种命名空间 |
+| **Cgroups** | 资源限制 | 限制 CPU、内存、磁盘 I/O、进程数 |
+| **Union FS** | 分层存储 | overlay2 为推荐驱动，支持 Copy-on-Write |
+
 | Namespace | 隔离内容 | 一句话说明 |
 |-----------|---------|-----------| 
 | PID | 进程 ID | 容器有自己的进程树 |
@@ -9,13 +17,6 @@
 | IPC | 进程间通信 | 容器间 IPC 隔离 |
 | USER | 用户 ID | 容器 root ≠ 宿主机 root |
 
-### 12.7.1 延伸阅读
-
-- [控制组 (Cgroups)](12.3_cgroups.md)：资源限制机制
-- [联合文件系统](12.4_ufs.md)：分层存储的实现
-- [安全](../18_security/README.md)：容器安全实践
-- [Linux Namespace 官方文档](https://man7.org/linux/man-pages/man7/namespaces.7.html)
-
 | 资源 | 限制参数 | 示例 |
 |------|---------|------|
 | **内存** | `-m` | `-m 512m` |
@@ -24,21 +25,12 @@
 | **磁盘 I/O** | `--device-write-bps` | `--device-write-bps /dev/sda:10mb` |
 | **进程数** | `--pids-limit` | `--pids-limit=100` |
 
-### 12.7.2 延伸阅读
-
-- [命名空间](12.2_namespace.md)：资源隔离
-- [安全](../18_security/README.md)：容器安全概述
-- [Docker Stats](../05_container/README.md)：监控容器资源
-
-| 概念 | 说明 |
-|------|------|
-| **UnionFS** | 将多层目录联合挂载为一个文件系统 |
-| **Copy-on-Write** | 写时复制，修改时才复制到可写层 |
-| **overlay2** | Docker 默认推荐的存储驱动 |
-| **分层好处** | 镜像复用、快速构建、快速启动 |
-
-### 12.7.3 延伸阅读
+### 延伸阅读
 
+- [命名空间](12.2_namespace.md)：资源隔离机制详解
+- [控制组 (Cgroups)](12.3_cgroups.md)：资源限制机制
+- [联合文件系统](12.4_ufs.md)：分层存储的实现
+- [安全](../18_security/README.md)：容器安全实践
 - [镜像](../02_basic_concept/2.1_image.md)：理解镜像分层
 - [容器](../02_basic_concept/2.2_container.md)：容器存储层
 - [构建镜像](../04_image/4.5_build.md)：Dockerfile 层的创建

14_kubernetes_setup/14.1_kubeadm.md

@@ -292,7 +292,6 @@ kubelet 默认要求禁用 swap，否则可能导致初始化失败或节点无
 $ sudo swapoff -a
 
 ## 如需永久禁用，可在 /etc/fstab 中注释 swap 对应行
-
 ```
 
 ```bash

14_kubernetes_setup/14.2_kubeadm-docker.md

@@ -78,7 +78,6 @@ kubelet 默认要求禁用 swap，否则可能导致初始化失败或节点无
 $ sudo swapoff -a
 
 ## 如需永久禁用，可在 /etc/fstab 中注释 swap 对应行
-
 ```
 
 ```bash

18_security/18.1_kernel_ns.md

@@ -22,7 +22,7 @@ Docker 守护进程在启动容器时，会在后台为容器创建一套独立
 通过命名空间，Docker 也能限制进程从外部环境获取信息。
 例如，由于进程环境被隔离，进程在内部其实是无法感知到外部宿主机的存在的。它既不能获取其他容器的进程列表，也无法通过网络与其他系统进行交互（除非经过配置）。
 
-### 18.1.1 用户命名空间 与提权防护
+### 18.1.3 用户命名空间与提权防护
 
 在所有的 Namespace 中，**User Namespace** 对安全的影响尤为关键。
 

21_case_devops/21.1_devops_workflow.md

@@ -2,7 +2,7 @@
 
 本章将演示一个基于 Docker、Kubernetes 和 Jenkins/GitLab CI 的完整 DevOps 工作流。
 
-## 21.1.1 工作流概览
+### 21.1.1 工作流概览
 
 1. **Code**：开发人员提交代码到 GitLab。
 2. **Build**：GitLab CI 触发构建任务。
@@ -12,7 +12,7 @@
 6. **Verify**：人工或自动化验证。
 7. **Release (Production)**：审批后自动部署到生产环境。
 
-## 21.1.2 关键配置示例
+### 21.1.2 关键配置示例
 
 本节通过一组最小可用的片段，展示典型 DevOps 流程中与 Docker 相关的关键配置。
 
@@ -54,9 +54,9 @@ unit_test:
 
 build_image:
   stage: build
-  image: docker:20.10.16
+  image: docker:27
   services:
-    - docker:20.10.16-dind
+    - docker:27-dind
   script:
     - echo "$CI_REGISTRY_PASSWORD" | docker login -u "$CI_REGISTRY_USER" --password-stdin $CI_REGISTRY
     - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
@@ -76,7 +76,7 @@ deploy_staging:
     - develop
 ```
 
-## 21.1.3 最佳实践
+### 21.1.3 最佳实践
 
 1. **不可变基础设施**：一旦镜像构建完成，在各个环境（Dev、Staging、Prod）中都应该使用同一个镜像 tag（通常是 commit hash），而不是重新构建。
 2. **配置分离**：使用 ConfigMap 和 Secret 管理环境特定的配置，不要打包进镜像。

CHANGELOG.md

@@ -1,5 +1,16 @@
 # 修订记录
 
+* 1.6.1 2026-02-28
+  * 修正数据卷 `--mount` 与 `-v` 的行为差异及数据卷管理说明
+  * 补充 Docker Hub 限流机制说明，区分 pull rate limit 与 abuse rate limit
+  * 完善安全权限警告，强化用户加入 docker 组等同于 root 的风险意识
+  * 增补 Docker Engine v29 containerd image store 与 BuildKit provenance attestations 默认行为说明
+
+* 1.6.0 2026-02-20
+  * 全面统一使用 `docker compose` (V2) 为默认标准，提供 V1 迁移说明
+  * 修复全书大量排版错误，建立附录与正文的双向索引与引用
+  * 更新 Kubernetes 至 1.35 兼容说明及运行时环境提示
+
 * 1.5.4 2026-02-15
   * 移除 combine.py
   * 修复若干问题

README.md

@@ -2,7 +2,7 @@
 
 [![图](https://img.shields.io/github/stars/yeasy/docker_practice.svg?style=social&label=Stars)](https://github.com/yeasy/docker_practice) [![图](https://img.shields.io/github/release/yeasy/docker_practice/all.svg)](https://github.com/yeasy/docker_practice/releases) [![图](https://img.shields.io/badge/Based-Docker%20Engine%20v29.x-blue.svg)](https://docs.docker.com/engine/release-notes/) [![图](https://img.shields.io/badge/Docker%20%E6%8A%80%E6%9C%AF%E5%85%A5%E9%97%A8%E4%B8%8E%E5%AE%9E%E6%88%98-jd.com-red.svg)][1]
 
-**v1.6.2**
+**v1.6.3**
 
 [Docker](https://www.docker.com) 是个划时代的开源项目，它彻底释放了计算虚拟化的威力，极大提高了应用的维护效率，降低了云计算应用开发的成本！使用 Docker，可以让应用的部署、测试和分发都变得前所未有的高效和轻松！
 

appendix/best_practices.md

@@ -53,7 +53,7 @@ RUN apt-get update && apt-get install -y \
 
 * 从一个基础镜像开始 (`FROM` 指令指定)，下一条指令将和该基础镜像的所有子镜像进行匹配，检查这些子镜像被创建时使用的指令是否和被检查的指令完全一样。如果不是，则缓存失效。
 * 在大多数情况下，只需要简单地对比 `Dockerfile` 中的指令和子镜像。然而，有些指令需要更多的检查和解释。
-* 对于 `ADD` 和 `COPY` 指令，镜像中对应文件的内容也会被检查，每个文件都会计算出一个校验和。文件的最后修改时间和最后访问时间不会纳入校验。在缓存的查找过程中，会将这些校验和和已存在镜像中的文件校验和进行对比。如果文件有任何改变，比如内容和元数据，则缓存失效。
+* 对于 `ADD` 和 `COPY` 指令，镜像中对应文件的内容也会被检查，每个文件都会计算出一个校验和。文件的最后修改时间和最后访问时间不会纳入校验。在缓存的查找过程中，会将这些校验和与已存在镜像中的文件校验和进行对比。如果文件有任何改变，比如内容和元数据，则缓存失效。
 * 除了 `ADD` 和 `COPY` 指令，缓存匹配过程不会查看临时容器中的文件来决定缓存是否匹配。例如，当执行完 `RUN apt-get -y update` 指令后，容器中一些文件被更新，但 Docker 不会检查这些文件。这种情况下，只有指令字符串本身被用来匹配缓存。
 
 一旦缓存失效，所有后续的 `Dockerfile` 指令都将产生新的镜像，缓存不会被使用。