Docker执行器GitLab Runner构建镜像磁盘不足，配新盘路径仍报空间不足

你对该配置项的作用存在认知偏差：

• builds_dir 仅控制GitLab Runner拉取源码、存储CI流程临时工作文件（如检出的代码、流水线脚本临时输出）的存储路径
• 日志中出现的Initialized empty Git repository in /run/media/<user>/STORAGE/builds/...提示，已经证明你设置的builds_dir配置完全生效，Runner已经把代码拉取环节迁移到了新磁盘
• 该配置项完全不关联Docker引擎的存储行为，无法管控docker build命令执行过程中产生的镜像层、构建缓存、容器可写层的存储位置——这就是你明明看到流程已经走到新磁盘路径，却依然在构建阶段报no space left on device的核心原因。

你使用Docker执行器时，docker build流程产生的大体积内容，默认全部存储在Docker引擎的根数据目录下（系统盘默认路径为/var/lib/docker）。这个目录由独立运行的Docker服务管控，和GitLab Runner的配置没有任何绑定关系。哪怕你把Runner的所有工作目录都迁移到新磁盘，只要Docker引擎还在使用原系统盘作为数据存储位置，所有构建产生的镜像层都会持续堆满原系统盘，触发磁盘不足报错。

• 停止Docker相关服务，避免迁移过程中数据读写造成损坏：执行systemctl stop docker.socket docker.service
• 将原Docker数据目录的全量内容同步到新磁盘的专属存储路径，比如在新磁盘下创建Docker专用目录：rsync -aP /var/lib/docker/ /run/media/<user>/STORAGE/docker-data/，注意路径末尾的斜杠不要遗漏，避免出现目录嵌套导致的文件位置错乱
• 修改Docker服务的全局配置，指定新的数据根目录：编辑/etc/docker/daemon.json，在原有配置中追加"data-root": "/run/media/<user>/STORAGE/docker-data"字段，注意不要覆盖文件内已有的其他配置项。

  参考配置示例（/etc/docker/daemon.json）

  {
    "data-root": "/run/media/<user>/STORAGE/docker-data",
    "log-driver": "json-file",
    "log-opts": {
      "max-size": "10m",
      "max-file": "3"
    }
  }
  

• 备份旧的Docker数据目录，避免Docker启动时自动读取旧路径：将原/var/lib/docker重命名为/var/lib/docker.bak
• 启动Docker服务并验证配置生效：执行systemctl start docker，再通过docker info | grep "Docker Root Dir"命令确认输出路径和你设置的新磁盘路径一致，即说明Docker侧的存储迁移完成
• 修复外置磁盘的服务访问权限与稳定性：
  • 当前/run/media/<user>/STORAGE路径是系统udisks服务自动生成的用户会话级挂载点，默认权限仅允许当前登录的普通用户读写，而GitLab Runner、Docker服务都是以系统用户身份运行的，会因为权限不足无法访问磁盘路径
  • /run/media下的挂载点会在用户注销后自动卸载，服务重启时可能找不到存储路径导致启动失败
  • 推荐将外置磁盘分区写入/etc/fstab做开机自动挂载，使用独立的稳定挂载点（如/mnt/STORAGE）替代用户会话路径，同时调整对应目录的权限，给gitlab-runner、docker运行用户开放读写权限
• （可选）将Runner的缓存目录cache_dir也设置到新磁盘路径下，避免CI流水线的缓存文件继续占用原系统盘空间

• 在CI流水线的收尾阶段添加清理逻辑，执行docker system prune -af --volumes清理构建过程中产生的悬空镜像、无用构建缓存，避免长期累积占用磁盘空间
• 定期检查新磁盘的剩余空间，避免大体积镜像构建过程中耗尽新磁盘的存储空间

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