第四章: Dockerfile 生产级最佳实践

第四章: Dockerfile 生产级最佳实践

摘要: 在前几章中，我们学会了如何使用和管理别人构建好的镜像。从本章开始，我们将迎来一次质的飞跃：亲手创造属于我们自己的、生产就绪的镜像。我们将以 Dockerfile 这个强大的“建筑图纸”为核心工具，将一个从零开始创建的现代化 Vite + React 应用，通过一系列循序渐进的优化，最终封装成一个体积小巧、构建迅速、安全可靠的 Docker 镜像。这不再是理论学习，这是一场彻头彻尾的实战演练。

4.0 项目准备：从零开始创建 Vite 应用

在为应用编写 Dockerfile 之前，我们得先有一个应用。我们将完全模拟真实开发流程，在 WSL2 中初始化一个项目。

第一步：准备 Node.js 环境

虽然您的环境可能已安装 Node.js，但为了保证教程的统一性与最佳实践，我们推荐使用 nvm (Node Version Manager) 来管理 Node.js 版本。

打开您的 Windows Terminal (WSL2/Ubuntu) 环境，执行以下命令安装 nvm：

1
2
3
4
5
# 从 nvm 的 GitHub 仓库下载并执行安装脚本 (版本号可能更新，此为示例)
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash

# 让 nvm 命令立即生效（或重启终端）
source ~/.bashrc

安装完成后，我们来安装 Node.js 的长期支持版 (LTS)，并在 2025 年，我们选择 v20.x 系列：

1
2
3
4
5
6
7
8
9
# 安装 Node.js v20 LTS 版本
nvm install 20

# 将 v20 设置为默认使用版本
nvm use 20
nvm alias default 20

# 验证安装成功
node -v && npm -v

第二步：使用 Vite 创建 React + TypeScript 项目

现在，我们使用 Vite 的官方脚手架来快速生成项目结构。

1
2
3
4
# 在你的主目录或工作目录下执行

# 命令会引导你进行选择，我们一路选择 React -> TypeScript
npm create vite@latest

Vite CLI 会以交互方式提问，请按以下方式选择：

  1. Project name: my-react-app
  2. Select a framework: React
  3. Select a variant: TypeScript

第三步：安装依赖并验证项目
项目已创建，让我们进入目录，安装依赖，并验证它能否在本地正常运行。

1
2
3
4
5
6
7
8
# 进入项目目录
cd my-react-app

# 安装项目所需的所有依赖包
npm install

# 启动本地开发服务器
npm run dev

现在，按住 Ctrl 并点击 http://localhost:5173/ 链接，它应该会在你的 Windows 浏览器中打开 Vite + React 的默认欢迎页面。

确认页面正常显示后，回到终端按 Ctrl+C 停止开发服务器。

准备就绪！ 我们现在拥有了一个功能完备、结构清晰的现代 Web 应用。它的目录结构如下，这将是我们本章进行所有 Dockerfile 操作的基础。

1
2
3
4
5
6
7
8
9
10
# my-react-app/
.
├── node_modules/       # npm 依赖 (需要被忽略)
├── public/
├── src/
│   ├── App.tsx
│   └── main.tsx
├── index.html
├── package.json
└── vite.config.ts

4.1. 构建的基石：设定构建上下文 (Build Context) 与 .dockerignore

承上启下: 我们的项目已经准备好，现在可以在项目根目录下（my-react-app/）开始编写 Dockerfile 了。但在写下第一行 FROM 指令之前，有一个至关重要的、却常常被新手忽略的步骤：告诉 Docker 引擎，哪些文件“不应该”被看到。

痛点背景: 当我们执行 docker build . 命令时，最后的 . 代表了 构建上下文 (Build Context)。Docker 客户端会把这个路径下 所有 的文件和目录（除了被忽略的）打包发送给 Docker 守护进程。如果不对其进行限制：

  • 构建缓慢: 体积巨大的 node_modules 目录（可能包含数万个小文件）和 .git 目录会被一同发送，极大地拖慢了构建的初始速度。
  • 镜像臃肿: 如果这些文件被不小心 COPY 进了镜像，会造成镜像体积无意义地膨胀。
  • 安全风险: 可能会将包含密钥的 .env 文件或本地日志等敏感信息打包进镜像中。

