Docker Build-Push Action 中构建多阶段镜像时的本地镜像访问问题解析

问题背景

在使用 Docker Build-Push Action 构建多阶段 Docker 镜像时，开发者经常会遇到一个典型问题：在第一个构建任务中生成的本地基础镜像，无法在后续构建任务中被正确识别和使用。具体表现为后续构建步骤仍然尝试从远程仓库拉取镜像，而不是使用已经加载到本地的镜像。

问题根源分析

这个问题的根本原因在于 Docker Buildx 的工作机制。当使用 docker/setup-buildx-action 时，默认会创建一个容器化的构建器（container builder），这种构建器运行在独立的容器环境中，与主机的 Docker 守护进程隔离。因此，即使通过 docker load 命令将镜像加载到了主机 Docker 存储中，容器化的构建器也无法直接访问这些镜像。

解决方案

方案一：使用 Docker 驱动替代容器驱动

最直接的解决方案是修改 docker/setup-buildx-action 的配置，指定使用 Docker 驱动而非默认的容器驱动：

- uses: docker/setup-buildx-action@v3
  with:
    driver: docker

这种方式的优点是简单直接，不需要额外的配置。缺点是放弃了容器化构建器的一些高级功能，如多平台构建和缓存导出等。

方案二：使用本地镜像仓库

对于需要保留容器化构建器高级功能的场景，可以设置本地镜像仓库作为中介：

1. 首先在 workflow 中启动本地 registry 服务：

services:
  registry:
    image: registry:2
    ports:
      - 5000:5000

2. 加载基础镜像后推送到本地 registry：

- name: Load base Docker image and push to local registry
  run: |
    docker load --input /tmp/${{ env.BASE_DOCKER_IMAGE }}.tar
    docker tag ${{ env.BASE_DOCKER_IMAGE }} localhost:5000/foo/bar:latest
    docker push localhost:5000/foo/bar:latest

3. 修改 Dockerfile 使用 ARG 参数指定基础镜像：

ARG BASE_IMAGE=dmca-base:latest
FROM $BASE_IMAGE

4. 在构建时传递基础镜像参数：

build-args: |
  BASE_IMAGE=localhost:5000/foo/bar:latest

最佳实践建议

1. 简单场景优先使用 Docker 驱动：如果不需要多平台构建等高级功能，使用 Docker 驱动是最简单可靠的解决方案。

2. 合理规划镜像构建流程：对于复杂的多阶段构建，考虑将基础镜像推送到可访问的镜像仓库，而不是依赖本地传递。

3. 明确镜像来源：在 Dockerfile 中使用 ARG 参数指定基础镜像，提高构建流程的灵活性。

4. 考虑构建缓存：对于频繁构建的场景，评估是否需要保留容器化构建器的缓存功能。

总结

理解 Docker Buildx 不同构建驱动的工作机制是解决这类问题的关键。通过合理选择构建驱动或设置本地镜像仓库，可以确保多阶段构建流程中基础镜像的正确传递和使用。在实际应用中，应根据项目需求和构建复杂度选择最适合的解决方案。