无Docker Registry的私有GitLab CI流水线配置求助

嘿，我来帮你理顺这个问题！你现在的核心困扰是学校的GitLab没配私有Docker镜像仓库，但想在CI里用Docker跑构建、测试流水线对吧？你当前的配置已经踩对了Docker-in-Docker（DinD）的路子，但docker login那一步肯定会报错——因为$CI_REGISTRY默认指向GitLab内置的镜像仓库，而你们没搭建它。下面分两种常用场景给你适配的配置方案：

场景1：只需要用Docker环境跑构建、测试，不用推送镜像 #

如果你的流水线只是要在Docker容器里完成代码编译、单元测试这类操作，不需要把自己的镜像推送到仓库，那直接去掉登录步骤，简化配置就行：

# .gitlab-ci.yml
stages:
  - build
  - test

# 抽取出通用的Docker基础配置，方便复用
.docker-base:
  image: docker:latest
  services:
    - docker:dind
  variables:
    # 这些变量是让容器里的Docker客户端能连上DinD的daemon，必须配
    DOCKER_HOST: tcp://docker:2376
    DOCKER_TLS_CERTDIR: "/certs"
    DOCKER_TLS_VERIFY: 1
    DOCKER_CERT_PATH: "$DOCKER_TLS_CERTDIR/client"

build-job:
  extends: .docker-base
  stage: build
  script:
    # 这里替换成你的实际构建命令，比如用Dockerfile构建镜像
    - docker build -t my-app:build .
    # 示例：运行镜像执行前端打包
    - docker run --rm my-app:build npm run build

test-job:
  extends: .docker-base
  stage: test
  script:
    - docker build -t my-app:test .
    # 示例：运行镜像执行单元测试
    - docker run --rm my-app:test npm run test

场景2：需要在不同CI阶段复用构建好的镜像（无仓库替代方案） #

如果你的流水线需要在后续阶段复用之前构建的镜像，但又没有私有仓库，那就用GitLab CI的**工件（artifacts）**来保存镜像归档，跨阶段传递：

stages:
  - build
  - test

.docker-base:
  image: docker:latest
  services:
    - docker:dind
  variables:
    DOCKER_HOST: tcp://docker:2376
    DOCKER_TLS_CERTDIR: "/certs"
    DOCKER_TLS_VERIFY: 1
    DOCKER_CERT_PATH: "$DOCKER_TLS_CERTDIR/client"
    IMAGE_ARCHIVE: my-app-image.tar # 定义镜像归档的文件名

build-job:
  extends: .docker-base
  stage: build
  script:
    - docker build -t my-app:build .
    # 把构建好的镜像导出成归档文件
    - docker save -o $IMAGE_ARCHIVE my-app:build
  artifacts:
    paths:
      - $IMAGE_ARCHIVE
    expire_in: 1 hour # 设定过期时间，避免占太多存储空间

test-job:
  extends: .docker-base
  stage: test
  script:
    # 加载之前导出的镜像归档
    - docker load -i $IMAGE_ARCHIVE
    # 复用镜像执行测试
    - docker run --rm my-app:build npm run test

几个必须注意的点 #

• 删掉before_script里的docker login：因为你们没配私有镜像仓库，这个步骤会直接失败，完全没必要留。
• GitLab Runner要开特权模式：DinD运行需要Runner是Docker executor，并且在它的config.toml里设置privileged = true，不然Docker daemon启动不起来，这是硬要求。
• 环境变量不能少：上面配置里的DOCKER_HOST那些变量是让容器内的Docker客户端能找到DinD的服务端，漏了的话会报“无法连接Docker”的错误。

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