Dockerfile多阶段构建复用基础镜像的参数优化方案问询

问题背景 #

我有一个多阶段构建的Dockerfile，用于在多个子目录执行命令生成幻灯片，但存在大量代码冗余。原Dockerfile每个build-*阶段都重复相同的COPY和RUN逻辑。尝试用ARG参数复用build-base镜像时，$SLIDE_NAME始终为空字符串，而原方案的层缓存效果很好，现在需要找到减少冗余的方法。

原Dockerfile示例 #

FROM node:22 AS build-base
COPY package*.json ./
RUN npm i
RUN ...

FROM build-base AS build-A
ENV SLIDE_NAME="A"
COPY ./slides/$SLIDE_NAME .
RUN npx command on folder/$SLIDE_NAME/ & \
  other command using $SLIDE_NAME

FROM build-base AS build-B
ENV SLIDE_NAME="B"
COPY ./slides/$SLIDE_NAME .
RUN npx command on folder/$SLIDE_NAME/ & \
  other command using $SLIDE_NAME

FROM build-base AS build-C
...

FROM nginx:1.27.0-alpine
RUN rm -r /usr/share/nginx/html/*

COPY --from=build-A /build/build/ /usr/share/nginx/html
COPY --from=build-B /build/build/ /usr/share/nginx/html
COPY --from=build-C /build/build/ /usr/share/nginx/html

尝试的ARG方案（失败） #

FROM node:22 AS build-base
COPY package*.json ./
RUN npm i
RUN ...
ARG SLIDE_NAME
COPY ./slides/$SLIDE_NAME .
RUN npx command on folder/$SLIDE_NAME/ & \
  other command using $SLIDE_NAME

FROM build-base AS build-A
ARG SLIDE_NAME="A"

FROM build-base AS build-B
ARG SLIDE_NAME="B"

...

失败原因分析 #

ARG的作用域仅限于当前构建阶段：在build-base里定义的ARG SLIDE_NAME，是构建build-base镜像时需要传入的参数，后续build-A阶段的ARG SLIDE_NAME="A"不会回溯修改build-base阶段的参数值。因此构建build-base时$SLIDE_NAME为空，导致COPY和RUN命令执行失败。

可行优化方案 #

方案1：子阶段复用公共逻辑（保留层缓存） #

把公共构建逻辑抽成模板阶段，子阶段仅传递参数，既减少冗余又保留原有的层缓存优势：

FROM node:22 AS build-base
COPY package*.json ./
RUN npm i
RUN ...

# 定义公共构建模板
FROM build-base AS build-template
ARG SLIDE_NAME
COPY ./slides/${SLIDE_NAME} .
RUN npx command on folder/${SLIDE_NAME}/ & \
  other command using ${SLIDE_NAME}

# 复用模板，传递不同参数
FROM build-template AS build-A
ARG SLIDE_NAME="A"

FROM build-template AS build-B
ARG SLIDE_NAME="B"

FROM build-template AS build-C
ARG SLIDE_NAME="C"

# 最终镜像构建逻辑不变
FROM nginx:1.27.0-alpine
RUN rm -r /usr/share/nginx/html/*

COPY --from=build-A /build/build/ /usr/share/nginx/html
COPY --from=build-B /build/build/ /usr/share/nginx/html
COPY --from=build-C /build/build/ /usr/share/nginx/html

• 优势：build-base的依赖安装层完全缓存，公共逻辑仅写一次，单个幻灯片目录修改时仅重新构建对应阶段。

方案2：用Makefile批量管理构建 #

若幻灯片数量较多，可通过Makefile封装构建逻辑，简化Dockerfile的同时支持批量/并行构建：

简化后的Dockerfile

FROM node:22 AS build-base
COPY package*.json ./
RUN npm i
RUN ...

FROM build-base AS builder
ARG SLIDE_NAME
COPY ./slides/${SLIDE_NAME} .
RUN npx command on folder/${SLIDE_NAME}/ & \
  other command using ${SLIDE_NAME}

FROM nginx:1.27.0-alpine AS final
RUN rm -r /usr/share/nginx/html/*

对应的Makefile

SLIDES := A B C
BUILD_TARGETS := $(addprefix build-,$(SLIDES))

.PHONY: all $(BUILD_TARGETS) final

all: final

$(BUILD_TARGETS): build-%:
	docker build --target builder --build-arg SLIDE_NAME=$* -t slide-$* .

final: $(BUILD_TARGETS)
	docker create --name temp-nginx nginx:1.27.0-alpine
	$(foreach slide,$(SLIDES),docker cp slide-$(slide):/build/build/ temp-nginx/usr/share/nginx/html/;)
	docker commit temp-nginx my-slides-nginx
	docker rm temp-nginx

• 优势：Dockerfile极度简洁，新增幻灯片只需修改SLIDES变量，支持make -j并行构建提升速度。

方案3：Docker BuildKit批量构建（Docker 19.03+） #

开启BuildKit后，使用docker buildx bake批量构建多个目标，适合复杂构建场景：

docker-bake.hcl配置文件

group "default" {
  targets = ["final"]
}

target "build-base" {
  dockerfile = "Dockerfile"
  target = "build-base"
}

target "builder" {
  inherits = ["build-base"]
  args = {
    SLIDE_NAME = "${TARGET_NAME}"
  }
}

target "A" {
  inherits = ["builder"]
}

target "B" {
  inherits = ["builder"]
}

target "final" {
  dockerfile = "Dockerfile"
  target = "final"
  copy = [
    { from = "A", source = "/build/build/", dest = "/usr/share/nginx/html/" },
    { from = "B", source = "/build/build/", dest = "/usr/share/nginx/html/" }
  ]
}

执行构建命令

DOCKER_BUILDKIT=1 docker buildx bake

• 优势：支持跨平台构建，构建流程可配置化，适合大规模项目。

内容的提问来源于stack exchange，提问作者johannchopin