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

32去2

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

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


1:docker push myregistry.com/ubuntu:0.0.1The 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来进行上传；