Deploying a registry server

你需要安裝Docker 1.6.0以上版本。

運(yùn)行在localhost上

啟動你的registry：

docker run -d -p 5000:5000 --restart=always --name registry registry:2

你先在可以通過docker使用它了。
獲取任意的鏡像從hub，然后標(biāo)記它指向你的registry：

docker pull ubuntu && docker tag ubuntu localhost:5000/ubuntu

。。。然后將它推入到你的registry：

docker push localhost:5000/ubuntu

。。。然后從你的registry里拉取它：

docker pull localhost:5000/ubuntu

停止你的registry，你可以：

docker stop registry && docker rm -v registry

存儲

默認(rèn)情況下，你的registry數(shù)據(jù)作為docker volume持久化到主機(jī)的文件系統(tǒng)。如果你堅(jiān)持要使用本地文件系統(tǒng)儲存，正確的理解volumes是十分必要的。

為了更容易的訪問，你可能會指定你的volume位置到一個指定的地方。你可以這樣：

docker run -d -p 5000:5000 --restart=always --name registry \
  -v `pwd`/data:/var/lib/registry \
  registry:2

備選方案

通常你應(yīng)該考慮使用其它的存貯后端替換本地文件系統(tǒng)。使用存儲配置選項(xiàng)去設(shè)置一個其它的存儲后段。

使用它們可以使你更加容易的擴(kuò)展你的registry。并充分利用您的存儲冗余和可用性功能。

運(yùn)行一個domain registry

在localhost上運(yùn)行供自己使用，但是更多的人想要registry可以更加廣泛的被使用。為了做到這一點(diǎn)，Docker engine需要你使用TLS來確保安全，這與web服務(wù)器配置SSL是非常相似的。

獲取證書

假設(shè)你擁有myregistrydomain.com這個域名，并且DNS記錄指向你運(yùn)行registry的主機(jī)，你首先需要從CA那里獲取一個證書。

創(chuàng)建一個certs目錄

mkdir -p certs

然后移動并重命名你的證書文件到：certs/domain.crt,你的密鑰文件為：certs/domain.key。

確保你停止了你的registry在上一步。再次啟動你的registry通過開啟TLS：

docker run -d -p 5000:5000 --restart=always --name registry \
  -v `pwd`/certs:/certs \
  -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt \
  -e REGISTRY_HTTP_TLS_KEY=/certs/domain.key \
  registry:2

現(xiàn)在你應(yīng)該能夠訪問你的registry從其它的docker主機(jī)：

docker pull ubuntu
docker tag ubuntu myregistrydomain.com:5000/ubuntu
docker push myregistrydomain.com:5000/ubuntu
docker pull myregistrydomain.com:5000/ubuntu

問題

證書的頒發(fā)者可能會提供一個中間證書給你。這種情況下，你必須結(jié)合你的證書和這個中間證書為一個證書包。你可以使用cat命令：

cat domain.crt intermediate-certificates.pem > certs/domain.crt

備選方案

雖然很少建議，你可能想要使用自簽證書來替代，或是使用不安全的方式。你可以在這里這里找到一些說明。

負(fù)載均衡的考慮

人們可能會想使用負(fù)載均衡器來分發(fā)負(fù)載，有限的TLS或是提高可用性。完整的負(fù)載均衡超出了本文的范圍，這里有一些建議可以使你使用的更加容易。

最重要的方面是一個負(fù)載均衡的registry集群必須提供相同的資源。對于當(dāng)前版本的registry，這意味著下面這些必須是相通的：

• Storage Driver
• HTTP Secret
• Redis Cache (if configured)

如果這些有一個不同，registry會產(chǎn)生一些問題。比如，如果你使用文件系統(tǒng)驅(qū)動，所有的registry實(shí)例必須可以訪問相同的根文件系統(tǒng)，這意味著它們應(yīng)該在同樣的機(jī)器中。對于其它的driver，比如s3或是azure，它們應(yīng)該訪問相同的資源，并且可能會共享相同的配置。The HTTP Secret coordinates uploads, so also must be the same across instances. Configuring different redis instances will work (at the time of writing), but will not be optimal if the instances are not shared, causing more requests to be directed to the backend.

Important/Required HTTP-Headers

Getting the headers correct is very important. For all responses to any request under the “/v2/” url space, the Docker-Distribution-API-Version header should be set to the value “registry/2.0”, even for a 4xx response. This header allows the docker engine to quickly resolve authentication realms and fallback to version 1 registries, if necessary. Confirming this is setup correctly can help avoid problems with fallback.

