如何在Docker化GitLab CI中实现构建部署两阶段的容器复用

核心机制结论 #

GitLab Runner 从底层设计上就不支持跨独立 Job 复用同一运行容器实例，不存在把build阶段启动好的容器上下文直接传递给deploy阶段使用的原生实现路径。
所有匹配ruby-3.0标签的Runner，在接收到Job任务时都会执行完整的独立生命周期：拉起全新隔离容器 → 拉取代码仓库 → 执行对应脚本 → Job结束后直接销毁容器的全部文件系统与进程状态。哪怕两个Job绑定到同一个Runner节点，Runner也不会复用上一次Job残留的容器实例，每次执行的上下文都是从零初始化的。

适配当前拆分需求的标准实现方案 #

你拆分build、deploy两个Job的核心诉求，完全可以用GitLab原生的artifacts机制落地，不需要改动原有部署逻辑，稳定性远高于硬追求容器复用的思路：

• 仅需在build Job中添加artifacts配置，将构建产出的build/目录声明为流水线产物，Runner会在build执行完成后自动打包该目录上传到GitLab服务端，后续启动的deploy Job会自动将产物包下载解压到标准的$CI_PROJECT_DIR路径下。
• 你原有deploy脚本里的cp -pr $CI_PROJECT_DIR/build/* next逻辑完全不需要修改即可正常运行。
• 原有全局配置里的_vendor目录缓存可以保留，两个Job执行时都会自动拉取缓存的Ruby依赖，不需要重复执行gem安装操作。

调整后的build Job关键配置示例：

build:
  stage: build
  tags:
    - ruby-3.0
  only:
    - master
  script:
    - apk update
    - apk add build-base nodejs git
    - command -v bundler || { gem install bundler; }
    - bundle config set --local path '_vendor/'
    - bundle install
    - MM_ENV=production bundle exec middleman build
  artifacts:
    paths:
      - build/
    expire_in: 1h

不推荐的绕行思路 #

不要为了追求“两个Job共用一个容器”去修改Runner配置、自定义容器挂载逻辑、硬编码复用容器名称，这类自定义实现会带来大量稳定性隐患：比如并行流水线执行时容器数据串流、Job执行失败后容器残留占用宿主机资源、Runner重启后状态丢失导致流程异常。
实际上拆分Job的核心价值本来就是解耦两个阶段的生命周期：build失败时不会误触发部署流程、两个阶段可以独立配置权限与执行资源、可以单独优化单阶段的执行效率。如果硬把两个Job绑定到同一个容器执行，反而彻底失去了拆分Job的实际意义，和你现在能跑通的单Job模式没有本质区别。

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