1. 容器化应用镜像构建与最小化优化

为什么镜像体积值得认真对待

一个典型的多依赖 Web 应用（以 Node.js 为例）如果直接把源码、node_modules、构建工具链全部塞进最终镜像，体积很容易达到 1GB 以上。镜像越大，带来的实际代价是：

• 推送/拉取耗时增加，滚动更新时 Pod 启动变慢；
• 节点磁盘与镜像仓库存储成本上升；
• 构建工具、包管理器缓存、源码等进入运行时镜像，扩大攻击面。

本案例的目标是：把一个多依赖 Web 应用打包为 Docker 镜像，通过多阶段构建与基础镜像选择把最终镜像压到最小，并验证容器内应用能正常启动。

核心思路：构建期与运行期分离

多阶段构建的本质是把 Dockerfile 拆成两个逻辑环境：builder 阶段负责安装全部依赖并产出构建产物；runtime 阶段只拷贝运行必需的产物，不携带编译器、开发依赖和包管理器缓存。下图展示了两个阶段的输入、产物与最终镜像的组成关系。

Dockerfile 实现

下面是一个可直接使用的多阶段 Dockerfile。关键点：builder 阶段用 npm ci 保证依赖可复现，runtime 阶段只拷贝 dist 与生产依赖，并用非 root 用户运行。

# ---------- 阶段 1：builder ----------
FROM node:20-alpine AS builder
WORKDIR /app

# 先拷贝依赖清单，利用层缓存
COPY package.json package-lock.json ./
RUN npm ci

# 再拷贝源码并构建
COPY . .
RUN npm run build

# 只保留生产依赖，减小后续拷贝体积
RUN npm prune --omit=dev

# ---------- 阶段 2：runtime ----------
FROM node:20-alpine AS runtime
WORKDIR /app
ENV NODE_ENV=production

# 从 builder 拷贝构建产物与生产依赖
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/package.json ./

# 使用非 root 用户运行
USER node

EXPOSE 3000
CMD ["node", "dist/server.js"]

构建与体积验证

构建镜像并查看体积：

docker build -t webapp:optimized .
docker images webapp:optimized

对比单阶段构建（把整个项目目录直接 COPY 进 node 镜像）的体积差异，通常可观察到数倍差距。若需进一步定位体积来源，可用：

docker history webapp:optimized

容器内应用启动验证

镜像体积优化后必须确认应用仍能正常启动，否则优化没有意义。启动容器并检查：

docker run -d --name webapp-test -p 3000:3000 webapp:optimized
docker logs webapp-test
curl -s http://localhost:3000/health

判断标准：

• docker logs 中无 Cannot find module 或 EACCES 报错；
• /health 返回 200 且响应体符合预期；
• docker exec webapp-test whoami 输出 node，确认非 root 运行。

优化检查清单