In the same train of thought, you must make sure you are properly sending the X-Forwarded-Proto, X-Forwarded-For and Host headers to their “client-side” values. Failure to do so usually makes the registry issue redirects to internal hostnames or downgrading from https to http.

A properly secured registry should return 401 when the “/v2/” endpoint is hit without credentials. The response should include a WWW-Authenticate challenge, providing guidance on how to authenticate, such as with basic auth or a token service. If the load balancer has health checks, it is recommended to configure it to consider a 401 response as healthy and any other as down. This will secure your registry by ensuring that configuration problems with authentication don’t accidentally expose an unprotected registry. If you’re using a less sophisticated load balancer, such as Amazon’s Elastic Load Balancer, that doesn’t allow one to change the healthy response code, health checks can be directed at “/”, which will always return a 200 OK response.

限制訪問

除非registry運(yùn)行在安全的本地網(wǎng)絡(luò)，不然registry應(yīng)該實(shí)現(xiàn)訪問限制。

Native basic auth

最簡單的實(shí)現(xiàn)訪問限制的方式是通過基本認(rèn)證(這與其它的web服務(wù)器的認(rèn)證機(jī)制十分相似)。

警告: 你不能在不安全的registry中使用認(rèn)證。所以必須先配置TLS。

首先創(chuàng)建一個密碼文件，用戶名“testuser”使用密碼“testpassword”：

#這個命令借用registry鏡像容器生成密碼串
mkdir auth
docker run --entrypoint htpasswd registry:2 -Bbn testuser testpassword > auth/htpasswd

確保你停止了你的registry在前一步。然后再次啟動它：

docker run -d -p 5000:5000 --restart=always --name registry \
  -v `pwd`/auth:/auth \
  -e "REGISTRY_AUTH=htpasswd" \
  -e "REGISTRY_AUTH_HTPASSWD_REALM=Registry Realm" \
  -e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd \
  -v `pwd`/certs:/certs \
  -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt \
  -e REGISTRY_HTTP_TLS_KEY=/certs/domain.key \
  registry:2

現(xiàn)在你可以：

docker login myregistrydomain.com:5000

然后作為一個認(rèn)證用戶去push和pull鏡像。

問題

看到X509錯誤通常是你要使用自簽名證書，或是沒有正確配置你的docker daemon。

備選方案

1. 你可能想通過代理設(shè)計(jì)在registry之前，使用更高級的基本身份驗(yàn)證。你可以在這里找到一些例子。
2. 另外，這個Registry也支持委托認(rèn)證，重定向用戶到一個指定的，受信任的token服務(wù)器。這種途徑明顯需要更多的投入，并且如果你想充分的配置ACLs(訪問控制列表)和完全的控制Registry集成到你的認(rèn)證系統(tǒng)。

你可以看看這個背景信息，和配置信息。

注意你需要實(shí)現(xiàn)你自己的認(rèn)證服務(wù)為此或是用第三方的實(shí)現(xiàn)。

通過Compose管理

當(dāng)你的registry配置變得更復(fù)雜時，處理它就會變的很煩人。

強(qiáng)烈推薦使用Docker Compose使操作registry變的更加便捷。

這里有一個簡單的docker-compose.yml匯聚了目前為止所有的說明：

registry:
  restart: always
  image: registry:2
  ports:
    - 5000:5000
  environment:
    REGISTRY_HTTP_TLS_CERTIFICATE: /certs/domain.crt
    REGISTRY_HTTP_TLS_KEY: /certs/domain.key
    REGISTRY_AUTH: htpasswd
    REGISTRY_AUTH_HTPASSWD_PATH: /auth/htpasswd
    REGISTRY_AUTH_HTPASSWD_REALM: Registry Realm
  volumes:
    - /path/data:/var/lib/registry
    - /path/certs:/certs
    - /path/auth:/auth

警告： 替換/path為你想要的目錄，確保其中包含了你的certs和auth文件夾。

然后你可以啟動你的registry：

docker-compose up -d

下一步

你可以通過下面的章節(jié)發(fā)現(xiàn)更多更詳細(xì)的內(nèi)容：

• Configuration reference
• Working with notifications
• Advanced 'recipes'
• Registry API
• Storage driver model
• Token authentication