如何获取GitLab pipeline失败作业的Docker镜像用于本地调试

GitLab CI 默认在 Job 执行结束（无论成功/失败）后立即删除运行用的 Docker 容器，不会自动留存对应镜像，你可以通过以下几种方式拿到现场环境做本地分析：

• 方案1：通过 Artifact 直接导出构建中间文件（最省事，不需要操作Runner）
  如果你只需要查看构建过程生成的文件，不需要完整容器环境，直接给出问题的 Job 加上失败也上传产物的配置即可：

  <你的失败Job名>:
    image: <原Job用的基础镜像>
    script:
      - # 原有构建脚本保持不变
    artifacts:
      when: always # 无论Job成功失败都上传产物
      paths:
        - <你要排查的目录路径> # 比如./build、./dist，要全量排查就填./ 传整个工作目录
      expire_in: 3 days # 产物保留时间，够排查就行
  

  重新触发Pipeline，等Job执行完（哪怕失败），直接去Job详情页的Artifacts栏就能下载所有构建生成的文件，本地解压即可查看。
• 方案2：临时挂起Job，手动将运行中的容器提交为本地镜像
  如果你需要完整的容器环境（比如排查依赖版本、环境变量、系统级配置问题），可以临时修改Job脚本，在构建命令后加等待逻辑卡住Job：

  <你的失败Job名>:
    image: <原Job用的基础镜像>
    script:
      - # 原有构建脚本保持不变
      - sleep 7200 # 卡住2小时，预留足够操作时间
    # 记得临时注释掉after_script里的文件清理、环境重置类命令，避免现场被破坏
  

  重新触发Pipeline，等Job跑到sleep步骤卡住时：
  1. 登录该Job绑定的GitLab Runner所在的服务器
  2. 执行docker ps找到对应Job的运行中容器ID（容器名一般会带Job ID、项目名特征）
  3. 执行docker commit <容器ID> debug-pipeline:v1 把当前容器存为本地镜像
  4. 后续直接执行docker run -it debug-pipeline:v1 bash就能进入和失败现场完全一致的容器环境排查
• 方案3：直接复用Runner本地残留的已退出容器
  如果你用的是自己注册的私有Runner，且没有修改默认的清理策略，Job结束后容器不会被立刻删除（默认保留24小时），你可以直接登录Runner服务器：
  1. 执行docker ps -a 找到对应Job的已退出容器（状态为Exited，命名带Job特征）
  2. 执行docker start <容器ID>启动容器
  3. 执行docker exec -it <容器ID> bash直接进入容器排查，不需要额外提交镜像

排查提示：绝大多数本地无法复现的Pipeline故障，都是因为本地环境和CI环境的基础镜像版本、环境变量、执行用户三者不一致导致的，排查时可以先在失败Job的script最开头加env && id && cat /etc/os-release命令打印CI环境信息，和本地做对齐。

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