解决方案: 在项目根目录下创建一个名为 .dockerignore 的文件，它的语法和 .gitignore 完全一样，用于从构建上下文中排除文件和目录。

实战操作: 在 my-react-app 目录下，创建一个新文件 .dockerignore。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# .dockerignore

# 排除所有 node_modules 目录
**/node_modules

# 排除 Git 仓库目录
.git

# 排除本地开发和构建的产物目录
dist
coverage

# 排除 Vite 的缓存目录
.vite

# 排除敏感的环境变量文件
.env*

# 排除日志文件
*.log

创建好 .dockerignore 文件，就像是为我们的构建过程设置了一个“门卫”。现在，当我们执行构建时，Docker 守护进程只会收到一个干净、轻量的项目包，为后续的高效构建打下了坚实的基础。

现在，同样在 my-react-app 目录下，创建我们本章的主角——Dockerfile 文件。我们将在接下来的小节中逐步填充和完善它的内容。

4.2. 初版构建：一个能工作，但有陷阱的 Dockerfile

承上启下: 我们的项目和 .dockerignore 文件都已就绪，现在可以正式开始编写 Dockerfile 了。在本节中，我们的目标是创建“v0.1”版本——一个能成功将 React 应用打包成可运行镜像的、简单直观的 Dockerfile。在这个过程中，我们将主动规避一个极其常见的容器网络陷阱，并最终揭示这个初版 Dockerfile 在构建效率上存在的致命缺陷，为后续的优化做足铺垫。

第一步：让我们的应用变得“容器友好”

在将任何 Web 服务容器化之前，一个专业的开发者会首先确保该服务能被容器环境正确地访问。这涉及到一个核心的网络概念：网络绑定地址。

  • 出于安全考虑，许多开发服务器（包括 Vite）默认只监听 localhost (即 127.0.0.1)。
  • 在容器的独立网络世界里，localhost 指的是 容器自己，这意味着服务只接受来自容器 内部 的连接。
  • 当我们从主机浏览器访问时，流量经过 Docker 的端口映射进入容器，这在容器看来是 外部 连接，因此会被默认的服务设置所拒绝。

为了让服务能被外部访问，我们必须让它监听 0.0.0.0，这个特殊的 IP 地址意为“监听本机上所有可用的网络接口”。

实战操作： 我们通过修改 package.json 来实现这一点，这比在 Dockerfile 中通过命令行参数修改更为稳健。

  1. 在 VS Code 中，打开 my-react-app/package.json 文件。
  2. 找到 "scripts" 部分下的 "preview" 命令。
  3. 为 vite preview 添加 --host 标志，指示它监听所有网络接口。
1
2
3
4
5
6
7
// package.json
"scripts": {
  "dev": "vite",
  "build": "tsc && vite build",
  // 将 "vite preview" 修改为 "vite preview --host"
  "preview": "vite preview --host"
},

通过这个简单的修改，我们的应用现在已经为容器化做好了充分的准备。

第二步：编写 Dockerfile v0.1

现在，在 VS Code 中打开 Dockerfile 文件，并粘贴以下内容。这是一个逻辑清晰的初稿：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
# Dockerfile (版本 0.1 - 初始草稿)

# 1. 选择一个包含 Node.js 环境的基础镜像
FROM node:20

# 2. 在容器内部设置工作目录
WORKDIR /app

# 3. 复制所有项目文件到工作目录
# 这是最简单直接，但也是效率最低的方式
COPY . .

RUN npm install -g pnpm
# 4. 安装所有 npm 依赖
RUN pnpm install

# 5. 编译 TypeScript/React 应用为静态文件
RUN pnpm run build

# 6. 声明容器将监听的端口
EXPOSE 4173

# 7. 定义容器启动时执行的命令
# 调用我们在 package.json 中配置好的、容器友好的 preview 脚本
CMD ["pnpm", "run", "preview"]

第三步：构建并运行容器

在 VS Code 的集成终端中，执行以下命令来构建镜像和启动容器：

1
2
3
4
5
# 构建镜像，并标记为 my-react-app: 0.1
docker build -t my-react-app:0.1 .

# 以后台模式启动容器，并进行端口映射
docker run -d --name webapp-v0.1 -p 8888:4173 my-react-app:0.1

构建完成后，打开你的 Windows 浏览器并访问 http://localhost:8888。您应该能成功看到 Vite + React 的欢迎页面，它现在正由一个完全独立的 Docker 容器提供服务。

