diff --git a/04_image/4.6_other.md b/04_image/4.6_other.md index a1baa0e..01f3034 100644 --- a/04_image/4.6_other.md +++ b/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 diff --git a/04_image/4.7_internal.md b/04_image/4.7_internal.md index 4b6494b..7932870 100644 --- a/04_image/4.7_internal.md +++ b/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)** 章节。 diff --git a/05_container/5.1_run.md b/05_container/5.1_run.md index 49fe108..717e11b 100644 --- a/05_container/5.1_run.md +++ b/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` | -| `-it` | 交互式终端 | `docker run -it ubuntu bash` | -| `--name` | 指定容器名称 | `docker run --name myapp nginx` | -| `--rm` | 退出后自动删除容器 | `docker run --rm ubuntu echo hi` | +| `-d` | 后台运行 (detach)| `docker run -d nginx:latest` | +| `-it` | 交互式终端 | `docker run -it ubuntu:24.04 bash` | +| `--name` | 指定容器名称 | `docker run --name myapp nginx:latest` | +| `--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:容器内修改的文件丢失 diff --git a/05_container/5.2_daemon.md b/05_container/5.2_daemon.md index 4a8db71..b1cb005 100644 --- a/05_container/5.2_daemon.md +++ b/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 # 进入容器手动执行命令,查找问题 ``` diff --git a/05_container/5.3_stop.md b/05_container/5.3_stop.md index c629246..3828006 100644 --- a/05_container/5.3_stop.md +++ b/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 diff --git a/05_container/5.5_import_export.md b/05_container/5.5_import_export.md index 77dfe3a..6b29e1c 100644 --- a/05_container/5.5_import_export.md +++ b/05_container/5.5_import_export.md @@ -13,6 +13,8 @@ $ docker export 7691a814370e > ubuntu.tar ``` 这样将导出容器快照到本地文件。 +> **版本说明**:导出的容器快照不包含镜像版本历史,导入时可以自定义标签和版本号。 + ### 5.5.2 导入容器快照 可以使用 `docker import` 从容器快照文件中再导入为镜像,例如 diff --git a/05_container/README.md b/05_container/README.md index 343ea0b..96b6451 100644 --- a/05_container/README.md +++ b/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) diff --git a/06_repository/6.2_registry.md b/06_repository/6.2_registry.md index f9f6b8e..2ae5459 100644 --- a/06_repository/6.2_registry.md +++ b/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 在私有仓库上传、搜索、下载镜像 diff --git a/06_repository/6.3_registry_auth.md b/06_repository/6.3_registry_auth.md index 5f2b0f0..b33adb9 100644 --- a/06_repository/6.3_registry_auth.md +++ b/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 diff --git a/06_repository/6.4_nexus3_registry.md b/06_repository/6.4_nexus3_registry.md index 9406152..08cd202 100644 --- a/06_repository/6.4_nexus3_registry.md +++ b/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` 了。 首次运行请通过以下命令获取初始密码: diff --git a/06_repository/README.md b/06_repository/README.md index 421b25c..6370a88 100644 --- a/06_repository/README.md +++ b/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` 标签,因为其含义存在歧义且易导致版本混淆 + ## 为什么需要私有仓库? 在讨论具体的安装和配置前,让我们先理解:**什么时候你应该建设私有仓库?** diff --git a/07_dockerfile/7.10_workdir.md b/07_dockerfile/7.10_workdir.md index b2956a2..42e1297 100644 --- a/07_dockerfile/7.10_workdir.md +++ b/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 # 尽早设置 diff --git a/07_dockerfile/7.12_healthcheck.md b/07_dockerfile/7.12_healthcheck.md index 45232f6..5f8d4a2 100644 --- a/07_dockerfile/7.12_healthcheck.md +++ b/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/* diff --git a/07_dockerfile/7.18_multistage_builds_laravel.md b/07_dockerfile/7.18_multistage_builds_laravel.md index a62188e..1290b1a 100644 --- a/07_dockerfile/7.18_multistage_builds_laravel.md +++ b/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 diff --git a/07_dockerfile/7.5_entrypoint.md b/07_dockerfile/7.5_entrypoint.md index 43fbe3e..edefe01 100644 --- a/07_dockerfile/7.5_entrypoint.md +++ b/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 . . diff --git a/07_dockerfile/7.6_env.md b/07_dockerfile/7.6_env.md index a27e0ac..51c9472 100644 --- a/07_dockerfile/7.6_env.md +++ b/07_dockerfile/7.6_env.md @@ -18,14 +18,14 @@ ENV = = ... #### 设置单个变量 ```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 \ - NODE_VERSION=20.10.0 \ - PYTHON_VERSION=3.12.0 +ENV NGINX_VERSION=1.25 \ + NODE_VERSION=20 \ + 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. 不要存储敏感信息 diff --git a/07_dockerfile/7.7_arg.md b/07_dockerfile/7.7_arg.md index 2633451..7db22c9 100644 --- a/07_dockerfile/7.7_arg.md +++ b/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 . ... ``` diff --git a/07_dockerfile/7.8_volume.md b/07_dockerfile/7.8_volume.md index 1772e6f..23ff096 100644 --- a/07_dockerfile/7.8_volume.md +++ b/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: # 命名卷(推荐) diff --git a/07_dockerfile/README.md b/07_dockerfile/README.md index ba9db62..d17acdd 100644 --- a/07_dockerfile/README.md +++ b/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` 的用法,我们在实战中会结合具体指令进行演示。 diff --git a/08_data/8.1_volume.md b/08_data/8.1_volume.md index e1b6d27..7c3ccdf 100644 --- a/08_data/8.1_volume.md +++ b/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 版本 ``` #### 场景二:多容器共享数据 diff --git a/09_network/9.7_advanced_networking.md b/09_network/9.7_advanced_networking.md index 0e4ddce..baf4dd9 100644 --- a/09_network/9.7_advanced_networking.md +++ b/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 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 db --network mynet postgres:latest +docker run -d --name web --network mynet nginx # 确保与环境兼容的 Nginx 版本 +docker run -d --name db --network mynet postgres # 确保与环境兼容的 PostgreSQL 版本 # 在其他容器中通过服务名访问 docker run -it --network mynet busybox sh diff --git a/10_buildx/10.1_buildkit.md b/10_buildx/10.1_buildkit.md index 449135f..e96606c 100644 --- a/10_buildx/10.1_buildkit.md +++ b/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 官方文档 diff --git a/10_buildx/10.2_buildx.md b/10_buildx/10.2_buildx.md index 2882fcf..019b2e1 100644 --- a/10_buildx/10.2_buildx.md +++ b/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 官方文档 diff --git a/10_buildx/10.3_multi-arch-images.md b/10_buildx/10.3_multi-arch-images.md index 1be0715..1f8797c 100644 --- a/10_buildx/10.3_multi-arch-images.md +++ b/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` 实例 diff --git a/10_buildx/README.md b/10_buildx/README.md index c8355d3..df7a0ea 100644 --- a/10_buildx/README.md +++ b/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 或本地高效校验镜像的安全元数据。 diff --git a/10_buildx/summary.md b/10_buildx/summary.md index f3534d0..016e8d8 100644 --- a/10_buildx/summary.md +++ b/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`,支持更多构建功能 | diff --git a/11_compose/11.2_install.md b/11_compose/11.2_install.md index b4f4b18..ee78238 100644 --- a/11_compose/11.2_install.md +++ b/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 卸载 diff --git a/11_compose/11.6_django.md b/11_compose/11.6_django.md index 3cc59e7..9f64bc4 100644 --- a/11_compose/11.6_django.md +++ b/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 架构概览 diff --git a/11_compose/11.7_rails.md b/11_compose/11.7_rails.md index abc0997..4f5072e 100644 --- a/11_compose/11.7_rails.md +++ b/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 架构概览 diff --git a/11_compose/11.8_wordpress.md b/11_compose/11.8_wordpress.md index fb300d0..91f8e8c 100644 --- a/11_compose/11.8_wordpress.md +++ b/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 环境。 --- diff --git a/12_implementation/12.1_arch.md b/12_implementation/12.1_arch.md index 495bbc3..c89a855 100644 --- a/12_implementation/12.1_arch.md +++ b/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 共享镜像。 --- diff --git a/12_implementation/12.4_ufs.md b/12_implementation/12.4_ufs.md index 6bc0bc1..791160f 100644 --- a/12_implementation/12.4_ufs.md +++ b/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 ``` diff --git a/14_kubernetes_setup/14.1_kubeadm.md b/14_kubernetes_setup/14.1_kubeadm.md index ebf73bd..0b3bb4f 100644 --- a/14_kubernetes_setup/14.1_kubeadm.md +++ b/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 ``` diff --git a/14_kubernetes_setup/14.2_kubeadm-docker.md b/14_kubernetes_setup/14.2_kubeadm-docker.md index 10eb8b1..b1defad 100644 --- a/14_kubernetes_setup/14.2_kubeadm-docker.md +++ b/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 ``` diff --git a/14_kubernetes_setup/14.4_kind.md b/14_kubernetes_setup/14.4_kind.md index 7afa3d7..71f882f 100644 --- a/14_kubernetes_setup/14.4_kind.md +++ b/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 diff --git a/14_kubernetes_setup/14.5_k3s.md b/14_kubernetes_setup/14.5_k3s.md index 606865e..8df6965 100644 --- a/14_kubernetes_setup/14.5_k3s.md +++ b/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`。 diff --git a/15_etcd/15.1_intro.md b/15_etcd/15.1_intro.md index d7acc29..edb48ac 100644 --- a/15_etcd/15.1_intro.md +++ b/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) diff --git a/15_etcd/15.2_install.md b/15_etcd/15.2_install.md index 0f02133..c9fc019 100644 --- a/15_etcd/15.2_install.md +++ b/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 \ diff --git a/15_etcd/15.3_cluster.md b/15_etcd/15.3_cluster.md index f9ac232..6c5e34b 100644 --- a/15_etcd/15.3_cluster.md +++ b/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`) 文件 diff --git a/15_etcd/15.4_etcdctl.md b/15_etcd/15.4_etcdctl.md index f147cd3..ac9326f 100644 --- a/15_etcd/15.4_etcdctl.md +++ b/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) 下载。 diff --git a/15_etcd/README.md b/15_etcd/README.md index c96c561..47aacc0 100644 --- a/15_etcd/README.md +++ b/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) 获取最新版本信息。 ## 本章内容 diff --git a/16_cloud/16.1_intro.md b/16_cloud/16.1_intro.md index 08f9a1b..47a7d0b 100644 --- a/16_cloud/16.1_intro.md +++ b/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 容器编排托管服务 diff --git a/16_cloud/README.md b/16_cloud/README.md index cb01a83..06b8980 100644 --- a/16_cloud/README.md +++ b/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)让用户在云上享有安全高效的镜像托管、分发等服务。 diff --git a/17_ecosystem/17.1_coreos_intro.md b/17_ecosystem/17.1_coreos_intro.md index 00309b0..75c4741 100644 --- a/17_ecosystem/17.1_coreos_intro.md +++ b/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 特性 diff --git a/17_ecosystem/17.3_podman.md b/17_ecosystem/17.3_podman.md index 8c5aa41..4f7aaf9 100644 --- a/17_ecosystem/17.3_podman.md +++ b/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 diff --git a/17_ecosystem/17.4_buildah.md b/17_ecosystem/17.4_buildah.md index 2a42b41..e89415b 100644 --- a/17_ecosystem/17.4_buildah.md +++ b/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 简介 diff --git a/17_ecosystem/17.5_skopeo.md b/17_ecosystem/17.5_skopeo.md index 6b5500b..3d04ce4 100644 --- a/17_ecosystem/17.5_skopeo.md +++ b/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 简介 diff --git a/17_ecosystem/17.6_containerd.md b/17_ecosystem/17.6_containerd.md index da338b4..ccf41c9 100644 --- a/17_ecosystem/17.6_containerd.md +++ b/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 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 原生支持了 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 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? diff --git a/17_ecosystem/17.7_secure_runtime.md b/17_ecosystem/17.7_secure_runtime.md index 4fe1270..6f301ae 100644 --- a/17_ecosystem/17.7_secure_runtime.md +++ b/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 为什么需要安全容器? diff --git a/17_ecosystem/17.8_wasm.md b/17_ecosystem/17.8_wasm.md index 7dd6860..96f3941 100644 --- a/17_ecosystem/17.8_wasm.md +++ b/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? diff --git a/17_ecosystem/README.md b/17_ecosystem/README.md index 1d70ff4..e8638ef 100644 --- a/17_ecosystem/README.md +++ b/17_ecosystem/README.md @@ -1,5 +1,10 @@ # 第十七章 容器其它生态 +> **版本说明**:本章介绍的工具和运行时(Podman、Buildah、Skopeo、containerd、Kata Containers、gVisor、WasmEdge 等)都保持活跃的开发。建议: +> - 查阅各项目官方文档获取最新版本 +> - 在生产环境使用前验证版本兼容性 +> - 关注官方发布说明了解重大变更 + 本章将介绍 Docker 和 Kubernetes 之外的容器生态技术。 ## 本章内容 diff --git a/18_security/18.3_daemon_sec.md b/18_security/18.3_daemon_sec.md index 324a8fd..23adc0b 100644 --- a/18_security/18.3_daemon_sec.md +++ b/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 模式)结合使用,构建纵深防御。 diff --git a/19_observability/19.1_prometheus.md b/19_observability/19.1_prometheus.md index 0b5a135..ac68f5e 100644 --- a/19_observability/19.1_prometheus.md +++ b/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: diff --git a/19_observability/19.2_elk.md b/19_observability/19.2_elk.md index 28b8bdc..1ea6b3b 100644 --- a/19_observability/19.2_elk.md +++ b/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: diff --git a/19_observability/19.3_performance_optimization.md b/19_observability/19.3_performance_optimization.md index 62a2af5..c806ac1 100644 --- a/19_observability/19.3_performance_optimization.md +++ b/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"