Docker 最佳实践：利用多阶段构建优化镜像大小与管理容器日志

在现代软件开发和部署中，Docker 已经成为不可或缺的工具。然而，构建高效、安全且易于管理的 Docker 镜像仍然是一项挑战。本文将深入探讨两项关键的 Dockerfile 最佳实践：多阶段构建 (Multi-Stage Builds) 和 将容器日志重定向到标准输出/错误流，并通过具体示例展示如何在实际生产环境中应用它们。

一、 精简镜像利器：多阶段构建 (Multi-Stage Builds)

1. 面临的挑战

传统的 Dockerfile 构建方式常常导致最终镜像体积臃肿。原因在于：

  • 构建依赖残留: 编译代码（如 Go、Java、C++）或安装前端依赖（如 Node.js 的 node_modules）需要完整的 SDK 或构建工具链。这些工具在运行时完全不需要，但却占据了镜像的大量空间。
  • 中间层文件: 构建过程中产生的临时文件、缓存或不必要的软件包，如果未在同一 RUN 指令层清理，也会增加镜像体积。

2. 解决方案：多阶段构建

多阶段构建允许我们在一个 Dockerfile 中使用多个 FROM 指令。每个 FROM 指令可以开始一个新的构建阶段，并可以为其命名（使用 AS <stage_name>）。关键在于，后续阶段可以利用 COPY --from=<stage_name_or_index> 指令，选择性地从之前的阶段复制所需的文件或构建产物，而完全抛弃前一阶段的其他内容（包括基础镜像、构建工具、源代码等）。

3. 示例 1：理解基本机制

我们先用一个简单的例子来演示多阶段构建的基本语法和文件复制。

  • Dockerfile (/oldboyedu/dockerfile/alpine/10-MultiStageConstruction/Dockerfile)
# Stage 0 (命名为 xixi, 索引为 0)
FROM alpine:3.20.2 AS xixi
# 这个阶段创建了一个 1G 的大文件和一个日志文件
RUN mkdir /oldboyedu-xixi && \
    dd if=/dev/zero of=/oldboyedu-xixi/bigfile.txt count=1024 bs=1M && \
    echo "xixi ~" > /oldboyedu-xixi/xixi.log

# Stage 1 (命名为 haha, 索引为 1)
FROM alpine:3.20.2 AS haha
# 这个阶段创建了一个 2G 的大文件和另一个日志文件
RUN mkdir /oldboyedu-haha && \
    dd if=/dev/zero of=/oldboyedu-haha/bigfile.txt count=2048 bs=1M && \
    echo "haha ~ "> /oldboyedu-haha/haha.log

# Final Stage (最终阶段，未命名，默认使用最后一个 FROM)
FROM alpine:3.20.2
MAINTAINER JasonYin
LABEL school=oldboyedu \
      class=linux92 \
      offic=www.oldboyedu.com

RUN mkdir /oldboyedu-hehe

# 关键：从之前的阶段复制必要的文件
# --from=xixi (或 --from=0) 从名为 'xixi' (索引 0) 的阶段复制
COPY --from=xixi /oldboyedu-xixi/xixi.log /oldboyedu-hehe
# --from=haha (或 --from=1) 从名为 'haha' (索引 1) 的阶段复制
COPY --from=haha /oldboyedu-haha/haha.log /oldboyedu-hehe

ENTRYPOINT ["tail","-f","/etc/hosts"]
  • 构建与分析
cd /oldboyedu/dockerfile/alpine/10-MultiStageConstruction
# 构建脚本 (build.sh)
# #!/bin/bash
# docker image build -t linux92-games:v3.0 .
./build.sh

# 查看镜像大小
docker image ls linux92-games:v3.0
# REPOSITORY      TAG       IMAGE ID       CREATED          SIZE
# linux92-games   v3.0      2b136d66c8fb   About a minute ago   7.8MB

结果分析:
尽管我们在前两个阶段 (xixi 和 haha) 创建了总计 3GB 的大文件 (bigfile.txt)，但最终的 linux92-games:v3.0 镜像大小仅为 7.8MB。这是因为最终阶段只从 xixi 阶段复制了 xixi.log，从 haha 阶段复制了 haha.log。两个大文件以及前两个阶段的基础镜像层和 RUN 指令层都被完全丢弃了。这清晰地展示了多阶段构建隔离构建环境和选择性复制产物的能力。

4. 示例 2：Golang 应用实战

多阶段构建最典型的应用场景之一是编译型语言（如 Go、Java、Rust、C++）。下面以 Golang 为例。

  • 目标: 构建一个包含简单 Go 程序的可执行二进制文件的镜像，同时保持镜像尽可能小，不包含 Go SDK。

  • 准备 Go 源码 (hello.go): (如您原文所示，打印学校信息)

  • 准备 Go SDK: go1.22.5.linux-amd64.tar.gz

  • Dockerfile (/oldboyedu/dockerfile/alpine/11-multiStageGolang/Dockerfile)