第四步：揭示性能陷阱

我们的容器虽然能工作，但现在我们将展示其作为“初稿”的致命缺陷。

  1. 在 VS Code 中，打开 src/App.tsx 文件。

  2. 做一点微小的修改，例如，将 <h1>Vite + React</h1> 改为 <h1>Vite + React in Docker!</h1>。

  3. 回到终端，基于修改后的代码，重新构建一个 v0.2 版本的镜像：

    1
    docker build -t my-react-app:0.2 .

仔细观察构建过程的输出。您会发现，即使我们只改动了一行业务代码，与 npm 依赖毫无关系，Docker 依然 完整地、缓慢地重新执行了 RUN npm install 步骤。

陷阱所在: 我们的 COPY . . 指令位于 RUN npm install 之前。这意味着项目中的 任何文件 改动，都会导致 COPY 层的缓存失效。一旦某个层的缓存失效，其 后续所有层 的缓存都会随之失效，Docker 必须重新执行从 COPY 开始的所有步骤，包括耗时的依赖安装。

在进入下一节优化之前，让我们先清理掉刚刚创建的容器：

1
docker stop webapp-v0.1 && docker rm webapp-v0.1

我们已经成功地构建并运行了第一个容器，并精准地定位了它的性能瓶颈。在下一节中，我们将学习如何利用 Docker 的缓存机制，彻底解决这个问题。

4.3. 效率革命：精通构建缓存与指令顺序的艺术

承上启下: 在上一节，我们成功构建并运行了 v0.1 版本的镜像，但也暴露了它在构建效率上的一个巨大缺陷：哪怕只修改一行代码，也要重新经历漫长的 npm install 过程。这在频繁提交代码的 CI/CD 流程中是不可接受的。本节，我们将通过重构 Dockerfile，学会利用 Docker 的核心特性——层缓存，将构建速度提升一个数量级。

痛点背后的原理：Docker 的层缓存机制

要解决问题，必先理解其根源。Docker 在构建镜像时，会严格按照 Dockerfile 中的指令顺序，一步步执行。每一条指令，都会生成一个镜像层。

Docker 会为每一个成功构建的层计算一个哈希值并将其缓存下来。在下一次构建时，Docker 会逐行检查指令：

  • 如果指令和它操作的文件内容都没有任何变化，Docker 就会直接使用上一次缓存的层（你会看到 ---> Using cache），跳过实际执行。
  • 但是，一旦某一条指令因为自身或其依赖的文件发生变化而导致缓存失效，那么从这一层开始，其后所有步骤的缓存都将全部失效，必须被重新执行。

回顾我们的 v0.1 版本，COPY . . 指令位于 RUN npm install 之前。COPY . . 依赖于整个项目目录的内容。当我们修改 src/App.tsx 时，COPY . . 指令的输入发生了变化，它的缓存失效了。因此，它后面的 RUN npm install 和 RUN npm run build 指令也必须被强制重新执行。

解决方案：重排指令，将变化频率作为唯一标准

优化的核心思想非常简单：将最稳定、最不经常变化的部分放在 Dockerfile 的最前面。

在我们的项目中：

  • 最稳定的是：项目依赖 package.json 和 package-lock.json。只有当我们添加或删除依赖时，它们才会改变。
  • 最善变的是：我们的业务源代码，如 src/ 目录下的文件。

因此，一个高效的 Dockerfile 应该遵循以下逻辑：

  1. 先只复制 package*.json 文件。
  2. 然后执行 npm install。这一步只依赖 package*.json，只要依赖不变更，这一层就可以被永久缓存。
  3. 最后再复制我们经常修改的源代码。

实战操作：重构 Dockerfile 为 v0.2

让我们将理论付诸实践。修改 Dockerfile 文件，内容如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
# Dockerfile (版本 0.1 - 初始草稿)

# 1. 选择一个包含 Node.js 环境的基础镜像
FROM node:20

# 2. 在容器内部设置工作目录
WORKDIR /app

# 3. (优化点) 先只复制依赖描述文件
# 使用通配符 `*` 来同时匹配 package.json 和 package-lock.json
COPY package*.json ./

# 4. (优化点) 安装依赖
# 这一步现在只依赖于上一步复制的文件。只要 package*.json 不变，这一层就会命中缓存。
RUN npm install -g pnpm
RUN pnpm install


