From 90536e9b85ce3e7bbdeb0765390c026059e0a9e7 Mon Sep 17 00:00:00 2001 From: yeasy Date: Fri, 4 Sep 2026 14:57:24 -0700 Subject: [PATCH] =?UTF-8?q?fix(=E4=B8=80=E8=87=B4=E6=80=A7):=20=E4=B8=A4?= =?UTF-8?q?=E5=A4=84=E7=9B=B8=E4=BA=92=E5=86=B2=E7=AA=81=E7=9A=84=E5=BB=BA?= =?UTF-8?q?=E8=AE=AE=EF=BC=8C=E5=85=B6=E4=B8=80=E4=BC=9A=E8=AE=A9=E8=AF=BB?= =?UTF-8?q?=E8=80=85=E6=82=84=E6=82=84=E5=A4=B1=E5=8E=BB=E6=9C=AC=E4=B9=A6?= =?UTF-8?q?=E6=8E=A8=E8=8D=90=E7=9A=84=E9=BB=98=E8=AE=A4=E5=90=8E=E7=AB=AF?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - 18.1 完整演示了如何开启 `userns-remap`，全程没有任何代价提示。但官方文档 明写「The containerd image store is not available when using user namespace remapping」，而本书基线是 Docker Engine v29.x——该版本新装默认就是 containerd image store，12.4 节还把它标为「强烈推荐（现代默认）」。照 18.1 做完，读者会在毫不知情的情况下退回旧存储后端，失去 OCI image index、多架构 镜像与构建溯源。补上这条互斥关系并交叉引用 12.4。 - 5 章说「生产环境建议指定确切版本号（如 nginx:1.28.0）而非仅大版本号」， 7 章说「使用主或次版本号而非完整版本号（patch）」并把 patch 版本列入 「避免」。两条都以全书建议的口吻写成，方向正好相反。它们其实面向不同环节： Dockerfile 的**基础镜像**用主/次版本号，才能在重新构建时自动带上安全补丁； **部署**一个服务镜像则应钉死确切版本，让部署可复现、升级是显式动作。 两处各补一句限定范围并互相指引，而不是删掉其中一条。 --- 05_container/README.md | 3 ++- 07_dockerfile/README.md | 3 ++- 18_security/18.1_kernel_ns.md | 6 ++++++ 3 files changed, 10 insertions(+), 2 deletions(-) diff --git a/05_container/README.md b/05_container/README.md index 6cc6f2b..52fefdc 100644 --- a/05_container/README.md +++ b/05_container/README.md @@ -14,7 +14,8 @@ - **镜像标签约定**： - `latest` 或 `v1.0.0` 等：带标签的自定义镜像，示例中指定具体版本 - `24.04`、`8.4`：官方镜像的稳定版本分支 - - 生产环境建议：指定确切版本号（如 `nginx:1.28.0`、`mysql:8.4.4`）而非仅大版本号 + - 生产环境建议：**运行/部署**服务镜像时指定确切版本号（如 `nginx:1.28.0`、`mysql:8.4.4`）而非仅大版本号，让每次部署可复现、升级是显式动作。 + （注意这与 [第 7 章](../07_dockerfile/README.md) 对 **Dockerfile 基础镜像** 的建议方向相反：基础镜像用主/次版本号，以便重新构建时自动带上补丁。两者面向的是不同环节。） * [启动容器](5.1_run.md) * [守护态运行](5.2_daemon.md) diff --git a/07_dockerfile/README.md b/07_dockerfile/README.md index 738041c..cf5e94a 100644 --- a/07_dockerfile/README.md +++ b/07_dockerfile/README.md @@ -89,7 +89,8 @@ docker build -t my-image:1.0 . 本章中的 Dockerfile 示例使用的基础镜像标签遵循以下原则： - **通用标签**（如 `ubuntu:24.04`、`alpine`、`nginx`）：保持原样，无需修改 -- **基础镜像版本号**（如 `node:22`、`python:3.12`）：使用主或次版本号而非完整版本号（patch），这样可以自动获取最新的补丁版本，确保获得安全更新 +- **基础镜像版本号**（如 `node:22`、`python:3.12`）：使用主或次版本号而非完整版本号（patch），这样可以自动获取最新的补丁版本，确保获得安全更新。 + （这条只针对 **Dockerfile 的基础镜像**；部署一个服务镜像时反而应钉死确切版本，见 [第 5 章](../05_container/README.md)。） - **避免**：不建议使用 `latest` 标签和完整的 patch 版本号（如 `20.10.0`）作为基础镜像，因为这会导致构建的不可重现性或安全风险 读者在使用这些示例时，应根据实际生产环境需求选择合适的版本号。 diff --git a/18_security/18.1_kernel_ns.md b/18_security/18.1_kernel_ns.md index c306645..074ab1a 100644 --- a/18_security/18.1_kernel_ns.md +++ b/18_security/18.1_kernel_ns.md @@ -45,6 +45,12 @@ Docker 守护进程在启动容器时，会在后台为容器创建一套独立 ``` 使用 `default` 值时，Docker 会自动在宿主机上创建一个名为 `dockremap` 的用户和用户组。 +> **注意其代价**：官方文档明确 **containerd image store 在启用 `userns-remap` 时不可用**。 +> 而本书基线是 Docker Engine v29.x，该版本新装默认就是 containerd image store， +> [12.4 节](../12_implementation/12.4_ufs.md) 也把它标为「强烈推荐（现代默认）」。 +> 也就是说，打开 userns-remap 会让你退回旧的镜像存储后端，失去 OCI image index、 +> 多架构镜像与构建溯源等能力。两者只能二选一，请按威胁模型权衡。 + 2. **验证子 UID 和子 GID 分配** Docker 会通过 `/etc/subuid` 和 `/etc/subgid` 文件为 `dockremap` 分配一个高位的 UID 范围：