# Stage 0: Builder - 编译阶段
# 使用包含 Go SDK 的基础（这里手动添加）或官方 Go 镜像 (e.g., FROM golang:1.22-alpine AS builder)
FROM alpine:3.20.2 AS builder

# 安装 Go SDK (实际生产中更推荐 FROM golang:...)
ADD go1.22.5.linux-amd64.tar.gz /oldboyedu/softwares
RUN ln -svf /oldboyedu/softwares/go/bin/* /usr/local/bin/ && \
    mkdir -p /app/src /app/code # 使用 /app 作为工作目录更常见

# 设置工作目录 (可选但推荐)
WORKDIR /app

# 复制 Go 源码
COPY hello.go /app/code/

# 执行编译
# -o 指定输出路径和文件名
# CGO_ENABLED=0 和 -ldflags '-w -s' 是 Go 编译优化选项，生成静态链接、去除调试信息，减小体积
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-w -s" -o /app/src/hello /app/code/hello.go

# Stage 1: Final - 最终运行阶段
# 使用一个极其精简的基础镜像
FROM alpine:3.20.2

MAINTAINER JasonYin
LABEL auther=JasonYin \
      school=oldboyedu \
      class=linux92 \
      office=www.oldboyedu.com

# 从 builder 阶段复制编译好的二进制文件
# 注意：源路径是 builder 阶段中的路径，目标路径是当前阶段的路径
COPY --from=builder /app/src/hello /usr/local/bin/hello # 放到 $PATH 中方便执行

# 设置工作目录（如果需要）
# WORKDIR /app

# 定义容器启动时执行的命令
# CMD ["/usr/local/bin/hello"] # 直接运行程序
ENTRYPOINT ["/usr/local/bin/hello"] # 或者使用 ENTRYPOINT

# 如果只是想保持容器运行用于检查，可以用 tail
# CMD ["tail","-f","/etc/hosts"]
  • 构建与对比
cd /oldboyedu/dockerfile/alpine/11-multiStageGolang

# 构建包含 Go SDK 的单阶段镜像 (假设这是 v3.1 的 Dockerfile)
# docker image build -t linux92-games:v3.1 . # (假设 v3.1 是单阶段构建)
# docker image ls linux92-games:v3.1
# REPOSITORY      TAG       IMAGE ID       CREATED          SIZE
# linux92-games   v3.1      3fc7030d0665   ...              230MB (包含 Go SDK 的大小)

# 构建多阶段镜像 (v3.2)
# 构建脚本 (build.sh)
# #!/bin/bash
# docker image build -t linux92-games:v3.2 .
# ... (其他命令)
./build.sh

# 查看多阶段构建后的镜像大小
docker image ls linux92-games:v3.2
# REPOSITORY      TAG       IMAGE ID       CREATED         SIZE
# linux92-games   v3.2      6085282e9e9b   ...             9.71MB (仅包含 Alpine 和 Go 二进制程序)

# 验证运行
docker run --rm linux92-games:v3.2
# 输出：老男孩的公司官网是https://www.oldboyedu.com

结果分析:
对比惊人！包含完整 Go SDK 的（假想的）单阶段镜像 v3.1 体积高达 230MB，而使用多阶段构建的 v3.2 镜像仅有 9.71MB。最终镜像只包含了轻量的 Alpine Linux 基础和几 MB 大小的 Go 可执行程序，没有任何编译工具的痕迹。这极大地减少了镜像体积，提高了传输效率，并减小了潜在的安全攻击面。

多阶段构建小结:

  • 使用 FROM ... AS <name> 定义和命名阶段。
  • 使用 COPY --from=<name_or_index> <source> <destination> 从先前阶段复制必要产物。
  • 最终镜像只包含最后一个 FROM 指令及之后的操作，以及通过 COPY --from 显式复制过来的文件。
  • 极大地优化编译型语言或需要复杂构建环境的应用镜像大小。

二、 拥抱标准：将容器日志输出到 stdout/stderr

1. 传统日志管理的困境

许多传统应用（如 Nginx, Apache, Tomcat）默认将访问日志和错误日志记录到容器内的特定文件中。这种方式存在几个问题：

  • 不易收集: 需要进入容器内部或通过 docker cp 才能查看日志文件。
  • 与 Docker 生态脱节: 无法直接使用 docker logs 命令查看实时日志。
  • 日志驱动 (Logging Drivers) 失效: Docker 提供的日志驱动（如 json-file, journald, fluentd, splunk 等）依赖于容器的标准输出 (stdout) 和标准错误 (stderr) 流来收集日志。写入文件的日志无法被这些驱动捕获。

2. 解决方案：重定向到标准流

最佳实践是配置应用直接将日志输出到 stdout 和 stderr。如果应用不支持直接配置，一个简单有效的技巧是在 Dockerfile 中将应用默认的日志文件路径符号链接 (symlink) 到 /dev/stdout 和 /dev/stderr。这两个是 Linux 系统中的特殊设备文件，写入它们的数据会分别成为进程的标准输出和标准错误。

3. 示例：Nginx 日志重定向

  • Dockerfile (/oldboyedu/dockerfile/alpine/12-xiaobawang-log/Dockerfile)
FROM alpine:3.20.2

MAINTAINER JasonYin y1053419035@qq.com www.oldboyedu.com xixi haha
LABEL school=oldboyedu class=linux92 auther=JasonYin email=y1053419035@qq.com office=www.oldboyedu.com
WORKDIR /usr/share/nginx/html
VOLUME /usr/share/nginx/html

RUN sed -i 's/dl-cdn.alpinelinux.org/mirrors.tuna.tsinghua.edu.cn/g' /etc/apk/repositories && \
     apk update && \
     apk add nginx openssh-server curl && \
     sed -i 's@#PermitRootLogin prohibit-password@PermitRootLogin yes@' /etc/ssh/sshd_config && \
     ssh-keygen -A && \
     rm -rf /var/cache/apk/* /usr/share/nginx/html/* && \
     # === 日志重定向关键步骤 ===
     # 将 Nginx 默认错误日志路径链接到标准错误流
     ln -svf /dev/stderr /var/log/nginx/error.log && \
     # 将 Nginx 默认访问日志路径链接到标准输出流
     ln -svf /dev/stdout /var/log/nginx/access.log

EXPOSE 80 22

ADD oldboyedu-xiaobawang.tar.gz /usr/share/nginx/html/xiaobawang
COPY games.conf /etc/nginx/http.d/default.conf
COPY start.sh /

# 注意：start.sh 中的 nginx 命令最好使用 nginx -g 'daemon off;' 让 Nginx 在前台运行，
# 这样 Nginx 的主进程就是容器的主进程，其 stdout/stderr 才会被 Docker 正确捕获。
# 如果用后台模式启动 Nginx，再用 tail -f 保持容器运行，日志也能通过链接输出，
# 但更推荐前台运行服务。
ENTRYPOINT ["/bin/sh","-x","/start.sh"]

  • 启动脚本 (start.sh): (如您原文所示，启动 sshd 和 nginx，然后 tail -f)

  • 构建与运行

cd /oldboyedu/dockerfile/alpine/12-xiaobawang-log
# 构建脚本 (build.sh)
# #!/bin/bash
# docker image build -t linux92-games:v3.3 .
# docker container rm -f `docker container ps -qa` 2>/dev/null
# docker run -dP --name games linux92-games:v3.3
# docker ps -l
./build.sh

# 查看容器日志
# -f 参数可以持续跟踪日志输出
docker logs -f games

结果分析:
当容器 games 运行时，Nginx 产生的任何访问日志（通常是 info 级别）会因为 ln -svf /dev/stdout /var/log/nginx/access.log 而被重定向到容器的标准输出流。同样，错误日志会通过 ln -svf /dev/stderr /var/log/nginx/error.log 被重定向到标准错误流。

现在，我们可以直接使用 docker logs games 命令来查看 Nginx 的所有日志输出，就像应用原生支持将日志打印到控制台一样。这也使得 Docker 的日志驱动能够正常工作，方便将日志集中收集到外部系统（如 ELK Stack, Graylog, Splunk 等）。

日志重定向小结:

  • 将应用日志文件链接到 /dev/stdout (用于访问/普通日志) 和 /dev/stderr (用于错误日志)。
  • 使得 docker logs 命令可以查看应用日志。
  • 兼容 Docker 日志驱动，便于集中式日志管理。
  • 推荐让容器内的主要服务在前台运行 (e.g., nginx -g 'daemon off;') 以获得最佳实践效果。

总结

本文介绍了 Docker 中两个非常实用的高级特性：

  1. 多阶段构建: 通过在单个 Dockerfile 中定义多个构建阶段，并选择性地复制最终产物，可以显著减小生产镜像的体积，移除不必要的构建依赖，提高安全性和部署效率。尤其适用于编译型语言和需要复杂构建环境的应用。
  2. 日志重定向: 通过将应用日志文件符号链接到 /dev/stdout 和 /dev/stderr，可以将容器内应用的日志无缝集成到 Docker 的标准日志管理体系中，方便使用 docker logs 查看，并利用日志驱动进行集中收集和分析。

掌握并应用这些技术，将帮助您构建更专业、更健壮、更易于管理的 Docker 化应用程序。希望这些实践能为您的 DevOps 工作流程带来实质性的改进！

posted on 2025-04-11 09:53  Leo-Yide  阅读(109)  评论(0)    收藏  举报

博客园  ©  2004-2025
浙公网安备 33010602011771号 浙ICP备2021040463号-3