# 5. (优化点) 复制所有源代码和项目文件
# 这是变化最频繁的部分，我们把它放在依赖安装之后。
COPY . .

# 6. 构建应用
RUN pnpm run build

# 7. 暴露端口
EXPOSE 4173


# 8. 定义启动命令
CMD ["pnpm", "run", "preview"]

见证效率的飞跃

让我们用这个优化后的 Dockerfile 来验证效果。

第一步：构建 v0.2 版本

1
2
# 构建优化后的版本，这次 npm install 依然会完整运行
docker build -t my-react-app:0.2 .

第二步：再次修改源代码
在 VS Code 中，再次打开 src/App.tsx 文件，做另一次修改，例如，将 <h1>Vite + React in Docker!</h1> 改为 <h1>Cache Optimized!</h1>。

第三步：构建 v0.3 版本，见证奇迹

现在，请仔细观察终端的输出。你会看到一个决定性的变化：

1
docker build -t my-react-app:0.3 .

成功了！ 正如输出所示，COPY package*.json ./ 和 RUN npm install 步骤都明确地显示了 ---> Using cache。构建过程直接跳过了耗时的依赖安装，从 COPY . . 这一步才开始重新执行，整个构建过程可能从几分钟缩短到了几秒钟。这就是指令顺序的艺术。

COPY vs ADD：一个明确的选择

在 Dockerfile 中，你可能还会看到一个与 COPY 功能相似的指令 ADD。

  • COPY: 功能纯粹，就是将文件或目录从构建上下文复制到镜像中。
  • ADD: 功能更复杂，它除了能做 COPY 的所有事，还有两个额外的特性：
    1. 如果源文件是一个可识别的压缩包（如 .tar, .gzip），ADD 会自动将其解压到目标路径。
    2. 如果源是一个 URL，ADD 会尝试下载该文件。

最佳实践: 除非你明确需要 ADD 的自动解压或 URL 下载功能，否则 始终优先使用 COPY。COPY 的行为更透明、更可预测。使用 COPY 能清晰地表明你的意图只是复制文件，这使得 Dockerfile 更易于理解和维护。

在结束本节前，让我们清理环境：

1
2
# 我们并没有运行容器，所以只需要清理掉构建的镜像即可
docker rmi my-react-app:0.1 my-react-app:0.2 my-react-app:0.3

4.4. 镜像瘦身（上）：选择合适的基础镜像

承上启下: 在上一节，我们通过优化指令顺序，极大地提升了 构建速度。现在，我们要关注另一个核心指标：镜像体积。我们 v0.2 版本的镜像是基于 node:20 构建的，它功能完备，但体积也相当庞大。一个臃肿的镜像会占用更多的磁盘和仓库存储，更重要的是，它会显著拖慢 CI/CD 流程中的拉取（pull）和推送（push）速度。本节，我们将学习第一个，也是最立竿见影的瘦身技巧：选择一个更小的基础镜像。

痛点背景：默认基础镜像的“慷慨”

当我们使用 FROM node:20 时，我们实际上得到的是一个基于完整版 Debian 操作系统的镜像。它包含了 bash、curl、git 以及大量编译工具和系统库。这些工具在某些场景下很有用，但对于一个已经构建好的、只想安静态运行的 Node.js 应用来说，90% 的内容都是不必要的“脂肪”。

解决方案：探索更苗条的镜像变体

Docker Hub 上的官方镜像通常会提供多种“风味”的标签（Tag），以满足不同需求。对于 Node.js 镜像，最常见的两种瘦身变体是：

  • node:<version>-slim: 这是一个“修身版”。它同样基于 Debian，但移除了许多非核心的软件包。体积适中，兼容性好，是一个稳健的折中选择。
  • node:<version>-alpine: 这是一个“极限版”。它基于 Alpine Linux，一个以安全和轻量著称的极简发行版。它的体积非常小，能极大地缩减最终镜像的尺寸。

实战操作：直观对比体积差异

让我们通过亲手构建来感受一下这种差异有多么巨大。

第一步：构建一个“全尺寸”的基准镜像

首先，请确保你的 Dockerfile 内容是我们在 4.3 节优化缓存后的版本。然后，修改第一行，明确指定使用完整的 node:20 镜像，并构建它。

