Update Grafana to v13, add version notes

04_image/4.6_other.md

@@ -10,6 +10,8 @@
 
 比如我们想要创建一个 [OpenVZ](https://openvz.org) 的 Ubuntu 16.04 [模板](https://wiki.openvz.org/Download/template/precreated)的镜像：
 
+> **版本提示**：示例中的 Ubuntu 16.04 (Xenial) 已于 2021 年 4 月停止支持。如果用于生产环境，建议更新至 Ubuntu 22.04 LTS 或更新版本。
+
 ```bash
 $ docker import \
     http://download.openvz.org/template/precreated/ubuntu-16.04-x86_64.tar.gz \
@@ -50,6 +52,8 @@ $ docker image ls alpine
 REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
 alpine              latest              baa5d63471ea        5 weeks ago         4.803 MB
 ```
+
+> **版本提示**：`alpine:latest` 为最新版本的 Alpine Linux。如果需要特定版本号（如 `alpine:3.20`），可以明确指定以确保可重现性。
 保存镜像的命令为：
 
 ```bash

04_image/4.7_internal.md

@@ -60,6 +60,8 @@ Docker 镜像的每一层都有一个唯一的 ID，这个 ID 是根据该层的
 
 Docker 使用联合文件系统 (Union FS) 与写时复制思路来实现这种分层挂载。传统的实现方式常见于 `overlay2`、`aufs`、`btrfs`、`zfs` 等存储驱动；而在 Docker Engine 29.0 及之后的全新安装中，默认镜像后端已经变为 containerd image store，它使用 snapshotter 来管理这些层。
 
+> **版本背景**：Docker Engine 29.0（发布于 2024 年 2 月）是一个重要版本分界点，引入了 containerd image store 作为默认镜像存储后端。这对镜像管理、OCI 合规性和供应链安全都有深远影响。如果你的 Docker 版本低于 29.0，镜像存储仍使用传统的 classic store 路径。
+
 虽然底层实现细节不同，但它们都遵循上述的 **分层 + CoW** 模型；因此，无论你看到的是 `overlay2` 还是 containerd snapshotter，理解镜像层、容器层和写时复制的方式都是一样重要的。
 
 > 想要深入了解 Overlay2 等文件系统的具体实现原理，包括 WorkDir、UpperDir、LowerDir 等底层细节，请阅读 **[第十二章 底层实现](../12_implementation/README.md)** 中的 **[联合文件系统](../12_implementation/12.4_ufs.md)** 章节。

05_container/5.1_run.md

@@ -29,6 +29,8 @@ Hello world
 ```
 这与直接执行 `/bin/echo 'Hello world'` 几乎没有区别，但实际上已经启动了一个完整的 Ubuntu 容器来执行这条命令。
 
+> **版本说明**：示例使用 `ubuntu:24.04`，这是最新 LTS 版本。如需其他版本，可替换为 `ubuntu:22.04`、`ubuntu:20.04` 等。
+
 #### 交互式容器
 
 启动一个可以交互的 bash 终端：
@@ -82,25 +84,25 @@ flowchart TD
 
 | 选项 | 说明 | 示例 |
 |------|------|------|
-| `-d` | 后台运行 (detach)| `docker run -d nginx` |
+| `-d` | 后台运行 (detach)| `docker run -d nginx:latest` |
-| `-it` | 交互式终端 | `docker run -it ubuntu bash` |
+| `-it` | 交互式终端 | `docker run -it ubuntu:24.04 bash` |
-| `--name` | 指定容器名称 | `docker run --name myapp nginx` |
+| `--name` | 指定容器名称 | `docker run --name myapp nginx:latest` |
-| `--rm` | 退出后自动删除容器 | `docker run --rm ubuntu echo hi` |
+| `--rm` | 退出后自动删除容器 | `docker run --rm ubuntu:24.04 echo hi` |
 
 #### 端口映射
 
 ```bash
 ## 将容器的 80 端口映射到宿主机的 8080 端口
 
-$ docker run -d -p 8080:80 nginx
+$ docker run -d -p 8080:80 nginx:latest
 
 ## 随机映射端口
 
-$ docker run -d -P nginx
+$ docker run -d -P nginx:latest
 
 ## 只绑定到 localhost
 
-$ docker run -d -p 127.0.0.1:8080:80 nginx
+$ docker run -d -p 127.0.0.1:8080:80 nginx:latest
 ```
 
 #### 数据卷挂载
@@ -108,15 +110,15 @@ $ docker run -d -p 127.0.0.1:8080:80 nginx
 ```bash
 ## 挂载命名卷
 
-$ docker run -v mydata:/data nginx
+$ docker run -v mydata:/data nginx:latest
 
 ## 挂载宿主机目录
 
-$ docker run -v /host/path:/container/path nginx
+$ docker run -v /host/path:/container/path nginx:latest
 
 ## 只读挂载
 
-$ docker run -v /host/path:/container/path:ro nginx
+$ docker run -v /host/path:/container/path:ro nginx:latest
 ```
 
 #### 环境变量
@@ -136,11 +138,11 @@ $ docker run --env-file .env myapp
 ```bash
 ## 限制内存
 
-$ docker run -m 512m nginx
+$ docker run -m 512m nginx:latest
 
 ## 限制 CPU
 
-$ docker run --cpus=1.5 nginx
+$ docker run --cpus=1.5 nginx:latest
 ```
 
 ### 5.1.5 启动已终止容器
@@ -186,11 +188,11 @@ root@ba267838cc1b:/# ps
 ```bash
 ## 这个容器会立即退出（echo 执行完就结束了）
 
-$ docker run ubuntu echo "hello"
+$ docker run ubuntu:24.04 echo "hello"
 
 ## 解决：使用能持续运行的命令
 
-$ docker run -d nginx  # nginx 是持续运行的服务
+$ docker run -d nginx:latest  # nginx 是持续运行的服务
 ```
 详细解释见[后台运行](5.2_daemon.md)。
 
@@ -201,11 +203,11 @@ $ docker run -d nginx  # nginx 是持续运行的服务
 ```bash
 ## 错误：没有 -p 参数，外部无法访问
 
-$ docker run -d nginx
+$ docker run -d nginx:latest
 
 ## 正确：映射端口
 
-$ docker run -d -p 80:80 nginx
+$ docker run -d -p 80:80 nginx:latest
 ```
 
 #### Q：容器内修改的文件丢失

05_container/5.2_daemon.md

@@ -122,17 +122,19 @@ $ docker container ls -a
 ```bash
 ## Web 服务器
 
-$ docker run -d -p 80:80 nginx
+$ docker run -d -p 80:80 nginx:latest
 
 ## 数据库
 
-$ docker run -d -p 3306:3306 mysql:8
+$ docker run -d -p 3306:3306 mysql:8.0
 
 ## 缓存服务
 
-$ docker run -d -p 6379:6379 redis
+$ docker run -d -p 6379:6379 redis:latest
 ```
 
+> **版本说明**：示例使用常见的标签如 `latest` 或稳定大版本号如 `mysql:8.0`。具体版本可根据需求调整，生产环境建议明确指定版本号（如 `mysql:8.0.35`）而非使用 `latest`。
+
 #### 2. 调试时先用前台模式
 
 当容器启动有问题时，**去掉 `-d` 参数** 可以直接看到输出和错误：
@@ -140,7 +142,7 @@ $ docker run -d -p 6379:6379 redis
 ```bash
 ## 有问题的容器，先前台运行看看发生了什么
 
-$ docker run myimage:latest
+$ docker run myimage:v1.0.0
 ```
 
 #### 3. 使用 --rm 自动清理
@@ -161,7 +163,7 @@ Hello, World!
 ```bash
 ## 后台启动
 
-$ docker run -d --name myapp myimage:latest
+$ docker run -d --name myapp myimage:v1.0.0
 
 ## 查看最近 100 行日志
 
@@ -194,7 +196,7 @@ $ docker logs -t myapp
 
 3. **以交互模式调试**：
    ```bash
-   $ docker run -it myimage:latest /bin/sh
+   $ docker run -it myimage:v1.0.0 /bin/sh
    # 进入容器手动执行命令，查找问题
 
    ```

05_container/5.3_stop.md

@@ -204,7 +204,7 @@ $ docker stop $(docker ps -q) && docker container prune -f
 ```dockerfile
 ## Dockerfile 示例
 
-FROM node:22
+FROM node:22-alpine
 ...
 
 ## 使用 exec 形式确保信号能传递给 node 进程
@@ -212,6 +212,8 @@ FROM node:22
 CMD ["node", "server.js"]
 ```
 
+> **版本说明**：示例使用 `node:22-alpine`，这是一个精简的 Node.js 22 版本镜像。可根据需求替换为其他版本（如 `node:20-alpine`、`node:latest`）。
+
 #### Q：容器无法停止
 
 ```bash

05_container/5.5_import_export.md

@@ -13,6 +13,8 @@ $ docker export 7691a814370e > ubuntu.tar
 ```
 这样将导出容器快照到本地文件。
 
+> **版本说明**：导出的容器快照不包含镜像版本历史，导入时可以自定义标签和版本号。
+
 ### 5.5.2 导入容器快照
 
 可以使用 `docker import` 从容器快照文件中再导入为镜像，例如

05_container/README.md

@@ -6,6 +6,16 @@
 
 本章将具体介绍如何来管理一个容器，包括创建、启动和停止等。
 
+## 版本号说明
+
+本章示例涉及多个 Docker 镜像，遵循以下版本号最佳实践：
+
+- **官方镜像**（如 `ubuntu`、`nginx`、`mysql`）：使用具体大版本号（如 `ubuntu:24.04`、`mysql:8.0`）而非 `latest`，确保示例的可重复性
+- **镜像标签约定**：
+  - `latest` 或 `v1.0.0` 等：带标签的自定义镜像，示例中指定具体版本
+  - `24.04`、`8.0`：官方镜像的稳定版本分支
+  - 生产环境建议：指定精确版本号（如 `nginx:1.24.0`、`mysql:8.0.35`）而非仅大版本号
+
 * [启动容器](5.1_run.md)
 * [守护态运行](5.2_daemon.md)
 * [终止容器](5.3_stop.md)

06_repository/6.2_registry.md

@@ -15,15 +15,17 @@
 你可以使用官方 `registry` 镜像来运行。
 
 ```bash
-$ docker run -d -p 5000:5000 --restart=always --name registry registry
+$ docker run -d -p 5000:5000 --restart=always --name registry registry:2
 ```
+
+> **版本说明**：使用 `registry:2` 表示 Docker Registry 2.x 版本，这是当前推荐的版本。旧版本 Registry 1.x 已停止维护，不建议使用。
 这将使用官方的 `registry` 镜像来启动私有仓库。默认情况下，仓库会被创建在容器的 `/var/lib/registry` 目录下。你可以通过 `-v` 参数来将镜像文件存放在本地的指定路径。例如下面的例子将上传的镜像放到本地的 `/opt/data/registry` 目录。
 
 ```bash
 $ docker run -d \
     -p 5000:5000 \
     -v /opt/data/registry:/var/lib/registry \
-    registry
+    registry:2
 ```
 
 ### 6.2.2 在私有仓库上传、搜索、下载镜像

06_repository/6.3_registry_auth.md

@@ -122,11 +122,13 @@ $ mkdir auth
 
 $ docker run --rm \
     --entrypoint htpasswd \
-    httpd:alpine \
+    httpd:2.4-alpine \
     -Bbn username password > auth/nginx.htpasswd
 ```
 > 将上面的 `username` `password` 替换为你自己的用户名和密码。
 
+> **版本说明**：使用 `httpd:2.4-alpine` 基于 Apache 2.4 的精简镜像。如需其他版本，可替换为 `httpd:latest` 或指定具体版本号如 `httpd:2.4.58-alpine`。
+
 ### 6.3.4 编辑 Docker Compose 配置
 
 编辑 `compose.yaml` (或 `docker-compose.yml`) 配置如下：
@@ -134,7 +136,7 @@ $ docker run --rm \
 ```yaml
 services:
   registry:
-    image: registry
+    image: registry:2
     ports:
       - "443:443"
     volumes:
@@ -145,6 +147,8 @@ volumes:
   registry-data:
 ```
 
+> **版本说明**：Compose 配置中明确指定 `registry:2` 版本。生产环境建议固定版本号（如 `registry:2.8.3`）而非使用 `latest`，以保证部署的可重复性。
+
 ### 6.3.5 修改 Hosts 文件
 
 编辑 `/etc/hosts`
@@ -187,6 +191,8 @@ $ docker image rm docker.domain.com/username/ubuntu:24.04
 
 $ docker pull docker.domain.com/username/ubuntu:24.04
 ```
+
+> **版本说明**：示例使用 `ubuntu:24.04`，这是最新 LTS 版本。推送到私有仓库时保持了原有的版本标签，建议生产环境明确指定镜像版本号。
 如果我们退出登录，尝试推送镜像。
 
 ```bash

06_repository/6.4_nexus3_registry.md

@@ -8,8 +8,10 @@
 $ docker run -d --name nexus3 --restart=always \
     -p 8081:8081 \
     --mount src=nexus-data,target=/nexus-data \
-    sonatype/nexus3
+    sonatype/nexus3:3.69
 ```
+
+> **版本说明**：使用 `sonatype/nexus3:3.69` 指定稳定的 Nexus 版本。使用具体版本号而非 `latest` 可以避免意外升级带来的不兼容问题。
 首次运行需等待 3-5 分钟，你可以使用 `docker logs nexus3 -f` 查看日志：
 
 ```bash
@@ -18,10 +20,12 @@ $ docker logs nexus3 -f
 2021-03-11 15:31:21,990+0000 INFO  [jetty-main-1] *SYSTEM org.sonatype.nexus.bootstrap.jetty.JettyServer -
 -------------------------------------------------
 
-Started Sonatype Nexus OSS 3.30.0-01
+Started Sonatype Nexus OSS 3.69.0
 
 -------------------------------------------------
 ```
+
+> **版本说明**：上述日志中显示的是 Nexus 3.69 版本的启动日志。具体版本号会随着容器镜像版本而不同。
 如果你看到以上内容，说明 `Nexus` 已经启动成功，你可以使用浏览器打开 `http://YourIP:8081` 访问 `Nexus` 了。
 
 首次运行请通过以下命令获取初始密码：

06_repository/README.md

@@ -6,6 +6,16 @@
 
 大部分时候，并不需要严格区分这两者的概念。
 
+## 版本号说明
+
+本章涉及的 Registry 和相关工具版本说明：
+
+- **Docker Registry**：使用 `registry:2` 推荐版本，已停止维护的 `registry:1` 不建议使用
+- **Nexus 3**：建议指定具体版本（如 `sonatype/nexus3:3.69`）而非 `latest`，避免自动升级带来的兼容性问题
+- **镜像标签规范**：
+  - 生产环境推送至仓库时应明确指定版本号（如 `myapp:v1.0.0`）
+  - 避免依赖 `latest` 标签，因为其含义存在歧义且易导致版本混淆
+
 ## 为什么需要私有仓库？
 
 在讨论具体的安装和配置前，让我们先理解：**什么时候你应该建设私有仓库？**

07_dockerfile/7.10_workdir.md

@@ -82,6 +82,7 @@ RUN pwd    # 输出 /app
 
 ```docker
 ## 构建阶段
+## 建议使用 node:20 或 node: 等具体版本标签，避免使用 latest
 
 FROM node:20 AS builder
 WORKDIR /build
@@ -91,6 +92,7 @@ COPY . .
 RUN npm run build
 
 ## 生产阶段
+## 建议使用 nginx:alpine 或其他具体版本
 
 FROM nginx:alpine
 WORKDIR /usr/share/nginx/html
@@ -103,6 +105,7 @@ COPY --from=builder /build/dist .
 #### 1. 尽早设置 WORKDIR
 
 ```docker
+# 建议使用 node:20 等主/次版本号标签
 FROM node:20
 WORKDIR /app    # 尽早设置
 

07_dockerfile/7.12_healthcheck.md

@@ -34,6 +34,7 @@ Starting ──成功──> Healthy ──失败N次──> Unhealthy
 #### Web 服务检查
 
 ```docker
+# 注：nginx 镜像推荐使用具体的版本标签（如 nginx:1.25-alpine）
 FROM nginx
 RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/*
 

07_dockerfile/7.18_multistage_builds_laravel.md

@@ -60,6 +60,7 @@ server {
 第一阶段进行前端构建。
 
 ```docker
+# 注：node 镜像推荐使用具体的版本标签（如 node:20-alpine）
 FROM node:alpine as frontend
 
 COPY package.json /app/
@@ -81,6 +82,7 @@ RUN set -x ; cd /app \
 第二阶段安装 Composer 依赖。
 
 ```docker
+# 注：composer 镜像推荐使用具体的版本标签（如 composer:2.x）
 FROM composer as composer
 
 COPY database/ /app/database/
@@ -101,6 +103,7 @@ RUN set -x ; cd /app \
 第三阶段对以上阶段生成的文件进行整合。
 
 ```docker
+# 注：php 镜像版本号已包含 major.minor（8.3），生产环境可根据需要调整
 FROM php:8.3-fpm-alpine as laravel
 
 ARG LARAVEL_PATH=/app/laravel
@@ -125,6 +128,7 @@ RUN set -x ; cd ${LARAVEL_PATH} \
 ### 7.18.5 最后一个阶段构建 NGINX 镜像
 
 ```docker
+# 注：nginx 镜像推荐使用具体的版本标签（如 nginx:1.25-alpine）
 FROM nginx:alpine as nginx
 
 ARG LARAVEL_PATH=/app/laravel
@@ -175,6 +179,7 @@ $ docker run -dit --rm --network=laravel -p 8080:80 my/nginx
 完整的 `Dockerfile` 文件如下。
 
 ```docker
+# 注：生产环境推荐使用具体的版本标签，如 node:20-alpine、composer:2.x、php:8.3-fpm-alpine、nginx:1.25-alpine
 FROM node:alpine as frontend
 
 COPY package.json /app/
@@ -225,6 +230,7 @@ RUN set -x ; cd ${LARAVEL_PATH} \
       && php artisan package:discover
 
 FROM nginx:alpine as nginx
+```
 
 ARG LARAVEL_PATH=/app/laravel
 

07_dockerfile/7.5_entrypoint.md

@@ -164,6 +164,7 @@ curl -s http://myip.ipip.net -i
 #### 实现方式
 
 ```docker
+# 建议使用 redis:7 或 redis:latest，具体版本号根据生产需求选择
 FROM redis:7-alpine
 COPY docker-entrypoint.sh /usr/local/bin/
 ENTRYPOINT ["docker-entrypoint.sh"]
@@ -216,6 +217,7 @@ docker-entrypoint.sh redis-server   docker-entrypoint.sh bash
 ### 7.5.6 场景三：带参数的应用
 
 ```docker
+# 建议使用 python:3.12 或 python:3，具体版本号根据应用兼容性需求选择
 FROM python:3.12-slim
 WORKDIR /app
 COPY . .

07_dockerfile/7.6_env.md

@@ -18,14 +18,14 @@ ENV <key1>=<value1> <key2>=<value2> ...
 #### 设置单个变量
 
 ```docker
-ENV NODE_VERSION 20.10.0
+ENV NODE_VERSION 20
 ENV APP_ENV production
 ```
 
 #### 设置多个变量
 
 ```docker
-ENV NODE_VERSION=20.10.0 \
+ENV NODE_VERSION=20 \
     APP_ENV=production \
     APP_NAME="My Application"
 ```
@@ -158,15 +158,15 @@ $ docker build --build-arg NODE_VERSION=18 -t myapp .
 ```docker
 ## ✅ 好：版本集中管理
 
-ENV NGINX_VERSION=1.25.0 \
+ENV NGINX_VERSION=1.25 \
-    NODE_VERSION=20.10.0 \
+    NODE_VERSION=20 \
-    PYTHON_VERSION=3.12.0
+    PYTHON_VERSION=3.12
 
 RUN apt-get install nginx=${NGINX_VERSION}
 
 ## ❌ 差：版本分散在各处
 
-RUN apt-get install nginx=1.25.0
+RUN apt-get install nginx=1.25
 ```
 
 #### 2. 不要存储敏感信息

07_dockerfile/7.7_arg.md

@@ -35,6 +35,7 @@ ARG <参数名>[=<默认值>]
 
 ```docker
 ## 定义有默认值的 ARG
+## 建议使用主版本号，如 20 而非 20.10.0，这样可以自动获取最新的补丁版本
 
 ARG NODE_VERSION=20
 
@@ -113,17 +114,19 @@ RUN echo "Running with Node $NODE_VERSION"
 #### 1. 控制基础镜像版本
 
 ```docker
-ARG ALPINE_VERSION=3.19
+# 推荐使用主版本号（如 3），或指定次版本号（如 3.19），避免指定完整补丁版本
+ARG ALPINE_VERSION=3
 FROM alpine:${ALPINE_VERSION}
 ```
 ```bash
-$ docker build --build-arg ALPINE_VERSION=3.18 .
+$ docker build --build-arg ALPINE_VERSION=3.19 .
 ```
 
 #### 2. 设置软件版本
 
 ```docker
-ARG NGINX_VERSION=1.25.0
+# 使用次版本号 (1.25) 而非完整版本号 (1.25.0)，以便自动更新到最新补丁版本
+ARG NGINX_VERSION=1.25
 
 RUN curl -fsSL https://nginx.org/download/nginx-${NGINX_VERSION}.tar.gz | tar -xz
 ```
@@ -197,7 +200,7 @@ $ docker build --build-arg HTTP_PROXY=http://proxy:8080 .
 #### 1. 为 ARG 提供合理默认值
 
 ```docker
-## ✅ 好：有默认值
+## ✅ 好：有默认值，建议使用主或次版本号而非完整版本号
 
 ARG NODE_VERSION=20
 
@@ -222,12 +225,13 @@ RUN echo "password=$DB_PASSWORD" > /app/.env
 #### 3. 使用 ARG 提高构建灵活性
 
 ```docker
+# 推荐使用次版本号标签，允许Docker自动拉取最新的补丁版本
 ARG BASE_IMAGE=python:3.12-slim
 FROM ${BASE_IMAGE}
 
 ## 可以构建不同基础镜像的版本
 
-## docker build --build-arg BASE_IMAGE=python:3.14-alpine .
+## docker build --build-arg BASE_IMAGE=python:3-slim .
 
 ...
 ```

07_dockerfile/7.8_volume.md

@@ -120,6 +120,7 @@ VOLUME /data
 #### 数据库持久化
 
 ```docker
+# 建议使用 postgres:16 或 postgres:latest，具体版本号根据数据库兼容性需求选择
 FROM postgres:16
 VOLUME /var/lib/postgresql/data
 ```
@@ -173,6 +174,7 @@ $ docker inspect mycontainer --format '{{json .Mounts}}' | jq
 ```yaml
 services:
   db:
+    # 建议使用 postgres:16 或其他具体版本，避免 latest
     image: postgres:16
     volumes:
       # 命名卷（推荐）

07_dockerfile/README.md

@@ -72,6 +72,17 @@ docker build [选项] <上下文路径/URL/->
 例如，在 Dockerfile 所在目录执行：
 
 ```bash
-docker build -t my-image:v1 .
+docker build -t my-image:1.0 .
 ```
+
+### 关于版本号最佳实践
+
+本章中的 Dockerfile 示例使用的基础镜像标签遵循以下原则：
+
+- **通用标签**（如 `ubuntu:24.04`、`alpine`、`nginx`）：保持原样，无需修改
+- **基础镜像版本号**（如 `node:20`、`python:3.12`）：使用主或次版本号而非完整版本号（patch），这样可以自动获取最新的补丁版本，确保获得安全更新
+- **避免**：不建议使用 `latest` 标签和完整的 patch 版本号（如 `20.10.0`）作为基础镜像，因为这会导致构建的不可重现性或安全风险
+
+读者在使用这些示例时，应根据实际生产环境需求选择合适的版本号。
+
 更多关于 `docker build` 的用法，我们在实战中会结合具体指令进行演示。

08_data/8.1_volume.md

@@ -171,7 +171,7 @@ $ docker run -d \
     --name postgres \
     -e POSTGRES_PASSWORD=secret \
     -v postgres_data:/var/lib/postgresql/data \
-    postgres:16
+    postgres:16  # 确保与环境兼容的 PostgreSQL 版本
 
 ## 即使删除容器，数据仍然保留
 
@@ -183,7 +183,7 @@ $ docker run -d \
     --name postgres \
     -e POSTGRES_PASSWORD=secret \
     -v postgres_data:/var/lib/postgresql/data \
-    postgres:16
+    postgres:16  # 确保与环境兼容的 PostgreSQL 版本
 ```
 
 #### 场景二：多容器共享数据

09_network/9.7_advanced_networking.md

@@ -53,7 +53,7 @@ docker network inspect my-overlay-net
 docker service create --name web \
   --network my-overlay-net \
   --replicas 3 \
-  nginx:latest
+  nginx  # 确保与环境兼容的 Nginx 版本
 
 # 单机环境下也可以让普通容器加入 attachable overlay 网络
 docker run -d --name container1 --network my-overlay-net busybox sleep 1d
@@ -111,14 +111,14 @@ docker run -d \
   --dns 8.8.8.8 \
   --dns 1.1.1.1 \
   --dns-search example.com \
-  nginx:latest
+  nginx  # 确保与环境兼容的 Nginx 版本
 
 # DNS 选项
 docker run -d \
   --dns-option ndots:2 \
   --dns-option timeout:1 \
   --dns-option attempts:3 \
-  nginx:latest
+  nginx  # 确保与环境兼容的 Nginx 版本
 
 # 查看容器 DNS 配置
 docker exec <container_id> cat /etc/resolv.conf
@@ -171,8 +171,8 @@ networks:
 docker network create mynet
 
 # 运行服务
-docker run -d --name web --network mynet nginx:latest
+docker run -d --name web --network mynet nginx  # 确保与环境兼容的 Nginx 版本
-docker run -d --name db --network mynet postgres:latest
+docker run -d --name db --network mynet postgres  # 确保与环境兼容的 PostgreSQL 版本
 
 # 在其他容器中通过服务名访问
 docker run -it --network mynet busybox sh

10_buildx/10.1_buildkit.md

@@ -2,7 +2,7 @@
 
 **BuildKit** 是下一代的镜像构建组件，在 [moby/buildkit](https://github.com/moby/buildkit) 开源。
 
-> **重要**：自 Docker 23.0 起，BuildKit 已成为 **默认稳定构建器**，无需手动启用。Docker Engine v29 进一步将 Containerd 镜像存储设为默认，提升与 Kubernetes 的互操作性。
+> **重要**：自 Docker 23 起，BuildKit 已成为 **默认稳定构建器**，无需手动启用。Docker Engine 29 进一步将 Containerd 镜像存储设为默认，提升与 Kubernetes 的互操作性。
 
 目前，Docker Hub 自动构建已经支持 BuildKit，具体请参考 [docker-practice/docker-hub-buildx](https://github.com/docker-practice/docker-hub-buildx)。
 
@@ -159,7 +159,7 @@ $ docker build -t test --ssh default=$SSH_AUTH_SOCK .
 
 Docker Compose 同样支持 BuildKit，这使得多服务应用的构建更加高效。
 
-自 Docker 23.0 起，BuildKit 已默认启用，无需额外配置。如果使用旧版本，可设置 `DOCKER_BUILDKIT=1` 环境变量启用。
+自 Docker 23 起，BuildKit 已默认启用，无需额外配置。如果使用旧版本，可设置 `DOCKER_BUILDKIT=1` 环境变量启用。
 
 ### 10.1.3 官方文档
 

10_buildx/10.2_buildx.md

@@ -43,7 +43,7 @@ $ docker buildx build --sbom=true -t myimage .
 >
 > **正确的解决路径有两条**：
 > 1. **推送到远端仓库**：使用 `docker buildx build --sbom=true --push -t myimage:tag` 时，SBOM 会正确保存到远端仓库。远端 OCI 兼容的镜像仓库能够完整存储这些元数据。
-> 2. **启用 containerd image store**：在 Docker 守护进程中启用 `containerd image store` 特性（Docker v29+，新安装场景默认启用，Docker Desktop 上也更容易直接使用），可以在本地查看和管理 SBOM 等 attestation 元数据。
+> 2. **启用 containerd image store**：在 Docker 守护进程中启用 `containerd image store` 特性（Docker 29+，新安装场景默认启用，Docker Desktop 上也更容易直接使用），可以在本地查看和管理 SBOM 等 attestation 元数据。
 
 ### 10.2.2 官方文档
 

10_buildx/10.3_multi-arch-images.md

@@ -44,7 +44,7 @@ $ docker manifest inspect hello-world
 
 `docker buildx` 是构建多架构镜像的最佳实践工具，它屏蔽了底层的复杂性，提供了一键构建多架构镜像的能力。
 
-在 Docker 19.03+ 版本中，`docker buildx` 是推荐的用于构建多架构镜像的工具。它使用 `BuildKit` 作为后端，可以大大简化构建过程。
+在 Docker 19.03+ 版本中，`docker buildx` 是推荐的用于构建多架构镜像的工具。它使用 `BuildKit` 作为后端，可以大大简化构建过程（Docker 23+ 默认启用 BuildKit）。
 
 #### 新建 `builder` 实例
 

10_buildx/README.md

@@ -2,7 +2,7 @@
 
 Docker Buildx 是一个 docker CLI 插件，其扩展了 docker 命令，支持 [Moby BuildKit](10.1_buildkit.md) 提供的功能。提供了与 docker build 相同的用户体验，并增加了许多新功能。
 
-> Buildx 需要 Docker v19.03+。在较新版本中已更常用且功能更完整。
+> Buildx 需要 Docker v19.03+ （Docker 19.03 及以上版本）。在较新版本中已更常用且功能更完整。
 
 ## 本章内容
 
@@ -13,4 +13,4 @@ Docker Buildx 是一个 docker CLI 插件，其扩展了 docker 命令，支持
 * [构建多种系统架构支持的 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 或本地高效校验镜像的安全元数据。
+> 正是基于此诉求，自 Docker Engine 29 起在**新安装场景**默认启用的 `containerd image store` 提供对 Image Index 的完美本地支持能力，解决了传统经典存储后端（Classic Store）无法有效处理带 Attestations 镜像索引的瓶颈。这使得你可以利用 `docker buildx imagetools inspect` 等手段，甚至做到无需拉取完整镜像内容即可在 Registry 或本地高效校验镜像的安全元数据。

10_buildx/summary.md

@@ -4,7 +4,7 @@ Docker Buildx 是 Docker 构建系统的重要进化，提供了高效、安全
 
 | 概念 | 要点 |
 |------|------|
-| **BuildKit** | 下一代构建引擎，Docker 23.0+ 默认启用 |
+| **BuildKit** | 下一代构建引擎，Docker 23+ 默认启用 |
 | **缓存挂载** | `RUN --mount=type=cache` 加速依赖安装 |
 | **Secret 挂载** | `RUN --mount=type=secret` 安全传递密钥 |
 | **buildx build** | 替代 `docker build`，支持更多构建功能 |

11_compose/11.2_install.md

@@ -19,7 +19,7 @@ $ chmod +x $DOCKER_CONFIG/cli-plugins/docker-compose
 
 ```bash
 $ docker compose version
-Docker Compose version vX.Y.Z
+Docker Compose version v5.x
 ```
 
 ### 11.2.3 卸载

11_compose/11.6_django.md

@@ -2,6 +2,11 @@
 
 > 本小节内容适合 `Python` 开发人员阅读。
 
+> **版本说明**：本示例使用以下镜像版本：
+> - Python：3.12-slim（可替换为其他 3.x 版本）
+> - PostgreSQL：16（可替换为其他 16.x、15.x 等版本）
+> - Django：>=5.0,<6.0（可根据项目需求调整）
+
 本节将使用 Docker Compose 配置并运行一个 **Django + PostgreSQL** 应用。笔者不仅会介绍具体步骤，还会解释每个配置项的作用，以及开发环境和生产环境的差异。
 
 ### 11.6.1 架构概览

11_compose/11.7_rails.md

@@ -2,6 +2,11 @@
 
 > 本小节内容适合 Ruby 开发人员阅读。
 
+> **版本说明**：本示例使用以下镜像版本：
+> - Ruby：3.2（可替换为其他 3.x 版本）
+> - PostgreSQL：16（可替换为其他 16.x、15.x 等版本）
+> - Rails：~> 7.1（可根据项目需求调整）
+
 本节使用 Docker Compose 配置并运行一个 **Rails + PostgreSQL** 应用。
 
 ### 11.7.1 架构概览

11_compose/11.8_wordpress.md

@@ -1,5 +1,9 @@
 ## 11.8 实战 WordPress
 
+> **版本说明**：本示例使用以下镜像版本：
+> - MySQL：8.0（可替换为其他 8.x 版本，或使用 MariaDB 替代）
+> - WordPress：latest（建议在生产环境指定具体版本，如 6.x）
+
 WordPress 是全球最流行的内容管理系统 (CMS)。使用 Docker Compose 可以在几分钟内搭建一个包含数据库、Web 服务和持久化存储的生产级 WordPress 环境。
 
 ---

12_implementation/12.1_arch.md

@@ -95,11 +95,11 @@ flowchart TD
 
 ---
 
-### 12.1.4 Docker Engine v29+ 变化
+### 12.1.4 Docker Engine v29.x 变化
 
-从 Docker Engine v29 开始，架构进一步简化和标准化：
+从 Docker Engine v29.x 开始，架构进一步简化和标准化：
 
-- **Containerd 镜像存储 (Image Store)**：在 v29+ 的新安装场景中默认启用。Docker 直接使用 Containerd 的镜像管理能力，不再维护自己的一套 graphdriver。
+- **Containerd 镜像存储 (Image Store)**：在 v29.x 的新安装场景中默认启用。Docker 直接使用 Containerd 的镜像管理能力，不再维护自己的一套 graphdriver。
   - **优势**：多平台镜像支持更好、镜像拉取更快 (lazy pulling)、与 K8s 共享镜像。
 
 ---

12_implementation/12.4_ufs.md

@@ -88,11 +88,11 @@ flowchart LR
 
 ### 12.4.4 Docker 支持的存储驱动
 
-Docker 的存储驱动经历了从早期各式各样的机制（如 aufs, devicemapper），到被广泛使用的现代经典 graph driver (`overlay2`)，再到当下（Engine v29 及以后）**在新安装场景中默认启用的 containerd 镜像存储引擎（containerd image store）** 的演进。
+Docker 的存储驱动经历了从早期各式各样的机制（如 aufs, devicemapper），到被广泛使用的现代经典 graph driver (`overlay2`)，再到当下（Engine v29.x 及以后）**在新安装场景中默认启用的 containerd 镜像存储引擎（containerd image store）** 的演进。
 
 | 存储后端 / 驱动 | 核心特性说明 | 推荐程度 |
 |---------|------|---------|
-| **containerd image store**| (v29+ 新一代默认后端，新装默认) 基于 containerd 的 snapshotters，原生支持 OCI image index、多架构镜像与 Attestations 构建溯源元数据存储。 | ✅**强烈推荐 (现代默认)** |
+| **containerd image store**| (v29.x 新一代默认后端，新装默认) 基于 containerd 的 snapshotters，原生支持 OCI image index、多架构镜像与 Attestations 构建溯源元数据存储。 | ✅**强烈推荐 (现代默认)** |
 | **overlay2**| (经典 Graph Driver) 传统架构下的现代 Linux 默认驱动，性能优秀，但在处理复杂溯源元数据（索引）时受限。 | ✅**推荐 (主要后备)** |
 | **aufs** | 早期默认，兼容性好 | 遗留系统 |
 | **btrfs**/**zfs** | 使用原生稳定文件系统快照能力 | 特定场景 |
@@ -113,7 +113,7 @@ Docker 的存储驱动经历了从早期各式各样的机制（如 aufs, device
 $ docker info | grep "Storage Driver"
 Storage Driver: overlay2
 
-## 在 Engine v29+ 中，可以通过如下输出验证是否开启了 containerd 镜像后端：
+## 在 Engine v29.x 中，可以通过如下输出验证是否开启了 containerd 镜像后端：
 $ docker info | grep "containerd image store"
  containerd image store: true
 ```

14_kubernetes_setup/14.1_kubeadm.md

@@ -271,6 +271,8 @@ $ kubectl get node -o yaml | grep CIDR
     podCIDRs:
 ```
 ```bash
+# 注意：v0.28.2 为编写本文档时的最新版本，请根据需要替换为当前版本
+# 参见 https://github.com/flannel-io/flannel/releases
 $ kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/v0.28.2/Documentation/kube-flannel.yml
 ```
 

14_kubernetes_setup/14.2_kubeadm-docker.md

@@ -2,6 +2,8 @@
 
 `kubeadm` 提供了 `kubeadm init` 以及 `kubeadm join` 这两个命令，作为快速创建 `Kubernetes` 集群的最佳实践。
 
+> **版本说明**：本文档基于 Kubernetes v1.36 编写。Kubernetes 版本更新较快（约每 4 个月一个新版本），本文档中的第三方工具版本（如 cri-dockerd、flannel）仅为示例，请根据实际需求更新至当前版本。更完整的安装和兼容性说明请以 [Kubernetes 官方文档](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/) 为准。
+
 > ⚠️ **强烈提示：Docker 与 Kubernetes 环境的时代分界**
 >
 > 自 Kubernetes v1.24 起，内置的 `dockershim` 组件已被正式移除。这意味着 **Kubernetes 不再将 Docker Engine 作为默认内置的容器运行时**。虽然 Docker 仍然是你本地构建、管理镜像的绝佳工具，但它已不再是 kubelet 的默认运行时选项。
@@ -22,6 +24,8 @@
 
 ```bash
 # 安装 cri-dockerd
+# 注意：v0.3.24 为编写本文档时的最新版本，请根据需要替换为当前版本
+# 参见 https://github.com/Mirantis/cri-dockerd/releases
 
 $ cd /tmp
 $ wget https://github.com/Mirantis/cri-dockerd/releases/download/v0.3.24/cri-dockerd-0.3.24.amd64.tgz
@@ -50,6 +54,8 @@ $ sudo /usr/local/bin/cri-dockerd --version
 
 ```bash
 # 安装 cri-dockerd
+# 注意：v0.3.24 为编写本文档时的最新版本，请根据需要替换为当前版本
+# 参见 https://github.com/Mirantis/cri-dockerd/releases
 
 $ cd /tmp
 $ wget https://github.com/Mirantis/cri-dockerd/releases/download/v0.3.24/cri-dockerd-0.3.24.amd64.tgz
@@ -282,6 +288,8 @@ $ kubectl get node -o yaml | grep CIDR
     podCIDRs:
 ```
 ```bash
+# 注意：v0.28.2 为编写本文档时的最新版本，请根据需要替换为当前版本
+# 参见 https://github.com/flannel-io/flannel/releases
 $ kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/v0.28.2/Documentation/kube-flannel.yml
 ```
 

14_kubernetes_setup/14.4_kind.md

@@ -2,6 +2,8 @@
 
 [Kind](https://kind.sigs.k8s.io/) (Kubernetes in Docker) 是一个使用 Docker 容器作为节点运行本地 Kubernetes 集群的工具。主要用于测试 Kubernetes 本身，也非常适合本地开发和 CI 环境。
 
+> **版本说明**：本文档基于 Kind v0.31.0 编写。Kind 会根据下载时的默认行为自动拉取对应的 Kubernetes 版本。建议定期更新 Kind 到最新版本以获得最新的 Kubernetes 支持。详见 [Kind Releases](https://github.com/kubernetes-sigs/kind/releases)。
+
 ### 14.4.1 为什么选择 Kind
 
 Kind 相比其他本地集群方案 (如 Minikube) 有以下显著优势：
@@ -27,6 +29,8 @@ brew install kind
 
 ```bash
 # Linux AMD64
+# 注意：v0.31.0 为编写本文档时的最新版本，请根据需要替换为当前版本
+# 参见 https://github.com/kubernetes-sigs/kind/releases
 
 curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.31.0/kind-linux-amd64
 chmod +x ./kind

14_kubernetes_setup/14.5_k3s.md

@@ -2,6 +2,8 @@
 
 [K3s](https://k3s.io/) 是一个轻量级的 Kubernetes 发行版，由 Rancher Labs 开发。它专为边缘计算、物联网、CI、ARM 等资源受限的环境设计。K3s 被打包为单个二进制文件，只有不到 100MB，但通过了 CNCF 的一致性测试。
 
+> **版本说明**：K3s 版本与 Kubernetes 版本对应。安装脚本会自动拉取最新稳定版本。如需指定特定版本，可在安装时设置 `INSTALL_K3S_VERSION` 环境变量。详见 [K3s Releases](https://github.com/k3s-io/k3s/releases)。
+
 ### 14.5.1 核心特性
 
 *   **轻量级**：移除过时的、非必须的 Kubernetes 功能 (如传统的云提供商插件)，使用 SQLite 作为默认数据存储 (也支持 Etcd/MySQL/Postgres)。
@@ -33,6 +35,8 @@ NAME          STATUS   ROLES                  AGE   VERSION
 k3s-master    Ready    control-plane,master   1m    v1.36.0+k3s1
 ```
 
+> **版本说明**：输出中的 `v1.36.0+k3s1` 为编写本文档时的版本示例。实际输出版本号取决于你所安装的 K3s 版本。更多信息请参见 [K3s Releases](https://github.com/k3s-io/k3s/releases)。
+
 ### 14.5.3 快速使用
 
 K3s 内置了 `kubectl` 命令 (通过 `k3s kubectl` 调用)，为了方便，通常会建立别名或配置 `KUBECONFIG`。

15_etcd/15.1_intro.md

@@ -1,5 +1,7 @@
 ## 15.1 简介
 
+> **版本说明：** 本章内容基于 etcd 3.5 系列版本编写（当前最新为 v3.5.x）。请访问 [etcd 官方发布页](https://github.com/etcd-io/etcd/releases) 获取最新版本信息。
+
 如图 15-1 所示，etcd 项目使用该标识。
 
 ![etcd 标识](./_images/etcd_logo.png)

15_etcd/15.2_install.md

@@ -13,6 +13,7 @@
 例如，使用 `curl` 工具下载压缩包，并解压。
 
 ```bash
+# 下载 etcd v3.5.29 版本（请访问 https://github.com/etcd-io/etcd/releases 获取最新版本）
 $ curl -L https://github.com/etcd-io/etcd/releases/download/v3.5.29/etcd-v3.5.29-linux-amd64.tar.gz -o etcd-v3.5.29-linux-amd64.tar.gz
 
 ## 国内用户可选择就近的网络加速方式（以可用镜像站为准）
@@ -60,6 +61,8 @@ hello world
 
 镜像名称为 `quay.io/coreos/etcd`，可以通过下面的命令启动 `etcd` 服务监听到 `2379` 和 `2380` 端口。
 
+> **版本说明：** 示例中使用 `v3.5.29` 标签。请访问 [etcd 官方发布页](https://github.com/etcd-io/etcd/releases) 获取最新可用版本标签。
+
 ```bash
 $ docker run \
 -p 2379:2379 \

15_etcd/15.3_cluster.md

@@ -1,5 +1,7 @@
 ## 15.3 集群
 
+> **版本说明：** 本节示例使用 etcd v3.5.29。请访问 [etcd 官方发布页](https://github.com/etcd-io/etcd/releases) 获取最新版本信息。
+
 下面我们使用 [Docker Compose](../11_compose/README.md) 模拟启动一个 3 节点的 `etcd` 集群。
 
 编辑 `compose.yaml` (或 `docker-compose.yml`) 文件

15_etcd/15.4_etcdctl.md

@@ -1,5 +1,7 @@
 ## 15.4 使用 etcdctl
 
+> **版本说明：** 本节示例基于 etcd 3.5 系列版本。请访问 [etcd 官方发布页](https://github.com/etcd-io/etcd/releases) 获取最新版本信息。
+
 `etcdctl` 是一个命令行客户端，它能提供一些简洁的命令，供用户直接跟 `etcd` 服务打交道，而无需基于 `HTTP API` 方式。这在某些情况下将很方便，例如用户对服务进行测试或者手动修改数据库内容。我们也推荐在刚接触 `etcd` 时通过 `etcdctl` 命令来熟悉相关的操作，这些操作跟 `HTTP API` 实际上是对应的。
 
 `etcd` 项目二进制发行包中已经包含了 `etcdctl` 工具，没有的话，可以从 [github.com/etcd-io/etcd/releases](https://github.com/etcd-io/etcd/releases) 下载。

15_etcd/README.md

@@ -1,6 +1,8 @@
 # 第十五章 Etcd 项目
 
-`etcd` 是 `CoreOS` 团队发起的一个管理配置信息和服务发现 (`Service Discovery`) 的项目，在这一章里面，我们将基于 `etcd 3.x` 版本介绍该项目的目标，安装和使用，以及实现的技术。
+`etcd` 是 `CoreOS` 团队发起的一个管理配置信息和服务发现 (`Service Discovery`) 的项目，在这一章里面，我们将基于 `etcd 3.5 系列`版本介绍该项目的目标，安装和使用，以及实现的技术。
+
+> **版本说明：** 本章示例基于 etcd 3.5 系列版本编写。etcd 官方维护最新两个次版本（当前为 3.5 和 3.6）。请访问 [etcd 官方发布页](https://github.com/etcd-io/etcd/releases) 获取最新版本信息。
 
 ## 本章内容
 

16_cloud/16.1_intro.md

@@ -1,5 +1,7 @@
 ## 16.1 简介
 
+> **版本说明**：各云平台的容器服务版本更新频繁。本章示例适用于常见的 Kubernetes API 版本。建议访问各云厂商官方文档（如 [AWS EKS](https://aws.amazon.com/eks/)、[Azure AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/)、[Google GKE](https://cloud.google.com/kubernetes-engine)、[阿里云 ACK](https://www.aliyun.com/product/kubernetes)、[腾讯云 TKE](https://cloud.tencent.com/product/tke)）获取最新信息。
+
 随着容器技术的普及，目前主流的云计算服务商都提供了成熟的容器服务。与容器相关的云计算服务主要分为以下几种类型：
 
 ### 16.1.1 容器编排托管服务

16_cloud/README.md

@@ -1,5 +1,7 @@
 # 第十六章 容器与云计算
 
+> **版本说明**：云平台的 Kubernetes 版本和容器服务功能更新迅速。本章示例使用通用的 API 版本（如 `apps/v1`），建议查阅各云厂商官方文档获取最新的服务版本和配置指南。
+
 Docker 目前已经得到了众多公有云平台的支持，并成为除虚拟机之外的核心云业务。
 
 除了 AWS、Google、Azure 等，国内的各大公有云厂商，基本上都同时支持了虚拟机服务和基于 Kubernetes 的容器云业务。有的还推出了其他服务，例如[容器镜像服务](https://cloud.tencent.com/act/cps/redirect?redirect=11588&cps_key=3a5255852d5db99dcd5da4c72f05df61)让用户在云上享有安全高效的镜像托管、分发等服务。

17_ecosystem/17.1_coreos_intro.md

@@ -1,5 +1,7 @@
 ## 17.1 Fedora CoreOS 简介
 
+> **版本说明**：Fedora CoreOS 定期发布更新。建议访问 [官方下载页面](https://getfedora.org/coreos/download/) 获取最新版本和兼容性信息。
+
 [Fedora CoreOS](https://getfedora.org/coreos/) 是一个自动更新的，最小的，整体的，以容器为中心的操作系统，不仅适用于集群，而且可独立运行，并针对运行 Kubernetes 进行了优化。它旨在结合 CoreOS Container Linux 和 Fedora Atomic Host 的优点，将 Container Linux 中的 [Ignition](https://github.com/coreos/ignition) 与 [rpm-ostree](https://github.com/coreos/rpm-ostree) 和 Project Atomic 中的 SELinux 强化等技术相集成。其目标是提供最佳的容器主机，以安全，大规模地运行容器化的工作负载。
 
 ### 17.1.1 FCOS 特性

17_ecosystem/17.3_podman.md

@@ -1,5 +1,7 @@
 ## 17.3 Podman - 下一代 Linux 容器工具
 
+> **版本说明**：Podman 保持活跃的开发和发布周期。建议访问 [Podman 官方文档](https://podman.io/docs) 和 [GitHub Releases](https://github.com/containers/podman/releases) 获取最新版本。
+
 [Podman](https://github.com/containers/podman) 是一个无守护进程、与 Docker 命令高度兼容的下一代 Linux 容器工具。它由 Red Hat 开发，旨在提供一个更安全的容器运行环境。
 
 ### 17.3.1 Podman vs Docker

17_ecosystem/17.4_buildah.md

@@ -1,5 +1,7 @@
 ## 17.4 Buildah - 容器镜像构建工具
 
+> **版本说明**：Buildah 与 Podman 和 Skopeo 共同维护。建议查阅 [Buildah 官方文档](https://buildah.io/) 和 [GitHub Releases](https://github.com/containers/buildah/releases) 了解最新版本。
+
 本节介绍 Buildah，包括其基础概念、应用场景以及基本指令。
 
 ### 17.4.1 Buildah 简介

17_ecosystem/17.5_skopeo.md

@@ -1,5 +1,7 @@
 ## 17.5 Skopeo - 容器镜像管理工具
 
+> **版本说明**：Skopeo 属于 containers 项目生态。建议访问 [Skopeo 官方仓库](https://github.com/containers/skopeo) 和 [GitHub Releases](https://github.com/containers/skopeo/releases) 获取最新版本信息。
+
 本节介绍 Skopeo，包括其基础概念、应用场景以及基本指令。
 
 ### 17.5.1 Skopeo 简介

17_ecosystem/17.6_containerd.md

@@ -1,5 +1,7 @@
 ## 17.6 containerd - 核心容器运行时
 
+> **版本说明**：containerd 和 nerdctl 保持活跃的发布周期。建议查阅 [containerd 官方文档](https://containerd.io/) 和 [nerdctl GitHub Releases](https://github.com/containerd/nerdctl/releases) 获取最新版本信息。
+
 本节介绍 containerd，它是现代容器技术栈中最为核心的基础组件之一。了解 containerd 有助于更深入地理解 Docker 和 Kubernetes 的底层运行机制。
 
 ### 17.6.1 containerd 简介
@@ -16,6 +18,8 @@
 
 ### 17.6.2 与 Docker 和 Kubernetes 的关系
 
+> **版本说明**：本章节涉及 containerd、Docker 和 Kubernetes 的多个版本。建议查阅官方文档了解最新的兼容性信息。
+
 理解 containerd，首先要理清它与用户日常操作的 Docker 以及 Kubernetes 的关系。
 
 #### Docker 的架构
@@ -36,8 +40,8 @@
 Kubernetes 作为一个容器编排系统，为了屏蔽底层不同容器运行时的实现差异，引入了 CRI（Container Runtime Interface）标准。
 
 - 早期版本中，Kubernetes 默认使用 docker 作为运行时，通过一个名为 `dockershim` 的桥接组件对接 Docker，Docker 再对接 containerd。
-- 随着 containerd 原生支持了 CRI 插件，Kubernetes 开始直接与 containerd 通信，去掉了 `dockershim` 和 `dockerd` 的中间层。这就是为什么从 Kubernetes v1.24 开始”弃用 Docker”引发了广泛关注，实际上 Kubernetes 只是弃用 `dockershim`，底层依然在使用从 Docker 基因中诞生的 containerd。
+- 随着 containerd 原生支持了 CRI 插件，Kubernetes 开始直接与 containerd 通信，去掉了 `dockershim` 和 `dockerd` 的中间层。这就是为什么从 Kubernetes 1.24+ 开始”弃用 Docker”引发了广泛关注，实际上 Kubernetes 只是弃用 `dockershim`，底层依然在使用从 Docker 基因中诞生的 containerd。参见 [Kubernetes 官方文档](https://kubernetes.io/docs/setup/production-environment/container-runtimes/#containerd)。
-- containerd 2.0 移除了已弃用的 CRI v1alpha2 接口，仅保留 CRI v1（Kubernetes 自 v1.26 起仅支持 CRI v1）。如果集群中仍有依赖 CRI v1alpha2 的组件，升级 containerd 2.x 前需先完成迁移。containerd 2.3（2026 年 4 月）是 2.x 系列首个 LTS 版本，支持从 1.7 LTS 直接升级，生产环境推荐使用。
+- containerd 2.0+ 移除了已弃用的 CRI v1alpha2 接口，仅保留 CRI v1（Kubernetes 1.26+ 仅支持 CRI v1）。如果集群中仍有依赖 CRI v1alpha2 的组件，升级 containerd 2.x 前需先完成迁移。containerd 2.3+ 是 2.x 系列首个 LTS 版本，支持从 1.7 LTS 直接升级，生产环境推荐使用。详见 [containerd 发布说明](https://github.com/containerd/containerd/releases)。
 
 ### 17.6.3 为什么直接使用 containerd？
 

17_ecosystem/17.7_secure_runtime.md

@@ -1,5 +1,7 @@
 ## 17.7 安全容器运行时
 
+> **版本说明**：Kata Containers、gVisor 和 Firecracker 均为活跃开发的项目。建议查阅各项目官方文档获取最新版本和兼容性信息：[Kata Containers](https://katacontainers.io/)、[gVisor](https://gvisor.dev/)、[Firecracker](https://firecracker-microvm.github.io/)。
+
 本节介绍容器技术生态中的安全运行时机制，主要探讨在隔离性和安全性上比标准 Linux 容器更进一步的方案，重点介绍 Kata Containers 和 gVisor。
 
 ### 17.7.1 为什么需要安全容器？

17_ecosystem/17.8_wasm.md

@@ -1,5 +1,7 @@
 ## 17.8 WebAssembly 与容器
 
+> **版本说明**：WebAssembly 和相关的 Wasm 运行时（如 WasmEdge、Spin）处于快速演进阶段。建议查阅 [WebAssembly 官方文档](https://webassembly.org/)、[WasmEdge](https://wasmedge.org/) 和 [Spin](https://developer.fermyon.com/spin) 官方文档获取最新信息。
+
 本节介绍 WebAssembly (简写为 Wasm) 以及它为何成为现代容器生态中备受瞩目的前沿技术路线。
 
 ### 17.8.1 什么是 WebAssembly？

17_ecosystem/README.md

@@ -1,5 +1,10 @@
 # 第十七章 容器其它生态
 
+> **版本说明**：本章介绍的工具和运行时（Podman、Buildah、Skopeo、containerd、Kata Containers、gVisor、WasmEdge 等）都保持活跃的开发。建议：
+> - 查阅各项目官方文档获取最新版本
+> - 在生产环境使用前验证版本兼容性
+> - 关注官方发布说明了解重大变更
+
 本章将介绍 Docker 和 Kubernetes 之外的容器生态技术。
 
 ## 本章内容

18_security/18.3_daemon_sec.md

@@ -103,7 +103,7 @@ $ docker version
 此后，Docker 守护进程会在执行任何 API 请求前，将请求转发给授权插件进行审批。
 
 > [!CAUTION]
-> 重要的安全事项：在配置 Authorization Plugin 时，务必确保插件本身的可靠性和及时更新。2026 年 4 月披露的 CVE-2026-34040 表明，不完整的 AuthZ 验证可能导致攻击者绕过授权检查并获得宿主机访问权限。建议：
+> 重要的安全事项：在配置 Authorization Plugin 时，务必确保插件本身的可靠性和及时更新。历史上已发现多个 AuthZ 验证绕过漏洞，可能导致攻击者绕过授权检查并获得宿主机访问权限。建议：
 > - 定期审计授权插件的日志，检查是否有可疑的请求被错误允许。
 > - 使用来自可信来源的授权插件，并保持其版本最新。
 > - 将授权检查结果与其他安全措施（如 TLS 认证、Rootless 模式）结合使用，构建纵深防御。

19_observability/19.1_prometheus.md

@@ -51,7 +51,11 @@ rule_files:
 
 #### 2. 编写 Docker Compose 文件
 
-创建 `compose.yaml` (或 `docker-compose.yml`)。下面示例使用的是 2026 年 4 月的稳定版本。对于生产环境部署，建议查阅 [Prometheus 官方文档](https://prometheus.io/docs/prometheus/latest/installation/) 确认最新推荐版本：
+创建 `compose.yaml` (或 `docker-compose.yml`)。下面示例使用的是相对较新的稳定版本。**镜像版本提示**：本示例中 Prometheus、Grafana、node-exporter、cAdvisor 的版本号仅为参考。生产环境部署前，请查阅以下官方资源确认最新推荐版本：
+- [Prometheus 官方文档](https://prometheus.io/docs/prometheus/latest/installation/)
+- [Grafana 官方发布](https://grafana.com/grafana/download)
+- [node-exporter 发布页](https://github.com/prometheus/node_exporter/releases)
+- [cAdvisor 发布页](https://github.com/google/cadvisor/releases)
 
 ```yaml
 services:
@@ -71,7 +75,7 @@ services:
       - monitoring
 
   grafana:
-    image: grafana/grafana:11.3.0
+    image: grafana/grafana:13.0.1
     ports:
       - "3000:3000"
     environment:

19_observability/19.2_elk.md

@@ -17,7 +17,7 @@ ELK (Elasticsearch，Logstash，Kibana) 是目前业界最流行的开源日志
 
 #### 1. 编写 Compose 文件
 
-1. 编写 `compose.yaml` (或 `docker-compose.yml`) 配置如下（示例基于 Elasticsearch 9.x，请查阅 [Elastic 官方文档](https://www.elastic.co/docs/) 确认最新版本与配置兼容性）：
+1. 编写 `compose.yaml` (或 `docker-compose.yml`) 配置如下。**版本提示**：本示例使用 Elasticsearch 9.x、Kibana 9.x、Fluentd 等组件的特定版本号，仅作为参考。生产环境部署前，请查阅 [Elastic 官方文档](https://www.elastic.co/docs/) 和 [Fluentd 官方文档](https://docs.fluentd.org/) 确认最新版本与配置兼容性。
 
 ```yaml
 services:

19_observability/19.3_performance_optimization.md

@@ -163,6 +163,9 @@ scrape_configs:
 
 **完整监控栈部署：**
 
+> [!TIP]
+> 以下示例中的镜像标签（如 `prom/prometheus:v3.11.0`、`prom/node-exporter:v1.11.1`、`ghcr.io/google/cadvisor:v0.56.2`、`grafana/grafana:13.0.1`）仅为参考。在生产环境部署前，请访问各项目的官方发布页或文档获取最新版本号。
+
 ```yaml
 services:
   prometheus:
@@ -211,7 +214,7 @@ services:
       - monitoring
 
   grafana:
-    image: grafana/grafana:11.3.0
+    image: grafana/grafana:13.0.1
     container_name: grafana
     ports:
       - "3000:3000"