【docker】多阶段构建与基础构建，及企业案例展示

基础构建与多阶段构建对比

基础构建（单阶段构建）

在基础构建中，所有构建过程和最终的应用程序都在同一个镜像中进行，构建工具和最终应用程序都会在最终镜像中。
这样构建镜像时会包含所有的构建工具和依赖，因此最终镜像可能会非常大。

示例：

FROM golang:1.18WORKDIR /app# 复制源代码
COPY . .# 获取依赖并编译 Go 应用
RUN go mod tidy && go build -o myapp .# 暴露应用端口
EXPOSE 8080# 启动应用
CMD ["./myapp"]

缺点：

• 最终镜像包含构建工具和依赖，导致镜像体积较大。
• 构建工具和中间文件也被打包在镜像中，增加了潜在的安全风险。

多阶段构建

多阶段构建将构建过程分为多个阶段。构建阶段和运行阶段使用不同的镜像，最终只将构建好的应用和最小的运行时镜像打包到最终镜像中。

示例：

# 第一阶段：编译阶段
FROM golang:1.18 AS builderWORKDIR /app# 复制源代码
COPY . .# 获取依赖并编译 Go 应用
RUN go mod tidy && go build -o myapp .# 第二阶段：运行阶段
FROM alpine:latestWORKDIR /root/# 从第一阶段复制编译好的二进制文件
COPY --from=builder /app/myapp .# 暴露应用端口
EXPOSE 8080# 启动应用
CMD ["./myapp"]

优点：

• 最终镜像只有运行时需要的内容，避免了构建工具和临时文件。
• 可以选择更小、更安全的镜像（如 alpine），大大减小了镜像体积。
• 多阶段构建提高了镜像的安全性，因为编译工具仅用于构建阶段，运行时环境不需要这些工具。

基础构建与多阶段构建对比表格

特性	基础构建	多阶段构建
镜像大小	较大，包含构建工具和中间文件	较小，仅包含编译后的二进制文件和最小运行环境
构建工具	构建工具（如编译器）与运行时文件一起打包到最终镜像中	构建工具仅存在于构建阶段，最终镜像不包含它们
安全性	安全性较低，因为镜像包含了编译工具和其他不必要的内容	更安全，因为只包含运行应用所需的最小环境
构建速度	较慢，因为构建工具和源文件都要复制到最终镜像中，可能导致镜像冗余	更快，构建工具和源文件被分离，只将必要内容复制到最终镜像
适用场景	小型项目或者简单的应用构建，无需考虑镜像体积和安全性	复杂应用，特别是需要减小镜像体积、提高安全性的情况
复杂性	较简单，只需一个镜像	需要多个阶段和 COPY --from 指令，构建过程稍复杂

总结

• 基础构建：适用于简单应用，镜像较大，包含了不必要的构建工具和依赖。
• 多阶段构建：通过分阶段构建，最终镜像更小，安全性更高，适合生产环境。
• 多阶段构建 在生产环境中更常见，能够有效优化镜像体积，提高安全性。

多阶段构建在企业级应用中的常见案例

1. Go 应用构建和部署

在企业级 Go 应用中，通常需要先构建应用，再将其部署到一个更小、更安全的基础镜像中。这种做法减少了不必要的构建依赖，提高了镜像的安全性和运行效率。

示例：

# 第一阶段：构建 Go 应用
FROM golang:1.18 AS builderWORKDIR /app# 复制源代码和依赖
COPY . .# 获取依赖并编译 Go 应用
RUN go mod tidy && go build -o myapp .# 第二阶段：运行 Go 应用
FROM alpine:latestWORKDIR /app# 从构建阶段复制编译好的二进制文件
COPY --from=builder /app/myapp .EXPOSE 8080# 启动应用
CMD ["./myapp"]

该案例通过分阶段构建，首先使用 golang 镜像进行编译，然后将编译好的二进制文件复制到更小的 alpine 镜像中，减小了最终镜像的体积，去除了构建工具。

2. Node.js + React 前端应用构建和部署

对于使用 Node.js 构建的前端应用，开发人员通常会先构建应用的生产版本，然后将其部署到一个最小化的静态文件服务器中。例如，使用 nginx 作为静态资源的服务器。

示例：

# 第一阶段：构建 React 前端应用
FROM node:16 AS builderWORKDIR /app# 复制源代码
COPY . .# 安装依赖并构建前端应用
RUN npm install && npm run build# 第二阶段：使用 Nginx 作为静态文件服务器
FROM nginx:alpine# 将 React 构建的静态文件复制到 Nginx 中
COPY --from=builder /app/build /usr/share/nginx/htmlEXPOSE 80CMD ["nginx", "-g", "daemon off;"]

该示例首先使用 Node.js 镜像来安装依赖并构建 React 应用，然后将构建好的静态文件复制到更轻量的 nginx 镜像中用于生产部署。这样可以大大减小镜像体积，且避免了将开发依赖暴露在生产环境中。

3. Java Spring Boot 应用构建和部署

对于 Java 后端应用，企业级的开发常常使用 Spring Boot 等框架。多阶段构建可以将构建过程和生产环境分开，最终镜像中只包含应用程序及其运行时依赖，而不包含构建工具或开发依赖。

示例：

# 第一阶段：构建阶段
FROM maven:3.8.4-openjdk-17 AS builderWORKDIR /app# 复制项目文件并构建应用
COPY pom.xml .
COPY src ./src
RUN mvn clean install# 第二阶段：运行阶段
FROM openjdk:17-alpineWORKDIR /app# 从构建阶段复制 Jar 包
COPY --from=builder /app/target/myapp.jar /app/EXPOSE 8080CMD ["java", "-jar", "myapp.jar"]

这个示例中，我们首先在 maven 镜像中进行构建，然后将构建出来的 Jar 包复制到更小的 openjdk 镜像中进行生产环境部署。最终镜像只包含运行所需的 Java 环境和应用，而没有 Maven 等构建工具。

4. Python Flask 应用构建和部署

Python 应用（如 Flask 框架）通常需要一个构建阶段来安装依赖并准备应用。多阶段构建在这种情况下同样可以有效减小镜像体积。

示例：

# 第一阶段：构建 Python 环境
FROM python:3.9-slim AS builderWORKDIR /app# 复制源代码
COPY . .# 安装依赖
RUN pip install --no-cache-dir -r requirements.txt# 第二阶段：运行 Python 应用
FROM python:3.9-slimWORKDIR /app# 从构建阶段复制安装好的依赖
COPY --from=builder /app /appEXPOSE 5000CMD ["python", "app.py"]

在这个示例中，构建阶段将安装所有 Python 依赖并准备应用。然后，将最终应用和依赖复制到更小的基础镜像中，从而减小镜像体积。

总结

在企业级应用中，多阶段构建非常适合于以下情况：

• 需要将构建过程和运行时环境分离，避免将开发工具和中间文件暴露在生产环境中。
• 需要优化镜像体积，减少不必要的构建依赖。
• 需要将构建工具（如 Maven、Node.js、Go 等）与运行时环境（如 JDK、Nginx、Alpine 等）分开，确保最终镜像的安全性和精简性。

通过这些常见案例，企业可以实现更高效、精简、安全的 Docker 镜像构建与部署过程。