1
2
3
# Dockerfile
# 明确使用默认的、全尺寸的 Debian 版本
FROM node:20

现在，构建这个全尺寸的镜像：

1
docker build -t my-react-app:full-debian .

第二步：切换到 alpine 并构建“极限版”镜像

接下来，我们只做一行修改：将基础镜像换成 alpine 版本。

1
2
3
4
5
6
7
8
9
10
11
12
13
# Dockerfile

# 将基础镜像切换为极度轻量化的 Alpine 版本
FROM node:20-alpine

# ... (后续内容完全不变) ...
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build
EXPOSE 4173
CMD ["npm", "run", "preview"]

构建这个 Alpine 版本的镜像：

1
docker build -t my-react-app:alpine .

第三步：见证瘦身成果

所有构建都已完成。现在，让我们使用 docker images 命令来检阅我们的劳动成果：

1
docker images

效果惊人！ 结果一目了然。仅仅通过修改 Dockerfile 的第一行，我们的应用镜像体积就从 1.13GB 骤降到了 315MB，缩减了超过 70%。在真实的部署流程中，这意味着更快的分发速度和更低的存储成本。

Alpine 的权衡：glibc vs musl libc

天下没有免费的午餐。Alpine 之所以能做到如此小巧，一个重要原因是它使用了 musl libc 作为标准的 C 库，而不是像 Debian/Ubuntu 等大多数 Linux 发行版那样使用 glibc。

  • glibc: 功能全面，兼容性最好，但体积较大。
  • musl libc: 设计轻量，注重标准和安全，但与一些依赖特定 glibc 特性的二进制包不兼容。

潜在的坑: 对于我们纯 JavaScript 的 React 应用来说，使用 Alpine 通常是安全的。但如果你的 Node.js 项目依赖了一些需要编译原生 C++ 插件的库（例如一些图像处理、加密或数据库驱动库），这些插件可能在 musl libc 环境下编译失败或运行出错。因此，当你选择 Alpine 作为基础镜像时，必须进行充分的测试，确保所有功能都能正常工作。如果遇到兼容性问题，node:<version>-slim 是一个极好的替代方案。

在结束本节前，让我们清理掉本次实验创建的镜像：

1
docker rmi my-react-app:full-debian my-react-app:alpine

我们已经成功地为镜像进行了第一次“大瘦身”。然而，当前的 Alpine 版本镜像中，依然包含了大量仅在“构建”阶段需要的开发依赖和工具。在下一节，我们将学习终极瘦身武器——多阶段构建，将这些“杂质”彻底从最终的生产镜像中剔除。

4.5. 镜像瘦身（下）：终极武器之 多阶段构建 (Multi-stage Builds)

承上启下: 上一节，我们通过切换到 Alpine 基础镜像，将镜像体积从 1.13GB 成功压缩到了约 315MB，成效显著。但这还远未达到极限。仔细思考一下，我们当前的 my-react-app:alpine 镜像中，到底包含了些什么？

  • 完整的 Node.js 运行时环境。
  • npm 包管理器。
  • package.json 中定义的所有 dependencies 和 devDependencies（例如 vite, typescript, @types/react 等）。
  • 我们全部的 TypeScript 源代码（src 目录）。
  • 最终编译生成的、真正对用户有用的静态文件（dist 目录）。

一个残酷的现实是：在生产环境中，为了让用户能看到我们的网页，我们真正需要的，仅仅是第 5 项——那个 dist 目录，以及一个能提供静态文件服务的 Web 服务器。其他所有东西，都是构建过程中产生的“脚手架”和“工业垃圾”，它们不仅让镜像变得臃肿，还因为包含了大量非必要的软件（如编译工具、开发服务器）而增大了潜在的攻击面。

解决方案：多阶段构建

多阶段构建允许我们在一个 Dockerfile 中使用多个 FROM 指令。每一个 FROM 都开启一个全新的、独立的构建 阶段 (Stage)。这让我们可以实现一个完美的“阅后即焚”流程：

  1. “构建器”阶段: 我们先在一个包含完整 Node.js 环境的阶段中，安装所有依赖、编译代码、运行测试，生成最终的 dist 目录。
  2. “最终”阶段: 我们另起一个新的阶段，选择一个极度轻量级的、不含 Node.js 的生产级 Web 服务器镜像（如 Nginx），然后只从“构建器”阶段 拷贝 出我们唯一需要的 dist 目录。

