4. 镜像构建最佳实践：多阶段构建、基础镜像选择、减少镜像层数、最小化攻击面

在 Serverless 集群中，镜像的构建质量直接决定了启动速度、运行效率与安全基线。本章围绕四个核心维度——多阶段构建、基础镜像选择、减少镜像层数、最小化攻击面——展开最佳实践，帮助团队构建既轻量又安全的交付制品。

4.1 多阶段构建：分离构建环境与运行环境

多阶段构建（Multi-stage Build）允许在同一个 Dockerfile 中使用多个 FROM 指令，将编译工具链、依赖缓存与最终运行产物彻底隔离。最终镜像只包含运行时所需的二进制文件和最小依赖，大幅降低体积与漏洞风险。

# 阶段一：构建环境
FROM golang:1.21-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -o /app/server

# 阶段二：运行环境
FROM alpine:3.19
RUN apk add --no-cache ca-certificates tzdata
COPY --from=builder /app/server /server
EXPOSE 8080
CMD ["/server"]

4.2 基础镜像选择：从源头控制风险

基础镜像是镜像安全的起点。选择原则遵循：最小化、官方维护、固定标签、定期更新。以下对比常见基础镜像类型：

4.3 减少镜像层数：合并指令与清理缓存

Docker 镜像由只读层叠加而成。层数过多会导致：

• 镜像拉取时需下载更多层元数据，增加网络开销
• 层缓存失效概率升高，CI 构建变慢
• 中间层可能残留临时文件或密钥

以下对比优化前后的 Dockerfile 写法：

RUN apt-get update
RUN apt-get install -y curl
RUN apt-get install -y jq
RUN rm -rf /var/lib/apt/lists/*

RUN apt-get update && \
    apt-get install -y curl jq && \
    rm -rf /var/lib/apt/lists/*

4.4 最小化攻击面：删除一切非必要组件

攻击面最小化是镜像安全的核心目标。每个多余的二进制、库文件、配置文件都可能成为攻击入口。以下是最小化攻击面的检查清单：

• 移除 shell 和包管理器： 使用 distroless 或 scratch 镜像，攻击者无法通过 shell 执行命令
• 删除 setuid/setgid 权限： RUN find / -perm /6000 -type f -exec chmod a-s {} \;
• 不以 root 运行： 创建专用用户，USER 10001
• 只暴露必要端口： 默认关闭所有端口，仅开放应用监听端口
• 清理 .env、密钥、历史文件： 构建阶段不复制敏感文件到运行阶段
• 使用只读根文件系统： 在 Kubernetes 中设置 readOnlyRootFilesystem: true

# 最小攻击面 Dockerfile 示例
FROM golang:1.21-alpine AS builder
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 go build -o /app/server

FROM gcr.io/distroless/static-debian12:nonroot
COPY --from=builder /app/server /server
EXPOSE 8080
USER 10001
CMD ["/server"]

4.5 镜像构建最佳实践总览

以下 SVG 图展示了从代码提交到安全镜像产出的完整构建流程，突出四个核心实践在流水线中的位置：

4.6 常见陷阱与规避策略

4.7 实践检查清单

每次构建前，对照以下清单逐项确认：

1. 基础镜像： 是否使用官方维护的最小镜像？标签是否固定？
2. 多阶段构建： 构建阶段是否与运行阶段完全分离？运行阶段是否只复制了必要的二进制文件？
3. 层数控制： 是否合并了同类 RUN 指令？是否在指令末尾清理了缓存？
4. 攻击面最小化： 是否移除了 shell、包管理器、setuid 权限？是否以非 root 用户运行？
5. 安全扫描： 镜像是否通过 Trivy 或 Grype 扫描？CVE 数量是否为 0？
6. 可复现性： Dockerfile 是否不依赖外部网络资源？是否使用 --no-cache 构建？