Docker多阶段构建（Multi-stage Build）介绍（distroless镜像 / slim基础镜像、slim镜像）（FROM指令的本质）胖镜像瘦镜像、COPY . .、FROM命令

文章目录 多阶段构建与精简基础镜像distroless / slim实践指南 一、为什么需要优化镜像❌ 问题 二、什么是多阶段构建Multi-stage Build✅ 核心思想 示例Go 项目 优势 三、distroless 镜像详解 什么是 distroless distroless 不包含✅ distroless 包含 常见 distroless 镜像 优势⚠️ 缺点 四、slim 镜像详解 什么是 slim✅ 特点 优势⚠️ 缺点⚖️ 五、distroless vs slim 对比 六、推荐组合多阶段 distroless 思路总结 七、安全最佳实践✅ 1. 使用最小权限✅ 2. 明确入口✅ 3. 扫描漏洞✅ 4. 固定版本 八、调试技巧distroless方法 1临时切换 slim方法 2使用 debug 版本方法 3Sidecar 调试 九、适用场景总结 十、总结补充FROM指令的本质多阶段构建的工作机制阶段1构建阶段阶段2运行阶段关键点理解1. **每个FROM都是独立的起点**2. **为什么需要这样**3. **COPY --from的作用**类比理解单阶段构建的对比总结 多阶段构建与精简基础镜像distroless / slim实践指南在容器化逐渐成为基础设施标准的今天如何构建更小、更安全、更高效的镜像已经成为工程团队的重要课题。本文将围绕三个核心点展开什么是多阶段构建Multi-stage Build什么是 distroless / slim 镜像如何在实际项目中结合使用 一、为什么需要优化镜像在默认情况下我们常见的 Dockerfile 可能是这样的FROM golang:1.22 WORKDIR /app COPY . . RUN go build -o app CMD [./app]这种写法存在几个明显问题❌ 问题镜像体积大包含完整编译环境包含无关工具gcc、git 等攻击面大潜在漏洞更多启动速度慢镜像大 这正是多阶段构建和精简镜像要解决的问题。 二、什么是多阶段构建Multi-stage Build多阶段构建是 Docker 提供的一种构建机制 允许在一个 Dockerfile 中使用多个FROM每个阶段只做一件事。✅ 核心思想构建环境 ≠ 运行环境 示例Go 项目# 第一阶段构建 FROM golang:1.22 AS builder WORKDIR /app COPY . . RUN CGO_ENABLED0 GOOSlinux go build -o app # 第二阶段运行 FROM gcr.io/distroless/base WORKDIR /app COPY --frombuilder /app/app . CMD [./app]注COPY . .是 Dockerfile 中的复制指令具体含义如下第一个.表示源路径指的是构建上下文的根目录即包含 Dockerfile 的目录宿主机第二个.表示目标路径指的是当前工作目录由前面的WORKDIR /app指定容器内作用将本地项目目录中的所有文件和子目录除了.dockerignore中排除的文件复制到容器的/app目录中。 优势优势说明镜像更小只包含最终二进制更安全不包含编译工具更清晰构建与运行分离更快部署镜像传输更快 三、distroless 镜像详解 什么是 distrolessdistroless 无发行版no distro由 Google 推出的一类镜像只包含运行应用所需的最小依赖 distroless 不包含shell没有 bash / sh包管理器apt / yum调试工具curl / ps✅ distroless 包含应用运行时依赖glibc 等证书CA certs最小系统库 常见 distroless 镜像镜像用途distroless/base通用基础distroless/static静态编译程序distroless/javaJava 应用distroless/nodejsNode.js 应用 优势 更安全极小攻击面⚡ 更小几十 MB 甚至更小 更快启动⚠️ 缺点无法进入容器调试没有 shell排查问题困难学习成本较高 四、slim 镜像详解相比 distroless“slim” 是一种折中方案。 什么是 slim例如python:3.12-slimnode:20-slim 是官方镜像的“精简版”✅ 特点保留基础操作系统Debian slim去掉文档、缓存、开发工具仍然可以apt install 优势比完整镜像小很多仍然可调试使用门槛低⚠️ 缺点仍然包含 OS → 攻击面较大体积比 distroless 大⚖️ 五、distroless vs slim 对比维度distrolessslim体积⭐ 最小⭐⭐ 较小安全性⭐⭐⭐ 极高⭐⭐ 中等可调试性❌ 几乎没有✅ 支持使用难度较高较低适用场景生产环境开发/测试 六、推荐组合多阶段 distroless 最佳实践# 构建阶段 FROM node:20 AS builder WORKDIR /app COPY package*.json ./ RUN npm install COPY . . RUN npm run build # 运行阶段 FROM gcr.io/distroless/nodejs20 WORKDIR /app COPY --frombuilder /app . CMD [server.js] 思路总结构建阶段用“胖镜像”带工具运行阶段用“瘦镜像”无工具 七、安全最佳实践✅ 1. 使用最小权限USER nonroot✅ 2. 明确入口CMD [./app]避免 shell 形式CMD ./app # ❌✅ 3. 扫描漏洞推荐工具TrivyGrype✅ 4. 固定版本FROM node:20.11.1-slim避免FROM node:latest # ❌ 八、调试技巧distrolessdistroless 最大痛点无法 debug 解决方案方法 1临时切换 slimFROM node:20-slim方法 2使用 debug 版本gcr.io/distroless/base:debug方法 3Sidecar 调试在 Kubernetes 中使用 sidecar 容器。 九、适用场景总结场景推荐CI 构建多阶段生产环境distroless本地开发slim需要调试slim 十、总结多阶段构建 精简镜像是现代容器化的标配✅ 更小✅ 更安全✅ 更快建议逐步演进先引入多阶段构建再切换到slim最终在生产使用distroless补充FROM指令的本质FROM确实是以某个镜像为基础进行构建但在多阶段构建中每个FROM都创建一个独立的构建阶段它们之间是相互隔离的。多阶段构建的工作机制阶段1构建阶段FROM golang:1.22 AS builder ## ← 第1个FROM WORKDIR /app COPY . . RUN CGO_ENABLED0 GOOSlinux go build -o app基于golang:1.22镜像创建一个临时容器在这个容器中编译Go代码生成的app二进制文件存在于这个阶段的文件系统中阶段2运行阶段FROM gcr.io/distroless/base ## ← 第2个FROM WORKDIR /app COPY --frombuilder /app/app . ## ← 从阶段1复制文件 CMD [./app]重新开始基于distroless/base创建一个全新的容器这个阶段不知道阶段1的存在除了通过COPY --from显式复制的文件只包含运行时需要的最小文件关键点理解1.每个FROM都是独立的起点阶段1: golang:1.22 → 编译环境~1GB ↓ 编译出app二进制文件 ↓ 阶段2: distroless/base → 运行环境~10MB ↑ COPY --frombuilder 复制二进制文件2.为什么需要这样构建阶段需要完整的Go工具链编译器、标准库等运行阶段只需要编译好的二进制文件如果只用一个阶段最终镜像会包含整个Go环境浪费空间且不安全3.COPY --from的作用COPY --frombuilder /app/app . ## ↑ ↑ ↑ ## 从阶段1 阶段1的路径 复制到当前阶段类比理解可以把多阶段构建想象成搬家阶段1原房子你在一个大房子里golang:1.22整理所有物品打包好需要的东西阶段2新房子你搬到一个空房子distroless/base只把打包好的必需品搬进来结果新房子很干净没有原房子里的杂物单阶段构建的对比如果只用单阶段FROM golang:1.22 WORKDIR /app COPY . . RUN go build -o app CMD [./app]问题最终镜像包含整个Go环境~1GB而实际只需要一个几MB的二进制文件总结每个FROM创建一个独立的构建上下文阶段之间通过COPY --from阶段名传递文件最终镜像只包含最后一个阶段的内容这就是为什么可以前面以这个为基后面又以另一个为基多阶段构建的本质是用不同的基础镜像完成不同的任务最终只保留需要的结果。