私有Docker Registry双仓库拉取偶现unexpected EOF问题求助

环境配置 #

• 基于Docker官方Registry容器搭建私有镜像仓库
• 仓库包含repo1和repo2两个镜像仓库，为同一应用的不同版本，共享部分镜像层
• 从独立构建服务器向私有仓库推送镜像
• 已知同类问题存在，但未找到根因解决方案，临时workaround无法可靠解决

问题现象 #

拉取镜像时偶现unexpected EOF错误，失败的是两个仓库共享的同一镜像层：

拉取repo1时的错误：

docker pull registry.foobar.com/repo1/repo1:latest 
latest: Pulling from repo1/repo1
125a6e411906: Already exists 
ab029ed1e0ab: Already exists 
bd96b0d396b3: Pull complete 
e0135e3ddcf1: Pull complete 
6a8cac0382d1: Pull complete 
756f32f3ded1: Downloading [==================================================>]  2.291kB/2.291kB
unexpected EOF 

拉取repo2时的错误：

docker pull registry.foobar.com/repo2/repo2:latest 
latest: Pulling from repo2/repo2
<different SHA>: Already exists 
<different SHA>: Already exists 
<different SHA>: Pull complete 
<different SHA>: Pull complete 
<different SHA>: Pull complete 
756f32f3ded1: Downloading # 与repo1失败的是同一SHA值的共享层
[==================================================>]  2.291kB/2.291kB
unexpected EOF 

已做排查 #

• 登录仓库文件系统检查，确认失败的镜像层实际不存在，EOF错误符合预期
• 通过以下步骤删除对应层：从manifest获取完整sha256值，执行删除命令：

  curl --user "$USER:$PASS" -H 'Accept: application/vnd.docker.distribution.manifest.v2+json' -k -X DELETE "https://registry.com/v2/repo1/repo1/blobs/sha256:THE_SHA"
  

• 删除后重新推送镜像，提示c9a6d53cb9c5: Mounted from repo2/repo2，但拉取时问题仍未解决

排查与解决建议 #

1. 强制推送完整镜像层（跳过层挂载） #

Docker推送时默认会复用已存在的共享层（通过挂载方式），若挂载的层实际未完整上传，会导致拉取失败。可通过以下步骤强制重新上传完整层：

# 先删除本地的问题共享层
docker rmi sha256:756f32f3ded1
# 重新构建镜像（确保本地无缓存层）
docker build --no-cache -t registry.foobar.com/repo1/repo1:latest .
# 推送镜像，禁用内容信任（避免依赖现有挂载）
docker push --disable-content-trust registry.foobar.com/repo1/repo1:latest

对repo2执行同样操作，确保两个仓库的共享层都完整上传。

2. 检查Registry存储与日志 #

• 确认Registry容器的存储路径权限正常，磁盘空间充足，无读写错误
• 查看Registry容器日志，排查推送时是否有层上传失败的记录：

  docker logs <你的Registry容器ID/名称>
  

  重点查找与sha256:756f32f3ded1相关的报错，比如权限不足、网络中断、存储异常等。

3. 执行Registry垃圾回收修复元数据 #

Registry的元数据可能与实际存储的镜像层不一致，执行垃圾回收清理无效元数据：

# 进入Registry容器执行垃圾回收命令
docker exec -it <你的Registry容器ID/名称> registry garbage-collect /etc/docker/registry/config.yml

执行完成后重新推送镜像，确保元数据与实际存储同步。

4. 验证网络稳定性 #

构建服务器与Registry之间的网络波动可能导致层上传不完整，检查网络连通性：

# 测试延迟与丢包
ping registry.foobar.com
# 测试路由路径
traceroute registry.foobar.com

若存在网络不稳定情况，建议优化网络配置（如调整MTU、使用专线），或在推送时使用--disable-content-trust确保层完整上传。

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