docker registry v2 配置 (REGISTRY_PROXY_REMOTEURL) 解释 + docker pull/push 动作简析

wiryywiryy 8年前

来自: http://dockone.io/article/1081

问题回顾

周末的时候,有个朋友在搭建docker registry v2版本( http://dockone.io/article/84 5)的时候遇到了一个问题:

问题描述:仓库搭建完成后,login没问题,但是push镜像会一直在retry,直到超时。

docker push myregistry.com/ubuntu:0.0.1

The push refers to a repository [myregistry.com/ubuntu]

xxxxxxx: Retrying in 5 seconds

xxxxxxx: Retrying in 5 seconds 

unsupported

log:

time="2016-02-27T07:43:30Z" level=warning msg="error authorizing context: authorization token required" go.version=go1.5.3 http.request.host=myregistry.com http.request.id=cf177681-c67a-4ecf-ad9c-7055faaf3331 http.request.method=GET http.request.remoteaddr="192.168.159.136:51585" http.request.uri="/v2/" http.request.useragent="docker/1.10.2 go/go1.5.3 git-commit/c3959b1 kernel/3.13.0-24-generic os/linux arch/amd64" instance.id=b498d7d9-aaa1-4a16-9fb6-714447085964 version=v2.3.0

192.168.159.136 - - [27/Feb/2016:07:43:30  0000] "GET /v2/ HTTP/1.1" 401 87 "" "docker/1.10.2 go/go1.5.3 git-commit/c3959b1 kernel/3.13.0-24-generic os/linux arch/amd64"time="2016-02-27T07:43:30Z" level=error msg="response completed with error" auth.user.name=admin err.code=unsupported err.message="The operation is unsupported." go.version=go1.5.3 http.request.host=myregistry.com http.request.id=4a12623f-b8f4-4875-95ba-115eb375f6d5 http.request.method=POST http.request.remoteaddr="192.168.159.136:51587" http.request.uri="/v2/ubuntu/blobs/uploads/" http.request.useragent="docker/1.10.2 go/go1.5.3 git-commit/c3959b1 kernel/3.13.0-24-generic os/linux arch/amd64" http.response.contenttype="application/json; charset=utf-8" http.response.duration=4.218218ms http.response.status=405 http.response.written=78 instance.id=b498d7d9-aaa1-4a16-9fb6-714447085964 vars.name=ubuntu version=v2.3.0

192.168.159.136 - - [27/Feb/2016:07:43:30  0000] "POST /v2/ubuntu/blobs/uploads/ HTTP/1.1" 405 78 "" "docker/1.10.2 go/go1.5.3 git-commit/c3959b1 kernel/3.13.0-24-generic os/linux arch/amd64"time="2016-02-27T07:43:30Z" level=error msg="response completed with error" auth.user.name=admin err.code=unsupported err.message="The operation is unsupported." go.version=go1.5.3 http.request.host=myregistry.com http.request.id=4c4fc4a9-9cdb-4ab7-a338-40d9da414dcf http.request.method=POST http.request.remoteaddr="192.168.159.136:51588" http.request.uri="/v2/ubuntu/blobs/uploads/" http.request.useragent="docker/1.10.2 go/go1.5.3 git-commit/c3959b1 kernel/3.13.0-24-generic os/linux arch/amd64" http.response.contenttype="application/json; charset=utf-8" http.response.duration=73.057308ms http.response.status=405 http.response.written=78 instance.id=b498d7d9-aaa1-4a16-9fb6-714447085964 vars.name=ubuntu version=v2.3.0

192.168.159.136 - - [27/Feb/2016:07:43:30  0000] "POST /v2/ubuntu/blobs/uploads/ HTTP/1.1" 405 78 "" "docker/1.10.2 go/go1.5.3 git-commit/c3959b1 kernel/3.13.0-24-generic os/linux arch/amd64"time="2016-02-27T07:43:30Z" level=error msg="response completed with error" auth.user.name=admin err.code=unsupported err.message="The operation is unsupported." go.version=go1.5.3 http.request.host=myregistry.com http.request.id=92c9c5bd-8281-441f-a745-4dadc3e13693 http.request.method=POST http.request.remoteaddr="192.168.159.136:51590" http.request.uri="/v2/ubuntu/blobs/uploads/" http.request.useragent="docker/1.10.2 go/go1.5.3 git-commit/c3959b1 kernel/3.13.0-24-generic os/linux arch/amd64" http.response.contenttype="application/json; charset=utf-8" http.response.duration=66.338973ms http.response.status=405 http.response.written=78 instance.id=b498d7d9-aaa1-4a16-9fb6-714447085964 vars.name=ubuntu version=v2.3.0

192.168.159.136 - - [27/Feb/2016:07:43:30  0000] "POST /v2/ubuntu/blobs/uploads/ HTTP/1.1" 405 78 "" "docker/1.10.2 go/go1.5.3 git-commit/c3959b1 kernel/3.13.0-24-generic os/linux arch/amd64"time="2016-02-27T07:43:30Z" level=error msg="response completed with error" auth.user.name=admin err.code=unsupported err.message="The operation is unsupported." go.version=go1.5.3 http.request.host=myregistry.com http.request.id=25cf49b8-99df-4d50-9f78-5ccc5d9e4bfc http.request.method=POST http.request.remoteaddr="192.168.159.136:51589" http.request.uri="/v2/ubuntu/blobs/uploads/" http.request.useragent="docker/1.10.2 go/go1.5.3 git-commit/c3959b1 kernel/3.13.0-24-generic os/linux arch/amd64" http.response.contenttype="application/json; charset=utf-8" http.response.duration=8.280863ms http.response.status=405 http.response.written=78 instance.id=b498d7d9-aaa1-4a16-9fb6-714447085964 vars.name=ubuntu version=v2.3.0

192.168.159.136 - - [27/Feb/2016:07:43:30  0000] "POST /v2/ubuntu/blobs/uploads/ HTTP/1.1" 405 78 "" "docker/1.10.2 go/go1.5.3 git-commit/c3959b1 kernel/3.13.0-24-generic os/linux arch/amd64"

启动参数

docker run -d -p 5000:5000 -p 443:5000 --restart=always --name registry \    -v `pwd`/auth:/auth \    -v `pwd`/data:/var/lib/registry \    -e STANDALONE=false \    -e REGISTRY_PROXY_REMOTEURL=https://registry-1.docker.io \    -e REGISTRY_AUTH=token \    -e REGISTRY_AUTH_TOKEN_REALM=https://myregistry.com:5001/auth \    -e REGISTRY_AUTH_TOKEN_SERVICE="Docker registry" \    -e REGISTRY_AUTH_TOKEN_ISSUER="Acme auth server" \    -e REGISTRY_AUTH_TOKEN_ROOTCERTBUNDLE=/certs/domain.crt \    -v /root/auth_server/ssl:/ssl \    -v `pwd`/certs:/certs \    -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt \    -e REGISTRY_HTTP_TLS_KEY=/certs/domain.key \    registry:2.2

过程

分析

1、大致问了下,如果不加认证,push是没有问题的,所以先确定了裸registry是没有问题的;

2、看了下参数,似乎没什么特别的配置,觉得应该不会有啥问题(好尴尬);

3、看了下push的时候的报错是个unsupported,好吧,报错的似乎不知道为啥,像是异常没获取到,来了个通量的;

4、看了下日志,这算是一套push(认证 push)完整的流程,但是出现了"405 78" 的状态,405权限问题,似乎有点头绪了(这里被这种报错误影响了好久好久);

备注:auth server 可以参考开头的连接中博客的认证服务,用的就是那个

实验1

好了,405是个突破口了,似乎说明auth server那里出了点状况,

1、于是乎手动调取了下auth server的API,token是可以拿到的,ok,auth server最起码是理人的;

2、405权限呐,于是对着auth server的ACL文件是配了又配:

①:确定是否能用,我把admin的密码改了,然后docker login 不进去,确保能读取config

②:翻了下它的github,配置没有问题呀,这里的测试过程省略1W字。

在这个地方一筹莫展,然后就去打LOL了,悲伤的时候必须缓解下。

实验2

好了,队友挂机,我又回来了。又把过程想了下,docker 既然可以给我报错"unsupport",也许405也是错的呢。然后决定详细排查下启动参数:

1、按照不加任何参数直接启动,push没问题,启动也没问题;

2、发现"STANDALONE"/"REGISTRY_PROXY_REMOTEURL"这2个参数无法判断是否会影响;

3、加上token验证(只加了相关的参数),发现push没问题;

4、初步判断可能和"STANDALONE"/"REGISTRY_PROXY_REMOTEURL"这2个参数有关;

5、最后确认和REGISTRY_PROXY_REMOTEURL有关

实验3

按照参数的解释STANDALONE应该是索引index的开关,但是貌似不会有太大关系,先忽略掉了(大家可以搜下这个参数的具体解释,个人觉得这个参数在这里不影响(应该关掉false));

参数REGISTRY_PROXY_REMOTEURL意思是mirror模式,具体配置的为远程docker仓库,突然察觉到点什么:mirror模式下,docker仓库在pull的时候会去验证远端HUB是否有相应的镜像,然后缓存,难道push的时候也会?

具体的分析

docker push 代码

https://github.com/docker/dock ... v2.go

49-59行有个大体解释。

type pushState struct {    sync.Mutex    // remoteLayers is the set of layers known to exist on the remote side.    // This avoids redundant queries when pushing multiple tags that    // involve the same layers. It is also used to fill in digest and size    // information when building the manifest.    remoteLayers map[layer.DiffID]distribution.Descriptor    // confirmedV2 is set to true if we confirm we're talking to a v2    // registry. This is used to limit fallbacks to the v1 protocol.    confirmedV2 bool    }

这里只截取了一小段代码,这里大概的意思是push的时候,会去对比远端HUB是否有重复的layers。

因为设置参数的时候没有加相应的用户名密码(这里在官方文档中是确切要求必须添加用户名密码的 https://docs.docker.com/registry/mirror /),所以造成了这个过程一直在retry。然后是docker在这一块处理的时候存在点问题,1是命令行抛了个"unsupported"报错,2是log中405报错有点尴尬,现在可以理解成到远端仓库中权限不足,但是log中应该不是很明确,但是似乎处理逻辑有些问题。

push过程分析

仅为个人理解:

(login过程省略)

1、docker client接收到push命令后,首先判断命令是否完整;

2、确保命令完整后,索引到相应的镜像文件,将image ID提取出来;

3、将image ID发送到仓库中验证是否有重复,从而处理增量上传;

4、registry拿到image ID,先在本地验证一次,然后到远端HUB中验证;

5、registry将验证的结果发送到client,也就是代码中的"pushState";

6、docker client根据pushState来进行上传;