GitLab中不推送至Docker Hub，跨阶段复用单阶段构建的Docker镜像可行吗？

这个方案直接用是行不通的，原因很简单：GitLab CI的每个job（也就是你这里的build、deploy阶段）默认是在独立的执行环境里运行的——要么是runner启动的全新容器，要么是独立的虚拟机。你在build阶段构建的myimage只存在于该job专属的Docker环境中，deploy阶段的job完全访问不到这个本地镜像。

不过不用慌，有几个不需要推送到Docker Hub的替代方案可以实现你的需求：

方案1：使用GitLab项目内置容器注册表（最推荐） #

GitLab每个项目都自带了私有容器注册表，完全不需要依赖Docker Hub，而且只有你的项目有权限访问，安全又可靠。修改你的流水线配置如下：

stages:
  - build
  - deploy
build:
  stage: build
  image: docker:latest
  services:
    - docker:dind
  variables:
    # 用GitLab预定义变量生成唯一镜像名
    IMAGE_NAME: $CI_REGISTRY_IMAGE/myimage:$CI_COMMIT_SHORT_SHA
  script:
    # 自动登录到项目内置注册表
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker build -t $IMAGE_NAME .
    - docker push $IMAGE_NAME
deploy:
  stage: deploy
  # 直接引用刚推送的私有镜像
  image: $IMAGE_NAME
  script:
    - echo "it works"

这里的$CI_REGISTRY_IMAGE、$CI_REGISTRY_USER等都是GitLab自动提供的预定义变量，不需要你手动配置，直接用就行。

方案2：使用专属单节点Runner的本地Docker环境（仅适合测试场景） #

如果你的项目用的是专属的单节点Runner（也就是这个Runner只跑你这一个项目的job），可以配置Runner共享主机的Docker daemon：

1. 修改Runner的配置文件，在volumes里添加/var/run/docker.sock:/var/run/docker.sock，让job直接使用Runner主机的Docker环境。
2. 这样build阶段构建的镜像会保存在Runner主机的Docker里，deploy阶段就能直接引用myimage了。

⚠️ 注意：这个方案只适合测试场景，共享Runner绝对不能这么配置（会导致不同项目的镜像互相干扰），而且如果Runner重启或者清理了本地镜像，流水线就会失败，可靠性很差。

方案3：用Artifacts传递镜像文件（无依赖但效率低） #

可以把build阶段构建的镜像导出为tar文件，通过GitLab的Artifacts功能传递给deploy阶段，然后再加载使用：

stages:
  - build
  - deploy
build:
  stage: build
  image: docker:latest
  services:
    - docker:dind
  script:
    - docker build -t myimage .
    # 把镜像导出为tar文件
    - docker save myimage -o myimage.tar
  artifacts:
    paths:
      - myimage.tar
    expire_in: 1h # 按需设置过期时间，避免占用存储空间
deploy:
  stage: deploy
  image: docker:latest
  services:
    - docker:dind
  script:
    # 加载tar文件为镜像
    - docker load -i myimage.tar
    # 运行镜像里的命令
    - docker run myimage echo "it works"

这个方案不需要任何外部或内置注册表，但镜像tar文件通常体积较大，会拖慢流水线速度，而且deploy阶段不能直接用image: myimage，得通过docker run来执行命令，灵活性稍差。

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