Question

我遇到了自托管Docker Registry的问题。当拉取某个图像时，拉取在其某些图层上将失败。一旦启动docker pull命令，就会有一些图层报告：

9894d615bbeb: Retrying in 5 seconds
dfc282427f6f: Retrying in 5 seconds
8dbb865cf7b1: Retrying in 1 second

这是在命令启动时立即发生的，层不大。

注册表已经运行了大约一年。
最近，我们采用了以docker为中心的CI / CD流程，因此需要不断清理注册表。因此，我们每晚运行注册表的清理工作：
- 删除文件系统上的所有清单（我们要保留的一些持久映像除外）
- 运行bin/registry garbage-collect命令以删除所有未引用的Blob
我已经验证了这些失败层的blob确实存在于注册表中，我可以在文件系统上导航到它们。
该问题在本地系统和远程服务器上均重现

docker注册表日志显示对Blob的HTTP请求成功：

time="2019-05-03T13:09:21.714123801Z" level=info msg="response completed" go.version=go1.7.6 http.request.host=registry.example.com http.request.id=e5c01bee-a755-48a5-b87a-716560dd0e25 http.request.method=GET http.request.remoteaddr=94.237.28.78 http.request.uri="/v2/applications/foo/dist-staging/blobs/sha256:9894d615bbebb5b235bb5a7aed17e9b2ba35c95c9fc8c0c763476c057536842f" http.request.useragent="docker/17.05.0-ce go/go1.7.5 git-commit/89658be kernel/4.4.0-145-generic os/linux arch/amd64 UpstreamClient(Swipely/Docker-API 1.33.6)" http.response.contenttype="application/octet-stream" http.response.duration=8.154072ms http.response.status=200 http.response.written=0 instance.id=92dfad5e-bf76-4db6-a8de-07901539d36e service=registry version=v2.6.2
172.17.0.1 - - [03/May/2019:13:09:21 +0000] "GET /v2/applications/foo/dist-staging/blobs/sha256:9894d615bbebb5b235bb5a7aed17e9b2ba35c95c9fc8c0c763476c057536842f HTTP/1.0" 200 0 "" "docker/17.05.0-ce go/go1.7.5 git-commit/89658be kernel/4.4.0-145-generic os/linux arch/amd64 UpstreamClient(Swipely/Docker-API 1.33.6)"

docker注册表位于nginx代理后面，但其设置最近未更改。调试时，我尝试了以下尝试，但是没有运气：
```
proxy_buffering off;
proxy_max_temp_file_size 0;
```

还有什么我应该检查的吗？这可能是注册表清理造成的吗？为什么？怎么样？

修改

注册表缓存似乎有些陈旧，因为重新启动它会引发unknown blob错误。

重建并重新推送映像后，此错误消失了，并且注册表能够再次将映像提供给客户端。

我认为这意味着注册表清理过程中有些混乱，但是为什么呢？ garbage-collect应该只删除未引用的Blob，并且如果我理解正确的话，应该可以安全使用吗？

这个问题已经轮到我了，但是我将完整地留给其他人解决。

Docker拉取自托管注册表的某些层失败

0 个答案: