【docker】多阶段构建与基础构建，及企业案例展示
基础构建与多阶段构建对比
基础构建（单阶段构建）
在基础构建中，所有构建过程和最终的应用程序都在同一个镜像中进行，构建工具和最终应用程序都会在最终镜像中。
这样构建镜像时会包含所有的构建工具和依赖，因此最终镜像可能会非常大。
示例：
FROM golang:1.18
WORKDIR /app
# 复制源代码
COPY . .
# 获取依赖并编译 Go 应用
RUN go mod tidy && go build -o myapp .
# 暴露应用端口
EXPOSE 8080
# 启动应用
CMD ["./myapp"]
缺点：
- 最终镜像包含构建工具和依赖，导致镜像体积较大。
- 构建工具和中间文件也被打包在镜像中，增加了潜在的安全风险。
多阶段构建
多阶段构建将构建过程分为多个阶段。构建阶段和运行阶段使用不同的镜像，最终只将构建好的应用和最小的运行时镜像打包到最终镜像中。
示例：
# 第一阶段：编译阶段
FROM golang:1.18 AS builder
WORKDIR /app
# 复制源代码
COPY . .
# 获取依赖并编译 Go 应用
RUN go mod tidy && go build -o myapp .
# 第二阶段：运行阶段
FROM alpine:latest
WORKDIR /root/
# 从第一阶段复制编译好的二进制文件
COPY --from=builder /app/myapp .
# 暴露应用端口
EXPOSE 8080
# 启动应用
CMD ["./myapp"]
优点：
- 最终镜像只有运行时需要的内容，避免了构建工具和临时文件。
- 可以选择更小、更安全的镜像（如
alpine），大大减小了镜像体积。 - 多阶段构建提高了镜像的安全性，因为编译工具仅用于构建阶段，运行时环境不需要这些工具。
基础构建与多阶段构建对比表格
| 特性 | 基础构建 | 多阶段构建 |
|---|---|---|
| 镜像大小 | 较大，包含构建工具和中间文件 | 较小，仅包含编译后的二进制文件和最小运行环境 |
| 构建工具 | 构建工具（如编译器）与运行时文件一起打包到最终镜像中 | 构建工具仅存在于构建阶段，最终镜像不包含它们 |
| 安全性 | 安全性较低，因为镜像包含了编译工具和其他不必要的内容 | 更安全，因为只包含运行应用所需的最小环境 |
| 构建速度 | 较慢，因为构建工具和源文件都要复制到最终镜像中，可能导致镜像冗余 | 更快，构建工具和源文件被分离，只将必要内容复制到最终镜像 |
| 适用场景 | 小型项目或者简单的应用构建，无需考虑镜像体积和安全性 | 复杂应用，特别是需要减小镜像体积、提高安全性的情况 |
| 复杂性 | 较简单，只需一个镜像 | 需要多个阶段和 COPY --from 指令，构建过程稍复杂 |
总结
- 基础构建：适用于简单应用，镜像较大，包含了不必要的构建工具和依赖。
- 多阶段构建：通过分阶段构建，最终镜像更小，安全性更高，适合生产环境。
- 多阶段构建 在生产环境中更常见，能够有效优化镜像体积，提高安全性。
多阶段构建在企业级应用中的常见案例
1. Go 应用构建和部署
在企业级 Go 应用中，通常需要先构建应用，再将其部署到一个更小、更安全的基础镜像中。这种做法减少了不必要的构建依赖，提高了镜像的安全性和运行效率。
示例：
# 第一阶段：构建 Go 应用
FROM golang:1.18 AS builder
WORKDIR /app
# 复制源代码和依赖
COPY . .
# 获取依赖并编译 Go 应用
RUN go mod tidy && go build -o myapp .
# 第二阶段：运行 Go 应用
FROM alpine:latest
WORKDIR /app
# 从构建阶段复制编译好的二进制文件
COPY --from=builder /app/myapp .
EXPOSE 8080
# 启动应用
CMD ["./myapp"]
该案例通过分阶段构建，首先使用 golang 镜像进行编译，然后将编译好的二进制文件复制到更小的 alpine 镜像中，减小了最终镜像的体积，去除了构建工具。
2. Node.js + React 前端应用构建和部署
对于使用 Node.js 构建的前端应用，开发人员通常会先构建应用的生产版本，然后将其部署到一个最小化的静态文件服务器中。例如，使用 nginx 作为静态资源的服务器。
示例：
# 第一阶段：构建 React 前端应用
FROM node:16 AS builder
WORKDIR /app
# 复制源代码
COPY . .
# 安装依赖并构建前端应用
RUN npm install && npm run build
# 第二阶段：使用 Nginx 作为静态文件服务器
FROM nginx:alpine
# 将 React 构建的静态文件复制到 Nginx 中
COPY --from=builder /app/build /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]
该示例首先使用 Node.js 镜像来安装依赖并构建 React 应用，然后将构建好的静态文件复制到更轻量的 nginx 镜像中用于生产部署。这样可以大大减小镜像体积，且避免了将开发依赖暴露在生产环境中。
3. Java Spring Boot 应用构建和部署
对于 Java 后端应用，企业级的开发常常使用 Spring Boot 等框架。多阶段构建可以将构建过程和生产环境分开，最终镜像中只包含应用程序及其运行时依赖，而不包含构建工具或开发依赖。
示例：
# 第一阶段：构建阶段
FROM maven:3.8.4-openjdk-17 AS builder
WORKDIR /app
# 复制项目文件并构建应用
COPY pom.xml .
COPY src ./src
RUN mvn clean install
# 第二阶段：运行阶段
FROM openjdk:17-alpine
WORKDIR /app
# 从构建阶段复制 Jar 包
COPY --from=builder /app/target/myapp.jar /app/
EXPOSE 8080
CMD ["java", "-jar", "myapp.jar"]
这个示例中，我们首先在 maven 镜像中进行构建，然后将构建出来的 Jar 包复制到更小的 openjdk 镜像中进行生产环境部署。最终镜像只包含运行所需的 Java 环境和应用，而没有 Maven 等构建工具。
4. Python Flask 应用构建和部署
Python 应用（如 Flask 框架）通常需要一个构建阶段来安装依赖并准备应用。多阶段构建在这种情况下同样可以有效减小镜像体积。
示例：
# 第一阶段：构建 Python 环境
FROM python:3.9-slim AS builder
WORKDIR /app
# 复制源代码
COPY . .
# 安装依赖
RUN pip install --no-cache-dir -r requirements.txt
# 第二阶段：运行 Python 应用
FROM python:3.9-slim
WORKDIR /app
# 从构建阶段复制安装好的依赖
COPY --from=builder /app /app
EXPOSE 5000
CMD ["python", "app.py"]
在这个示例中，构建阶段将安装所有 Python 依赖并准备应用。然后，将最终应用和依赖复制到更小的基础镜像中，从而减小镜像体积。
总结
在企业级应用中，多阶段构建非常适合于以下情况：
- 需要将构建过程和运行时环境分离，避免将开发工具和中间文件暴露在生产环境中。
- 需要优化镜像体积，减少不必要的构建依赖。
- 需要将构建工具（如 Maven、Node.js、Go 等）与运行时环境（如 JDK、Nginx、Alpine 等）分开，确保最终镜像的安全性和精简性。
通过这些常见案例，企业可以实现更高效、精简、安全的 Docker 镜像构建与部署过程。