From be09a95d0d95e64989850e8ff5022fc9dd2e3053 Mon Sep 17 00:00:00 2001 From: Baohua Yang Date: Mon, 2 Mar 2026 22:16:51 -0800 Subject: [PATCH] Refine words --- 09_network/summary.md | 2 +- 10_buildx/README.md | 3 ++ 11_compose/summary.md | 2 +- 12_implementation/12.4_ufs.md | 31 ++++++++++--------- 12_implementation/summary.md | 36 +++++++++------------- 14_kubernetes_setup/14.1_kubeadm.md | 1 - 14_kubernetes_setup/14.2_kubeadm-docker.md | 1 - 18_security/18.1_kernel_ns.md | 2 +- 21_case_devops/21.1_devops_workflow.md | 10 +++--- CHANGELOG.md | 11 +++++++ README.md | 2 +- appendix/best_practices.md | 2 +- 12 files changed, 54 insertions(+), 49 deletions(-) diff --git a/09_network/summary.md b/09_network/summary.md index af9daf9..3ed4216 100644 --- a/09_network/summary.md +++ b/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 等网络模式 diff --git a/10_buildx/README.md b/10_buildx/README.md index b1d7fdb..7f2d491 100644 --- a/10_buildx/README.md +++ b/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 或本地高效校验镜像的安全元数据。 diff --git a/11_compose/summary.md b/11_compose/summary.md index e07b0f9..57bf578 100644 --- a/11_compose/summary.md +++ b/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)：完整命令列表 diff --git a/12_implementation/12.4_ufs.md b/12_implementation/12.4_ufs.md index 9828fd9..89e396c 100644 --- a/12_implementation/12.4_ufs.md +++ b/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 ``` --- diff --git a/12_implementation/summary.md b/12_implementation/summary.md index 1d03b33..f6d68b3 100644 --- a/12_implementation/summary.md +++ b/12_implementation/summary.md @@ -1,7 +1,15 @@ ## 本章小结 +本章深入介绍了 Docker 的底层实现，包括命名空间、控制组和联合文件系统三大核心技术。 + +| 技术 | 作用 | 要点 | +|------|------|------| +| **Namespace** | 资源隔离 | PID、NET、MNT、UTS、IPC、USER 六种命名空间 | +| **Cgroups** | 资源限制 | 限制 CPU、内存、磁盘 I/O、进程数 | +| **Union FS** | 分层存储 | overlay2 为推荐驱动，支持 Copy-on-Write | + | Namespace | 隔离内容 | 一句话说明 | -|-----------|---------|-----------| +|-----------|---------|-----------| | PID | 进程 ID | 容器有自己的进程树 | | NET | 网络 | 容器有自己的 IP 和端口 | | MNT | 文件系统 | 容器有自己的根目录 | @@ -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 层的创建 diff --git a/14_kubernetes_setup/14.1_kubeadm.md b/14_kubernetes_setup/14.1_kubeadm.md index d9a00c0..8eaab88 100644 --- a/14_kubernetes_setup/14.1_kubeadm.md +++ b/14_kubernetes_setup/14.1_kubeadm.md @@ -292,7 +292,6 @@ kubelet 默认要求禁用 swap，否则可能导致初始化失败或节点无 $ sudo swapoff -a ## 如需永久禁用，可在 /etc/fstab 中注释 swap 对应行 - ``` ```bash diff --git a/14_kubernetes_setup/14.2_kubeadm-docker.md b/14_kubernetes_setup/14.2_kubeadm-docker.md index f51ec28..2270e27 100644 --- a/14_kubernetes_setup/14.2_kubeadm-docker.md +++ b/14_kubernetes_setup/14.2_kubeadm-docker.md @@ -78,7 +78,6 @@ kubelet 默认要求禁用 swap，否则可能导致初始化失败或节点无 $ sudo swapoff -a ## 如需永久禁用，可在 /etc/fstab 中注释 swap 对应行 - ``` ```bash diff --git a/18_security/18.1_kernel_ns.md b/18_security/18.1_kernel_ns.md index 59e933d..25ed1d2 100644 --- a/18_security/18.1_kernel_ns.md +++ b/18_security/18.1_kernel_ns.md @@ -22,7 +22,7 @@ Docker 守护进程在启动容器时，会在后台为容器创建一套独立 通过命名空间，Docker 也能限制进程从外部环境获取信息。 例如，由于进程环境被隔离，进程在内部其实是无法感知到外部宿主机的存在的。它既不能获取其他容器的进程列表，也无法通过网络与其他系统进行交互（除非经过配置）。 -### 18.1.1 用户命名空间 与提权防护 +### 18.1.3 用户命名空间与提权防护 在所有的 Namespace 中，**User Namespace** 对安全的影响尤为关键。 diff --git a/21_case_devops/21.1_devops_workflow.md b/21_case_devops/21.1_devops_workflow.md index 53cbf98..50a85b5 100644 --- a/21_case_devops/21.1_devops_workflow.md +++ b/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 管理环境特定的配置，不要打包进镜像。 diff --git a/CHANGELOG.md b/CHANGELOG.md index 0272337..dfecbba 100644 --- a/CHANGELOG.md +++ b/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 * 修复若干问题 diff --git a/README.md b/README.md index 9c1b30d..1d707a2 100644 --- a/README.md +++ b/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，可以让应用的部署、测试和分发都变得前所未有的高效和轻松！ diff --git a/appendix/best_practices.md b/appendix/best_practices.md index b20c007..4e49374 100644 --- a/appendix/best_practices.md +++ b/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` 指令都将产生新的镜像，缓存不会被使用。