构建结束后，那个包含了所有“垃圾”的“构建器”阶段会被 直接丢弃，我们得到的将是一个只包含最终产物和最小化运行环境的、极致精简的生产镜像。

实战操作：打造生产级 Dockerfile

第一步：为 Nginx 准备 SPA 配置文件
单页应用（SPA）依赖前端路由，这意味着对于像 /about 或 /users/1 这样的路径，Nginx 不能去文件系统里找对应的目录，而应该总是返回 index.html，让 React Router 来接管。我们需要创建一个简单的 Nginx 配置文件来告知它这个规则。

在你的 my-react-app 项目根目录下，创建一个名为 nginx.conf 的文件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# nginx.conf

server {
    listen       80;
    server_name  localhost;

    # 设定静态文件的根目录
    root   /usr/share/nginx/html;
    index  index.html;

    location / {
        # 核心配置：尝试查找请求的文件，如果找不到，就回退到 index.html
        try_files $uri $uri/ /index.html;
    }

    # 可以添加 gzip 压缩等优化
    gzip on;
    gzip_min_length 1000;
    gzip_proxied expired no-cache no-store private auth;
    gzip_types text/plain text/css application/json application/javascript application/x-javascript text/xml application/xml application/xml+rss text/javascript;
}

第二步：编写多阶段构建的 Dockerfile

现在，用以下内容彻底覆盖你的 Dockerfile：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
# Dockerfile (版本 1.0 - 生产就绪版)

# ---- 第一阶段: 构建器 (Builder) ----
# 我们给这个阶段命名为 "builder"，以便后续引用
FROM node:20-alpine AS builder

WORKDIR /app

# 复制依赖描述文件并安装所有依赖（包括 devDependencies）
COPY package*.json ./
RUN npm install -g pnpm
RUN pnpm install

# 复制所有源代码
COPY . .

# 执行构建命令，生成 /app/dist 目录
RUN pnpm run build


# ---- 第二阶段: 最终镜像 (Final Image) ----
# 从一个极度轻量的 Nginx 镜像开始，它才是我们生产环境需要的
FROM nginx:stable-alpine

# 将我们自定义的 Nginx 配置文件复制到容器中
COPY nginx.conf /etc/nginx/conf.d/default.conf

# 从 "builder" 阶段，只拷贝出我们需要的构建产物
# 语法：COPY --from=[阶段名] [源路径] [目标路径]
COPY --from=builder /app/dist /usr/share/nginx/html

# 暴露 Nginx 默认的 80 端口
EXPOSE 80

# Nginx 镜像已经有默认的 CMD 来启动服务，我们无需再写

第三步：构建并见证终极瘦身

让我们构建这个代表着最终成果的生产镜像：

1
docker build -t my-react-app:production-v1.0 .

构建完成后，再次执行 docker images，并将我们一路走来的所有版本进行对比：

1
2
3
4
REPOSITORY          TAG               IMAGE ID       CREATED          SIZE
my-react-app        production-v1.0   7d8e9f0a1b2c   2 minutes ago    42.5MB
my-react-app        alpine            a1b2c3d4e5f6   About an hour ago    315MB
my-react-app        full-debian       f6e5d4c3b2a1   About an hour ago    1.13GB

无与伦比的优化！ 最终的生产镜像体积仅为 42.5MB！

  • 相比最初的 1.13GB，体积缩减了 96% 以上。
  • 相比 Alpine 单阶段版本，体积也进一步缩减了 86%。
  • 最重要的是，这个镜像的 攻击面被降到了最低。它不包含 Node.js，不包含 npm，不包含源代码，不包含任何编译工具，只包含一个身经百战的 Nginx 和我们编译好的静态文件。这才是真正的生产级交付物。

第四步：运行并验证生产镜像

1
2
# 注意容器端口现在是 Nginx 默认的 80
docker run -d --name webapp-prod -p 8080:80 my-react-app:production-v1.0

访问 http://localhost:8080，你的 React 应用正由一个轻快、稳固的 Nginx 服务器提供服务。

在结束本章的核心实战前，让我们清理所有实验过程中的容器和镜像：

1
2
docker stop webapp-prod && docker rm webapp-prod
docker rmi my-react-app:production-v1.0 my-react-app:alpine my-react-app:full-debian

