GitLab CI构建的Docker镜像存储位置及Trivy扫描卡住问题咨询

镜像存储位置说明 #

你当前配置下，构建的testdock:latest（对应$CI_REGISTRY_IMAGE:latest）仅临时存储在build任务启动的专属DinD（Docker-in-Docker）服务容器的本地存储中，该存储会随build任务结束被销毁，不会持久化留存，也无法被其他CI任务访问。

扫描卡住原因 #

1. security_scan任务启动的是全新的独立DinD实例，无法访问build阶段DinD里的本地镜像。
2. 你注释掉了build阶段的镜像推送逻辑，镜像没有被上传到$CI_REGISTRY对应的GitLab私有镜像仓库，Trivy拉取镜像时找不到资源，会无限重试导致流程卡住。
3. 如果你直接使用testdock:latest标签扫描，Trivy会默认先查找本地DinD的镜像，找不到就会去公网Docker Hub拉取对应镜像，拉取不到也会卡住。

修复方案 #

方案1：推送镜像到私有仓库后扫描（推荐）

修改build阶段的执行逻辑，把构建好的镜像推送到GitLab私有镜像仓库，后续Trivy直接从仓库拉取镜像扫描：

build:
  script:
    # 同时打commit sha和latest两个标签
    - docker build -t $FULL_IMAGE_NAME -t $CI_REGISTRY_IMAGE:latest .
    # 取消推送注释，上传两个标签的镜像到仓库
    - docker push $FULL_IMAGE_NAME
    - docker push $CI_REGISTRY_IMAGE:latest

你已经在security_scan阶段配置了TRIVY_USERNAME、TRIVY_PASSWORD等认证参数，Trivy可以正常拉取私有仓库的镜像。

方案2：跨任务传递镜像包（无需推送）

如果不想把临时构建的镜像推送到仓库，可以把镜像导出为tar包作为制品传递：

1. 在build阶段新增镜像导出逻辑，保存为制品：

build:
  script:
    - docker build -t $FULL_IMAGE_NAME .
    - docker save $FULL_IMAGE_NAME -o image.tar
  artifacts:
    paths:
      - image.tar
    expire_in: 1h # 可按需调整制品保留时间

2. 在security_scan阶段的before_script中导入镜像：

security_scan:
  before_script:
    # 保留原有逻辑，新增镜像导入命令
    - docker load -i image.tar

3. 扫描时直接指定本地镜像即可，无需从仓库拉取，执行速度更快。

排查优化建议 #

如果修改后流程仍然卡住，可以在Trivy命令后添加--debug参数，输出详细执行日志定位卡顿节点。另外security_scan阶段的代码克隆逻辑可以删除，设置GIT_STRATEGY: none即可减少不必要的耗时。

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