使用Microsoft.NET.Build.Containers在GitLab CI/CD构建镜像失败求助

你猜的没错！问题核心就是GitLab CI的Docker执行器默认环境里没有Docker客户端，也没法访问Docker守护进程。

Microsoft.NET.Build.Containers这个包本质上是在dotnet publish过程中调用了本地的docker命令来构建镜像，本地机器上你装了Docker Desktop/Engine，所以能正常运行；但GitLab CI用Docker执行器时，你的构建任务是跑在一个隔离的Docker容器里的，这个容器默认没装Docker客户端，也连不上Docker daemon，自然就会报"No such file or directory"的错误。

至于GitHub Actions能正常跑，是因为GitHub的托管Runner是基于虚拟机的，默认就预装了完整的Docker环境，直接就能调用docker命令。

下面给你两种常用的解决办法，按需选择：

方法1：使用Docker-in-Docker（DinD）服务 #

这是GitLab CI里最常用的方式，通过启动一个DinD服务容器来提供Docker daemon，同时在你的构建容器里安装Docker客户端，让dotnet publish能调用到docker命令。

修改你的.gitlab-ci.yml如下：

image: mcr.microsoft.com/dotnet/sdk:7.0

# 启动DinD服务，提供Docker daemon
services:
  - docker:dind

stages:
  - publish

build-job:
  stage: publish
  variables:
    # 告诉Docker客户端连接到DinD服务的地址
    DOCKER_HOST: tcp://docker:2375
    # 禁用TLS（DinD默认开启，但我们这里简化配置）
    DOCKER_TLS_CERTDIR: ""
  script:
    # 安装Docker客户端（因为dotnet sdk镜像默认没有）
    - apt-get update && apt-get install -y --no-install-recommends docker.io
    # 执行发布命令
    - dotnet publish --os linux --arch x64 --configuration Release -p:PublishProfile=DefaultContainer

方法2：挂载宿主机的Docker Socket #

如果你有权限配置GitLab Runner，可以直接把宿主机的Docker Socket挂载到构建容器里，这样构建容器里的docker命令会直接调用宿主机的Docker daemon，不需要额外启动DinD服务。

步骤1：修改GitLab Runner配置 #

找到Runner的config.toml文件（通常在/etc/gitlab-runner/目录下），在[runners.docker]段添加volume配置：

[[runners]]
  name = "你的Runner名称"
  url = "你的GitLab实例地址"
  token = "你的Runner令牌"
  executor = "docker"
  [runners.docker]
    image = "mcr.microsoft.com/dotnet/sdk:7.0"
    # 添加这一行，挂载宿主机的Docker Socket
    volumes = ["/var/run/docker.sock:/var/run/docker.sock", "/cache"]
    # 其他配置保持不变...

步骤2：简化CI配置 #

修改后的.gitlab-ci.yml可以去掉services和相关变量：

image: mcr.microsoft.com/dotnet/sdk:7.0

stages:
  - publish

build-job:
  stage: publish
  script:
    # 同样需要安装Docker客户端，除非你用带Docker的镜像
    - apt-get update && apt-get install -y --no-install-recommends docker.io
    - dotnet publish --os linux --arch x64 --configuration Release -p:PublishProfile=DefaultContainer

注意：这种方法有一定安全风险，因为构建容器可以直接操作宿主机的Docker，所以只适合信任的项目使用。

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