docker registry v2 配置 (REGISTRY_PROXY_REMOTEURL) 解釋 + docker push 動做簡析

問題回顧

週末的時候，有個朋友在搭建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

過程

分析

一、大體問了下，若是不加認證，push是沒有問題的，因此先肯定了裸registry是沒有問題的；
二、看了下參數，彷佛沒什麼特別的配置，以爲應該不會有啥問題(好尷尬)；
三、看了下push的時候的報錯是個unsupported，好吧，報錯的彷佛不知道爲啥，像是異常沒獲取到，來了個通量的；
四、看了下日誌，這算是一套push(認證 push)完整的流程，可是出現了"405 78" 的狀態，405權限問題，彷佛有點頭緒了(這裏被這種報錯誤影響了很久很久)；
備註：auth server 能夠參考開頭的鏈接中博客的認證服務，用的就是那個

實驗1

好了，405是個突破口了，彷佛說明auth server那裏出了點情況，
一、因而乎手動調取了下auth server的API，token是能夠拿到的，ok，auth server最起碼是理人的；
二、405權限吶，因而對着auth server的ACL文件是配了又配：
①：肯定是否能用，我把admin的密碼改了，而後docker login 不進去，確保能讀取config
②：翻了下它的github，配置沒有問題呀，這裏的測試過程省略1W字。
在這個地方束手無策，而後就去打LOL了，悲傷的時候必須緩解下。

實驗2

好了，隊友掛機，我又回來了。又把過程想了下，docker 既然能夠給我報錯"unsupport"，也許405也是錯的呢。而後決定詳細排查下啓動參數：
一、按照不加任何參數直接啓動，push沒問題，啓動也沒問題；
二、發現"STANDALONE"/"REGISTRY_PROXY_REMOTEURL"這2個參數沒法判斷是否會影響；
三、加上token驗證(只加了相關的參數)，發現push沒問題；
四、初步判斷可能和"STANDALONE"/"REGISTRY_PROXY_REMOTEURL"這2個參數有關；
五、最後確認和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過程省略)
一、docker client接收到push命令後，首先判斷命令是否完整；
二、確保命令完整後，索引到相應的鏡像文件，將p_w_picpath ID提取出來；
三、將p_w_picpath ID發送到倉庫中驗證是否有重複，從而處理增量上傳；
四、registry拿到p_w_picpath ID,先在本地驗證一次，而後到遠端HUB中驗證；
五、registry將驗證的結果發送到client，也就是代碼中的"pushState"；
六、docker client根據pushState來進行上傳；