Refresh Docker ecosystem

02_basic_concept/2.1_image.md

@@ -172,7 +172,7 @@ registry.example.com/myproject/myapp:v1.2.3
 
 ## 简写（使用 Docker Hub）
 
-nginx:1.30
+nginx:1.28
 ubuntu:24.04
 
 ## 省略标签（默认使用 latest）

02_basic_concept/2.3_repository.md

@@ -1,6 +1,6 @@
 ## 2.3 仓库
 
-> **版本说明**：本节示例基于 Docker v29.x 和常见镜像版本编写。示例中的版本号（如 `nginx:1.30`、`mysql:8.4`、`mysql:5.7` 等）为演示用途。实际使用时请访问 [Docker Hub 官方页面](https://hub.docker.com) 或相应镜像的发布页确认最新可用版本和标签。
+> **版本说明**：本节示例基于 Docker v29.x 和常见镜像版本编写。示例中的版本号（如 `nginx:1.28`、`mysql:8.4`、`mysql:5.7` 等）为演示用途。实际使用时请访问 [Docker Hub 官方页面](https://hub.docker.com) 或相应镜像的发布页确认最新可用版本和标签。
 
 Docker Registry 是镜像分发和管理的核心组件。本节将介绍 Registry 的基本概念、公共和私有服务的选择，以及镜像的安全管理。
 
@@ -25,8 +25,8 @@ flowchart TB
         subgraph RepoNginx ["Repository（仓库）: nginx"]
             direction LR
             N1(":latest (tag)")
-            N2(":1.25 (tag)")
-            N3(":1.24 (tag)")
+            N2(":1.28 (tag)")
+            N3(":1.26 (tag)")
             N4(":alpine (tag)")
             N5("...")
             N1 ~~~ N2 ~~~ N3 ~~~ N4 ~~~ N5
@@ -50,7 +50,7 @@ flowchart TB
 |------|------|------|
 | **Registry** | 存储镜像的服务 | Docker Hub、ghcr.io |
 | **Repository (仓库)** | 同一软件的镜像集合 | `nginx`、`mysql`、`mycompany/myapp` |
-| **Tag (标签)** | 仓库内的版本标识 | `latest`、`1.25`、`alpine` |
+| **Tag (标签)** | 仓库内的版本标识 | `latest`、`1.28`、`alpine` |
 
 #### 镜像的完整名称
 
@@ -73,7 +73,7 @@ registry.example.com/mycompany/myapp:v1.2.3
 
 ## Docker Hub 官方镜像（省略 registry 和用户名）
 
-nginx:1.30
+nginx:1.28
 ubuntu:24.04
 
 ## Docker Hub 用户镜像
@@ -131,7 +131,7 @@ Google 的 Container Registry 已废弃并完成下线，当前应优先使用 A
 
 由于网络原因，在国内直接访问 Docker Hub 可能会很慢。可以配置 **镜像加速器** (Registry Mirror) 来加速下载。配置示例如下：
 
-```json
+```jsonc
 // /etc/docker/daemon.json
 {
   "registry-mirrors": [
@@ -217,7 +217,7 @@ $ docker login registry.example.com # 登录其他 Registry
 
 ## 拉取镜像
 
-$ docker pull nginx:1.30
+$ docker pull nginx:1.28
 
 ## 标记镜像（准备推送）
 
@@ -261,9 +261,9 @@ someuser/myapp # ⚠️ 需要评估
 
 ```bash
 ## 准备一个你有写权限的镜像地址
-$ export IMAGE=<你的仓库名>/nginx:1.30
-$ docker pull nginx:1.30
-$ docker tag nginx:1.30 $IMAGE
+$ export IMAGE=<你的仓库名>/nginx:1.28
+$ docker pull nginx:1.28
+$ docker tag nginx:1.28 $IMAGE
 $ docker push $IMAGE
 
 ## 生成签名密钥（会生成 cosign.key / cosign.pub）

03_install/3.3_fedora.md

@@ -39,7 +39,7 @@ $ sudo dnf remove docker \
 
 ### 3.3.2 使用 dnf 安装
 
-使用 dnf 包管理器安装是推荐的方式，便于后续的更行和管理。
+使用 dnf 包管理器安装是推荐的方式，便于后续的更新和管理。
 
 执行以下命令安装依赖包：
 

04_image/4.1_pull.md

@@ -4,7 +4,7 @@
 
 > **版本号最佳实践**
 >
-> - **永远指定版本号**：避免使用 `latest` 标签，应指定具体的版本（如 `ubuntu:24.04`、`nginx:1.30`），以确保镜像内容稳定一致。
+> - **永远指定版本号**：避免使用 `latest` 标签，应指定具体的版本（如 `ubuntu:24.04`、`nginx:1.28`），以确保镜像内容稳定一致。
 > - **在生产环境使用摘要**：优先使用镜像摘要（SHA256）而非标签，如 `nginx@sha256:abc123...`，因为摘要不可变。
 > - **定期评估依赖**：即使指定了版本号，仍应定期检查依赖的基础镜像是否有安全更新。
 
@@ -160,7 +160,7 @@ root@e7009c6ce357:/# exit
 
 从 Docker Hub 下载可能较慢。可以配置镜像加速器：
 
-```json
+```jsonc
 // /etc/docker/daemon.json (Linux)
 // ~/.docker/daemon.json (Docker Desktop)
 {

04_image/4.4_commit.md

@@ -10,7 +10,7 @@
 
 现在让我们以定制一个 Web 服务器为例子，来讲解镜像是如何构建的。
 
-> **版本提示**：以下示例中 `nginx` 镜像使用默认 `latest` 标签。生产环境建议指定具体版本号（如 `nginx:1.30`），以避免镜像更新带来的不兼容性。
+> **版本提示**：以下示例中 `nginx` 镜像使用默认 `latest` 标签。生产环境建议指定具体版本号（如 `nginx:1.28`），以避免镜像更新带来的不兼容性。
 
 ```bash
 $ docker run --name webserver -d -p 8080:80 nginx
@@ -93,7 +93,7 @@ nginx               1.30                05a60462f8ba        12 days ago
 nginx               latest              e43d811ce2f4        4 weeks ago         181.5 MB
 ```
 
-> **版本说明**：上面示例中 `nginx:1.30` 代表 1.30 系列的最新 patch 版本。在���际应用中应根据需求选择确切的版本号，而不是盲目使用 `latest`。
+> **版本说明**：上面示例中 `nginx:1.30` 代表 1.30 系列的最新 patch 版本。在实际应用中应根据需求选择确切的版本号，而不是盲目使用 `latest`。
 
 我们还可以用 `docker history` 具体查看镜像内的历史记录。例如先执行 `docker history nginx:v2`，再对比 `docker history nginx:latest`，就能看到我们刚刚提交出来的新层。
 

04_image/4.5_build.md

@@ -26,7 +26,7 @@ $ touch Dockerfile
 ```
 其内容为：
 
-> **版本提示**：下面示例中 `FROM nginx` 使用的是 `latest` 标签。在实际应用中应使用明确的版本号（如 `FROM nginx:1.30`），以确保 Dockerfile 的可重现性和稳定性。
+> **版本提示**：下面示例中 `FROM nginx` 使用的是 `latest` 标签。在实际应用中应使用明确的版本号（如 `FROM nginx:1.28`），以确保 Dockerfile 的可重现性和稳定性。
 
 ```docker
 FROM nginx

05_container/5.4_attach_exec.md

@@ -249,10 +249,11 @@ $ docker exec myapp python manage.py migrate
 $ docker exec -it myapp bash
 OCI runtime exec failed: exec failed: unable to start container process: exec: "bash": executable file not found
 
-## 解决方案：使用调试容器
+## 解决方案：使用调试容器（需要 Docker Desktop Pro/Team/Business 订阅）
 
 $ docker debug myapp
 ```
+> **注意**：`docker debug` 是 Docker Desktop 4.33+ 提供的功能，需要 Pro、Team 或 Business 订阅。它会附加一个包含常用调试工具（vim、curl、htop 等）的工具箱到目标容器，即使目标镜像基于 `scratch` 也能使用。
 ---
 
 ### 5.4.7 常见问题

05_container/README.md

@@ -14,7 +14,7 @@
 - **镜像标签约定**：
   - `latest` 或 `v1.0.0` 等：带标签的自定义镜像，示例中指定具体版本
   - `24.04`、`8.4`：官方镜像的稳定版本分支
-  - 生产环境建议：指定���确版本号（如 `nginx:1.30.0`、`mysql:8.4.4`）而非仅大版本号
+  - 生产环境建议：指定确切版本号（如 `nginx:1.28.0`、`mysql:8.4.4`）而非仅大版本号
 
 * [启动容器](5.1_run.md)
 * [守护态运行](5.2_daemon.md)

06_repository/6.1_dockerhub.md

@@ -75,7 +75,7 @@ Docker Hub 对不同类型用户实施拉取速率限制（基于 6 小时周期
 | **免费账户** (已登录) | 每 6 小时 200 次请求 |
 | **Pro/Team/Business 账户** | 无限制（公平使用政策） |
 
-> **注意**：自 2025 年 4 月起，所有付费订阅用户享有无限制拉取额度。匿名用户和免费账户的限制保持不变，建议在 CI/CD 环境中始终配置 `docker login` 以获得更高的拉取额度。
+> **注意**：Docker 曾计划于 2025 年 4 月调整拉取限制策略，但在 2025 年 2 月宣布取消该计划。目前付费订阅用户享有无限制拉取额度，匿名用户和免费账户的限制保持不变。建议在 CI/CD 环境中始终配置 `docker login` 以获得更高的拉取额度。
 
 #### 滥用限流
 

06_repository/6.3_registry_auth.md

@@ -126,6 +126,8 @@ $ docker run --rm \
     -Bbn username password > auth/nginx.htpasswd
 ```
 > 将上面的 `username` `password` 替换为你自己的用户名和密码。
+>
+> **安全提示**：上述命令会将密码明文暴露在 shell 历史记录和进程列表中。生产环境建议使用交互式方式输入密码（不带 `-b` 参数），或通过环境变量/文件传入。
 
 > **版本说明**：使用 `httpd:2.4-alpine` 基于 Apache 2.4 的精简镜像。如需其他版本，可替换为 `httpd:latest` 或指定具体版本号如 `httpd:2.4.58-alpine`。
 

07_dockerfile/7.12_healthcheck.md

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

07_dockerfile/7.17_multistage_builds.md

@@ -33,7 +33,7 @@ WORKDIR /go/src/github.com/go/helloworld/
 COPY app.go .
 
 RUN go mod init helloworld \
-  && go get -d -v github.com/go-sql-driver/mysql \
+  && go get github.com/go-sql-driver/mysql \
   && CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app . \
   && cp /go/src/github.com/go/helloworld/app /root
 
@@ -62,7 +62,8 @@ WORKDIR /go/src/github.com/go/helloworld
 
 COPY app.go .
 
-RUN go get -d -v github.com/go-sql-driver/mysql \
+RUN go mod init helloworld \
+  && go get github.com/go-sql-driver/mysql \
   && CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app .
 ```
 编写 `Dockerfile.copy` 文件
@@ -125,7 +126,8 @@ RUN apk --no-cache add git
 
 WORKDIR /go/src/github.com/go/helloworld/
 
-RUN go get -d -v github.com/go-sql-driver/mysql
+RUN go mod init helloworld \
+  && go get github.com/go-sql-driver/mysql
 
 COPY app.go .
 
@@ -158,6 +160,15 @@ go/helloworld     1     f55d3e16affc     2 minutes ago      295MB
 ```
 很明显使用多阶段构建的镜像体积小，同时也完美解决了上边提到的问题。
 
+> **Go Modules 最佳实践**：上述示例为简化演示在 Dockerfile 中临时执行 `go mod init`。在实际项目中，通常已在代码仓库中维护好 `go.mod` 和 `go.sum` 文件。推荐的 Dockerfile 写法是先拷贝这两个文件并执行 `go mod download` 以利用 Docker 层缓存，再拷贝源码并构建：
+>
+> ```docker
+> COPY go.mod go.sum ./
+> RUN go mod download
+> COPY . .
+> RUN go build -o app .
+> ```
+
 ### 7.17.4 只构建某一阶段的镜像
 
 我们可以使用 `as` 来为某一阶段命名，例如
@@ -176,5 +187,5 @@ $ docker build --target builder -t username/imagename:tag .
 上面例子中我们使用 `COPY --from=0 /go/src/github.com/go/helloworld/app .` 从上一阶段的镜像中复制文件，我们也可以复制任意镜像中的文件。
 
 ```docker
-COPY --from=nginx:1.30-alpine /etc/nginx/nginx.conf /nginx.conf
+COPY --from=nginx:1.28-alpine /etc/nginx/nginx.conf /nginx.conf
 ```

07_dockerfile/7.18_multistage_builds_laravel.md

@@ -128,8 +128,8 @@ RUN set -x ; cd ${LARAVEL_PATH} \
 ### 7.18.5 最后一个阶段构建 NGINX 镜像
 
 ```docker
-# 注：nginx 镜像推荐使用具体的版本标签（如 nginx:1.30-alpine）
-FROM nginx:1.30-alpine as nginx
+# 注：nginx 镜像推荐使用具体的版本标签（如 nginx:1.28-alpine）
+FROM nginx:1.28-alpine as nginx
 
 ARG LARAVEL_PATH=/app/laravel
 
@@ -179,7 +179,7 @@ $ docker run -dit --rm --network=laravel -p 8080:80 my/nginx
 完整的 `Dockerfile` 文件如下。
 
 ```docker
-# 注：生产环境推荐使用具体的版本标签，如 node:22-alpine、composer:2.x、php:8.3-fpm-alpine、nginx:1.30-alpine
+# 注：生产环境推荐使用具体的版本标签，如 node:22-alpine、composer:2.x、php:8.3-fpm-alpine、nginx:1.28-alpine
 FROM node:22-alpine as frontend
 
 COPY package.json /app/
@@ -229,7 +229,7 @@ RUN set -x ; cd ${LARAVEL_PATH} \
       && chmod -R 777 storage \
       && php artisan package:discover
 
-FROM nginx:1.30-alpine as nginx
+FROM nginx:1.28-alpine as nginx
 
 ARG LARAVEL_PATH=/app/laravel
 

08_data/8.2_bind-mounts.md

@@ -238,7 +238,7 @@ $ docker run -u $(id -u):$(id -g) ...
 在 Docker Desktop 上，Bind Mount 性能通常不如 Volume，因为数据需要在宿主机文件系统和 Linux VM 之间同步：
 
 ```bash
-## 使用 :cached 或 :delegated 提高性能（macOS）
+## 使用 :cached 或 :delegated 提高性能（macOS，仅 Docker Desktop 4.5 及更早版本）
 
 $ docker run -v /host/path:/container/path:cached myapp
 ```
@@ -248,6 +248,8 @@ $ docker run -v /host/path:/container/path:cached myapp
 | `:delegated` | 容器权威，宿主机读取可能延迟 |
 | `:consistent` | 默认，完全一致 (最慢)|
 
+> **注意**：Docker Desktop 4.6+ 默认使用 VirtioFS 文件共享引擎，上述 `:cached`/`:delegated` 选项已被静默忽略。如需优化文件同步性能，请参考 Docker Desktop 的 [Synchronized file shares](https://docs.docker.com/desktop/synchronized-file-sharing/) 功能。
+
 ---
 
 ### 8.2.9 最佳实践

11_compose/11.4_commands.md

@@ -46,7 +46,7 @@ docker compose [-f=<arg>...] [options] [COMMAND] [ARGS...]
 
 * `-p, --project-name NAME` 指定项目名称，默认将使用所在目录名称作为项目名。
 
-* `--verbose` 输出更多调试信息。
+* `--verbose` 输出更多调试信息。(**已弃用**：在 Docker Compose V2 中，请改用 `docker --log-level debug compose ...` 或设置环境变量 `COMPOSE_DEBUG=1`。)
 
 * `-v, --version` 打印版本并退出。
 

12_implementation/12.3_cgroups.md

@@ -198,7 +198,7 @@ $ docker run --rm --cpus=1 stress --cpu 4
 
 #### Docker 对 cgroups v2 的支持
 
-Docker 19.03+ 默认优先使用 cgroups v2（如果系统支持），提供更好的性能和资源隔离。如果需要明确控制或回退到 v1，可以通过 Docker 守护进程配置文件 `/etc/docker/daemon.json` 修改 `cgroup-driver` 参数：
+Docker 20.10+ 开始支持 cgroups v2（如果系统支持），提供更好的性能和资源隔离。如果需要明确控制或回退到 v1，可以通过 Docker 守护进程配置文件 `/etc/docker/daemon.json` 修改 `cgroup-driver` 参数：
 
 ```json
 {

13_kubernetes_concepts/13.2_concepts.md

@@ -166,7 +166,7 @@ spec:
     spec:
       containers:
         - name: nginx
-          image: nginx:1.30
+          image: nginx:1.28
           ports:
             - containerPort: 80
 ```

13_kubernetes_concepts/13.5_practice.md

@@ -31,7 +31,7 @@ spec:
     spec:
       containers:
       - name: nginx
-        image: nginx:1.30
+        image: nginx:1.28
         ports:
         - containerPort: 80
 ```
@@ -73,7 +73,7 @@ kubectl get svc nginx-service
 
 ### 13.5.4 步骤 3：模拟滚动更新
 
-修改 `nginx-deployment.yaml`，将镜像版本改为 `nginx:1.30-alpine`。
+修改 `nginx-deployment.yaml`，将镜像版本改为 `nginx:1.28-alpine`。
 
 ```bash
 kubectl apply -f nginx-deployment.yaml

14_kubernetes_setup/14.1_kubeadm.md

@@ -140,7 +140,7 @@ $ sysctl --system
 
 #### 修改 `kubelet.service`（可选：IPVS 模式）
 
-> **注意**：kube-proxy 的 IPVS 模式已在 Kubernetes 1.35 中被标记为弃用，并计划在后续版本中移除。新部署建议使用默认的 iptables 模式或 nftables 模式（Kubernetes 1.31+ 可用）。以下 IPVS 配置仅供需要兼容旧环境的场景参考。
+> **注意**：kube-proxy 的 IPVS 模式已在 Kubernetes 1.35 中被标记为弃用，并在 **Kubernetes 1.36 中正式移除**。新部署应使用默认的 iptables 模式或 nftables 模式（Kubernetes 1.31+ 可用）。以下 IPVS 配置仅供 1.35 及更早版本的旧环境参考。
 
 `/etc/systemd/system/kubelet.service.d/10-proxy-ipvs.conf` 写入以下内容
 

14_kubernetes_setup/14.2_kubeadm-docker.md

@@ -171,7 +171,7 @@ $ sysctl --system
 
 #### 修改 `kubelet.service`（可选：IPVS 模式）
 
-> **注意**：kube-proxy 的 IPVS 模式已在 Kubernetes 1.35 中被标记为弃用，并计划在后续版本中移除。新部署建议使用默认的 iptables 模式或 nftables 模式（Kubernetes 1.31+ 可用）。以下 IPVS 配置仅供需要兼容旧环境的场景参考。
+> **注意**：kube-proxy 的 IPVS 模式已在 Kubernetes 1.35 中被标记为弃用，并在 **Kubernetes 1.36 中正式移除**。新部署应使用默认的 iptables 模式或 nftables 模式（Kubernetes 1.31+ 可用）。以下 IPVS 配置仅供 1.35 及更早版本的旧环境参考。
 
 `/etc/systemd/system/kubelet.service.d/10-proxy-ipvs.conf` 写入以下内容
 
@@ -242,7 +242,8 @@ kubeadm join 192.168.199.100:6443 --token cz81zt.orsy9gm9v649e5lf \
 
 ```bash
 $ kubeadm join 192.168.199.100:6443 --token cz81zt.orsy9gm9v649e5lf \
-    --discovery-token-ca-cert-hash sha256:5edb316fd0d8ea2792cba15cdf1c899a366f147aa03cba52d4e5c5884ad836fe
+    --discovery-token-ca-cert-hash sha256:5edb316fd0d8ea2792cba15cdf1c899a366f147aa03cba52d4e5c5884ad836fe \
+    --cri-socket unix:///var/run/cri-dockerd.sock
 ```
 
 ### 14.2.7 查看服务

14_kubernetes_setup/14.8_kubectl.md

@@ -240,8 +240,10 @@ $ kubectl config set-context --current --namespace=my-namespace
 # 显示集群信息
 $ kubectl cluster-info
 
-# 显示完整的集群状态（包括所有组件）
+# 显示完整的集群状态（注：componentstatuses 自 1.19 起已弃用，建议使用下方替代命令）
 $ kubectl get componentstatuses
+# 推荐替代：
+$ kubectl get --raw='/readyz?verbose'
 ```
 
 ### 14.8.15 version

17_ecosystem/README.md

@@ -1,12 +1,19 @@
 # 第十七章 容器其它生态
 
-> **版本说明**：本章介绍的工具和运行时（Podman、Buildah、Skopeo、containerd、Kata Containers、gVisor、WasmEdge 等）都保持活跃的开发。建议：
+> **版本说明（核验日期：2026-05-16）**：本章介绍的工具和运行时（Podman、Buildah、Skopeo、containerd、Kata Containers、gVisor、WasmEdge 等）都保持活跃的开发。建议：
 > - 查阅各项目官方文档获取最新版本
 > - 在生产环境使用前验证版本兼容性
 > - 关注官方发布说明了解重大变更
 
 本章将介绍 Docker 和 Kubernetes 之外的容器生态技术。
 
+同时，Docker 自身的生态也在向云构建、AI 本地推理和企业级桌面安全扩展。当前需要额外关注：
+
+* **Docker Model Runner**：在 Docker Desktop / Docker Engine 中管理、运行和服务本地 AI 模型，支持 OpenAI 与 Ollama 兼容 API，并可将 GGUF、Safetensors 等模型文件作为 OCI Artifact 管理。
+* **Docker Build Cloud**：通过远程 BuildKit 和共享构建缓存加速本地与 CI 构建，适合多平台镜像和团队共享缓存场景。
+* **Docker Offload**：把容器构建和运行卸载到云端，适合 VDI、受限本机或不支持嵌套虚拟化的开发环境。
+* **Hardened Docker Desktop / Enhanced Container Isolation (ECI)**：通过更强的命名空间隔离、敏感挂载保护和系统调用限制降低桌面容器逃逸风险。
+
 ## 本章内容
 
 * [Fedora CoreOS 简介](17.1_coreos_intro.md)

19_observability/19.2_elk.md

@@ -22,7 +22,7 @@ ELK (Elasticsearch，Logstash，Kibana) 是目前业界最流行的开源日志
 ```yaml
 services:
   elasticsearch:
-    image: docker.elastic.co/elasticsearch/elasticsearch:9.3.3
+    image: docker.elastic.co/elasticsearch/elasticsearch:9.4.0
     container_name: elasticsearch
     environment:
       - "discovery.type=single-node"
@@ -36,7 +36,7 @@ services:
       - logging
 
   kibana:
-    image: docker.elastic.co/kibana/kibana:9.3.3
+    image: docker.elastic.co/kibana/kibana:9.4.0
     container_name: kibana
     environment:
       - ELASTICSEARCH_HOSTS=http://elasticsearch:9200

21_case_devops/21.7_practical_examples.md

@@ -543,7 +543,7 @@ logfile ""
 
 # 客户端输出缓冲限制
 client-output-buffer-limit normal 0 0 0
-client-output-buffer-limit slave 256mb 64mb 60
+client-output-buffer-limit replica 256mb 64mb 60
 client-output-buffer-limit pubsub 32mb 8mb 60
 ```
 

appendix/best_practices.md

@@ -14,7 +14,7 @@
 
 #### 使用多阶段构建
 
-在 Docker 17.05 以上版本中，你可以使用[多阶段构建](../07_dockerfile/7.17_multistage_builds.md)来减少所构建镜像的大小。
+在现代 Docker 版本中，你可以使用[多阶段构建](../07_dockerfile/7.17_multistage_builds.md)来减少所构建镜像的大小。该能力最早在 Docker 17.05 引入，如今已是编写生产镜像的默认实践之一；新项目还应结合 BuildKit 缓存挂载、secret 挂载和多平台构建能力一起评估。
 
 #### 避免安装不必要的包
 

appendix/debug.md

@@ -14,7 +14,7 @@
 ```bash
 $ sudo kill -SIGHUP $(pidof dockerd)
 ```
-此时 dockerd 会在日志中输入更多信息供分析。
+此时 dockerd 会在日志中输出更多信息供分析。
 
 ### 检查内核日志
 

appendix/learning_roadmap.md

@@ -421,7 +421,7 @@ Kubernetes 进阶 (Week 24-36)
 - [Docker 官方博客](https://www.docker.com/blog/)
 - [Kubernetes 官方博客](https://kubernetes.io/blog/)
 - [CNCF 博客](https://www.cncf.io/blog/)
-- [DZone](https://dzone.com/containers-cloud)
+- [DZone Cloud Architecture](https://dzone.com/cloud-architecture)
 
 ### 认证指南
 
@@ -478,7 +478,7 @@ Kubernetes 进阶 (Week 24-36)
 # 1. 学习本书第 1-11 章（基础到中级）
 # 2. 完成 20+ 个实战项目
 # 3. 参考官方学习指南
-curl https://docker.training.kodekloud.com/dca-guide
+# 参考 KodeKloud DCA 认证指南：https://kodekloud.com/blog/docker-certified-associate-guide/
 
 # 4. 模拟考试
 - Linux Academy DCA 练习题

appendix/repo/centos.md

@@ -9,7 +9,7 @@
 > 2026 年了，对于任何新项目，**强烈建议** 使用以下生产级替代方案：
 > - [Rocky Linux](https://hub.docker.com/_/rockylinux)：CentOS 原创始人发起的社区驱动项目，目前主流为 Rocky Linux 9。
 > - [AlmaLinux](https://hub.docker.com/_/almalinux)：由 CloudLinux 支持的企业级发行版，提供长期支持。
-> - [CentOS Stream](https://hub.docker.com/r/centos/centos)：RHEL 的上游开发分支 (适合开发测试，不建议用于生产环境)。
+> - [CentOS Stream](https://quay.io/repository/centos/centos)：RHEL 的上游开发分支，镜像已迁移至 Quay.io (适合开发测试，不建议用于生产环境)。
 
 该仓库位于 [Docker Hub 的 CentOS 官方镜像页](https://hub.docker.com/_/centos)，提供了 CentOS 从 5 ~ 8 各个版本的镜像（仅作为历史归档，不再更新）。