多阶段构建

背景与问题界定 某金融科技团队的 Java 微服务镜像体积达到了 1.8GB，每次部署拉取镜像耗时超过 3 分钟，开发环境日均有 40GB 的镜像存储增长。更严重的是，第三方安全扫描发现基础镜像中包含了超过 200 个高危 CVE 漏洞，大量不必要工具包遗留在生产镜像中。Docker 镜像既是应用的交付载体，也是攻击面的暴露入口——过大的镜像导致部署缓慢、带宽浪费，遗留的构建工具链和调试脚本成为安全审计中的重大隐患。治理目标是在保证运行时功能完整的前提下，将镜像体积缩小 80% 以上，同时消除所有高危漏洞。 目标拆解与工程约束 镜像体积控制：构建产物镜像必须只包含运行时所需的最小依赖集合，任何编译工具、调试器、包管理器和文档文件都不得出现在最终镜像中，目标是将单个服务镜像压缩到 150MB 以内。 漏洞清零策略：必须扫描基础镜像和每一层引入的第三方依赖，高危漏洞（CVSS >= 7.0）必须阻断 CI 构建流程，不允许带有已知高危漏洞的镜像推送到生产仓库。 构建性能与缓存：多阶段构建需要在保持镜像精简的同时，利用 Docker BuildKit 的缓存机制加速构建，全量构建不应超过 5 分钟，增量构建控制在 30 秒以内。 可追溯性与合规：每个镜像必须通过 OCI 标准的 SBOM（Software Bill of Materials）记录所有依赖组件的来源和版本，满足金融合规审计的供应链安全要求。 方案设计 首先引入多阶段构建（Multi-stage Build），将构建环境和运行环境彻底分离。以 Java 服务为例，第一阶段使用 maven:3.9-eclipse-temurin-17 作为构建镜像，编译打包生成 fat JAR；第二阶段使用 eclipse-temurin:17-jre-alpine 作为运行时镜像，仅将构建产物的 JAR 文件拷贝进来，构建镜像的 Maven 缓存、JDK 工具链和 .class 中间文件全部丢弃。通过这种方式，Java 服务镜像从 1.8GB 骤降至 120MB。 第二层优化是基础镜像的最小化选型。我们放弃通用镜像，采用分层的镜像裁剪策略：Alpine 变体作为默认选择（< 5MB），对于需要 glibc 兼容性的应用退回到 Distroless（Google 维护的静态镜像），对于 Go 编译的二进制应用直接使用 scratch 空镜像。同时在 Dockerfile 中通过 RUN --mount=type=cache 挂载包管理器缓存，避免每次构建都重新下载 APT/NPM 包。 ...