镜像优化：多阶段构建、基础镜像选择、镜像瘦身技巧、安全扫描与漏洞修复

镜像优化这事儿，说白了就是给容器「减负」。我见过太多生产环境里，一个镜像动辄几个G，拉取慢、启动慢、漏洞还多。今天咱们就聊聊怎么把镜像做得又小又安全。

基础镜像选择：别什么都从零开始

选基础镜像，我个人的习惯是「够用就好」。你想想看，一个Java应用非要装个完整版的Ubuntu，里面几百个包其实一个都用不上。

常用的基础镜像有这么几类：

镜像类型 大小 适用场景
alpine ~5MB 静态编译、Go/Rust应用
slim ~30MB Python、Node.js应用
distroless ~20MB Java、.NET应用
scratch 0MB 纯静态二进制
我的建议：能用alpine就别用ubuntu，能用slim就别用full。我在项目中遇到过，一个Node应用从node:16换成node:16-slim，镜像从1.2GB直接降到180MB。

多阶段构建：把构建环境和运行环境分开

多阶段构建是镜像瘦身的核心武器。原理很简单——编译时需要的工具，运行时根本不需要。

来看个例子，一个Go应用的Dockerfile：

# 第一阶段：编译
FROM golang:1.20 AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -o myapp

# 第二阶段：运行
FROM alpine:3.18
RUN apk add --no-cache ca-certificates
COPY --from=builder /app/myapp /usr/local/bin/
EXPOSE 8080
CMD ["myapp"]

你看，第一阶段装了一堆编译工具，最后只把编译好的二进制拷过来。最终镜像只有十几MB。

关键点：多阶段构建不是把多个FROM写在一起就完事了。你得想清楚——哪些东西是构建时需要的，哪些是运行时需要的。我曾经见过有人把npm缓存也拷到最终镜像里，那跟没做多阶段构建没啥区别。

镜像瘦身技巧：能删就删，能合就合

镜像瘦身，我总结了几个实用技巧：

  • 清理包管理器缓存——apt clean、yum clean all、apk cache clean，这些命令一定要在同一个RUN里执行
  • 合并RUN指令——每多一个RUN就会多一层，尽量把相关的命令合并到一起
  • 删除临时文件——下载的压缩包、编译中间产物，用完就删
  • 使用.dockerignore——别把node_modules、.git这些文件拷进去

举个例子，一个Python应用的Dockerfile优化前后对比：

# 优化前
FROM python:3.11-slim
RUN pip install flask
COPY app.py /app/
CMD ["python", "/app/app.py"]

# 优化后
FROM python:3.11-slim AS builder
RUN pip install --no-cache-dir flask
COPY app.py /app/

FROM python:3.11-slim
COPY --from=builder /usr/local/lib/python3.11/site-packages /usr/local/lib/python3.11/site-packages
COPY --from=builder /app /app
CMD ["python", "/app/app.py"]
注意：合并RUN指令不是无脑合并。如果两个指令的缓存策略不同，分开写反而更好。比如apt update和apt install，分开写可以利用缓存。

安全扫描与漏洞修复：别让镜像成为定时炸弹

镜像安全这事儿，我吃过亏。有一次线上环境被扫出几十个高危漏洞，排查下来发现是基础镜像里的一个旧版本openssl。从那以后，我把安全扫描加到了CI/CD流程里。

常用的安全扫描工具有这些：

  • Trivy——轻量、快速、支持多种格式
  • Clair——Red Hat出品，集成度高
  • Docker Scout——Docker官方工具
  • Grype——Anchore开源项目

我个人习惯用Trivy，一行命令就能扫：

trivy image myapp:latest

扫出来漏洞怎么办？我的处理流程是这样的：

  1. 先看严重等级——CRITICAL和HIGH的优先处理
  2. 判断是否可被利用——有些漏洞虽然存在，但实际场景中用不到
  3. 升级基础镜像——大部分漏洞通过升级基础镜像就能解决
  4. 实在不行就加白名单——但要有充分的理由和记录
避坑指南：我曾经遇到过一个情况，Trivy扫出来一个openssl的漏洞，但升级基础镜像后应用启动报错。后来发现是应用依赖了旧版本的openssl API。这种情况下，要么改代码适配新版本，要么在安全团队确认风险可控后加白名单。

实战：一个完整的镜像优化案例

最后，咱们看一个完整的优化案例。一个Java Spring Boot应用，从原始到优化：

# 原始版本
FROM openjdk:11
COPY target/app.jar /app.jar
CMD ["java", "-jar", "/app.jar"]

# 优化版本
FROM maven:3.8 AS builder
WORKDIR /build
COPY pom.xml .
RUN mvn dependency:go-offline
COPY src ./src
RUN mvn package -DskipTests

FROM openjdk:11-slim
RUN apt-get update && apt-get install -y --no-install-recommends \
    ca-certificates \
    && rm -rf /var/lib/apt/lists/*
COPY --from=builder /build/target/app.jar /app.jar
EXPOSE 8080
CMD ["java", "-jar", "/app.jar"]

优化后的镜像从原来的800MB降到了200MB，漏洞数量从50多个降到了个位数。嗯，这就是多阶段构建+基础镜像选择+安全扫描的组合拳。

镜像优化不是一锤子买卖。每次更新依赖、升级基础镜像，都要重新审视一遍。养成习惯，你的容器化之路会顺畅很多。

← 上一章 📖 返回目录 下一章 →