4.6. 安全加固：以 非 root 用户 运行你的应用

承上启下: 我们在 4.5 节中构建的 production-v1.0 镜像，在体积和结构上已经达到了生产级标准。现在，我们要关注一个同样重要、但更侧重于 安全 的方面。默认情况下，容器内的进程是以最高权限用户——root——来运行的。这是一个潜在的、必须被修复的安全隐患。

痛点背景：root 权限的风险

遵循“最小权限原则”是所有安全规范的基石。让应用以 root 用户身份在容器内运行，会带来不必要的风险：

  • 增大了攻击面: 如果应用本身存在漏洞（例如，任意文件上传或远程代码执行），攻击者一旦利用漏洞获得了应用的控制权，他也就获得了容器内的 root 权限。
  • 增加了“容器逃逸”的风险: 虽然容器技术提供了有效的隔离，但历史上也出现过需要特定内核权限才能利用的 Linux 内核漏洞。如果攻击者在容器内是 root，他将拥有更多尝试利用这些漏洞、从容器“逃逸”到宿主机系统的能力。

解决方案：创建并切换到非特权用户

最佳实践是在 Dockerfile 中创建一个专用的、低权限的应用程序用户，并在容器启动前，使用 USER 指令切换到该用户。

实战验证：官方镜像的良好实践

幸运的是，我们为最终阶段选择的 nginx:stable-alpine 是一个维护精良的官方镜像，它已经为我们内置了安全实践。我们无需自己添加用户，但我们可以学会 如何去验证 这一点。

第一步：启动我们的生产容器

1
2
3
4
5
# 如果你已清理环境，请先重新构建 v1.0 镜像
# docker build -t my-react-app: production-v1.0 .

# 启动生产容器
docker run -d --name webapp-prod -p 8080:80 my-react-app:production-v1.0

第二步：进入容器并检查进程

1
2
3
4
5
# 进入正在运行的容器
docker exec -it webapp-prod sh

# 在容器内部，使用 ps aux 命令查看所有正在运行的进程
/ # ps aux

结果分析:
请仔细观察 USER 列。你会发现一个关键的安全设计：

  • PID 为 1 的 Master Process（主进程）是以 root 用户启动的。这是必需的，因为在类 Unix 系统中，只有 root 用户才有权限绑定到 1024 以下的端口（例如 Nginx 默认的 80 端口）。
  • 但真正处理用户请求、执行业务逻辑的 Worker Processes（工作进程），其用户是 nginx——这是一个由基础镜像预先创建好的、权限受限的非特权用户。

这意味着，即使 Nginx 的某个工作进程被漏洞攻陷，攻击者获得的也只是一个受限的 nginx 用户权限，而不是为所欲为的 root 权限。这个发现告诉我们一个宝贵的经验：尽可能选择并信任由官方维护的基础镜像。它们通常已经包含了大量的、经过社区检验的安全与最佳实践，让我们能站在巨人的肩膀上，避免重复造轮子和踩坑。

当我们需要自己创建用户时

当然，并非所有基础镜像都像 Nginx 一样配置完备。当你使用一个更通用的基础镜像（如 alpine 或 debian）来构建自定义应用时，你就必须自己负责创建和切换用户。

以下是在 Dockerfile 中创建和使用非 root 用户的标准模式，供你日后参考：

Dockerfile 安全模式：创建非 Root 用户 (Alpine)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# 假设我们基于一个纯净的 Alpine 镜像
FROM alpine:latest

# 1. 创建一个系统组（-S）和一个系统用户（-S），并将其加入该组
#    -D 参数表示不为用户创建密码
RUN addgroup -S appgroup && adduser -S appuser -G appgroup

# 2. 切换工作目录，并确保新用户拥有该目录的权限
WORKDIR /app
# 使用 COPY 的 --chown 标志，在复制文件的同时，将其所有者设置为新创建的用户和组
COPY --chown=appuser:appgroup . .

# 3. 切换到新创建的非特权用户
#    此后的所有指令（如 CMD）都将以 appuser 的身份运行
USER appuser

# 定义启动命令
CMD ["./my-application"]

通过本节的学习，我们不仅验证了当前生产镜像的安全性，更掌握了在任何 Dockerfile 中实施“最小权限原则”的通用方法。