Deploying a registry server

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

运行在localhost上

启动你的registry：

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

你先在可以通过docker使用它了。
获取任意的镜像从hub，然后标记它指向你的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

存储

默认情况下，你的registry数据作为docker volume持久化到主机的文件系统。如果你坚持要使用本地文件系统储存，正确的理解volumes是十分必要的。

为了更容易的访问，你可能会指定你的volume位置到一个指定的地方。你可以这样：

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

备选方案

通常你应该考虑使用其它的存贮后端替换本地文件系统。使用存储配置选项去设置一个其它的存储后段。

使用它们可以使你更加容易的扩展你的registry。并充分利用您的存储冗余和可用性功能。

运行一个domain registry

在localhost上运行供自己使用，但是更多的人想要registry可以更加广泛的被使用。为了做到这一点，Docker engine需要你使用TLS来确保安全，这与web服务器配置SSL是非常相似的。

获取证书

假设你拥有myregistrydomain.com这个域名，并且DNS记录指向你运行registry的主机，你首先需要从CA那里获取一个证书。

创建一个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

现在你应该能够访问你的registry从其它的docker主机：

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

问题

证书的颁发者可能会提供一个中间证书给你。这种情况下，你必须结合你的证书和这个中间证书为一个证书包。你可以使用cat命令：

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

备选方案

虽然很少建议，你可能想要使用自签证书来替代，或是使用不安全的方式。你可以在这里这里找到一些说明。

负载均衡的考虑

人们可能会想使用负载均衡器来分发负载，有限的TLS或是提高可用性。完整的负载均衡超出了本文的范围，这里有一些建议可以使你使用的更加容易。

最重要的方面是一个负载均衡的registry集群必须提供相同的资源。对于当前版本的registry，这意味着下面这些必须是相通的：

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

如果这些有一个不同，registry会产生一些问题。比如，如果你使用文件系统驱动，所有的registry实例必须可以访问相同的根文件系统，这意味着它们应该在同样的机器中。对于其它的driver，比如s3或是azure，它们应该访问相同的资源，并且可能会共享相同的配置。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运行在安全的本地网络，不然registry应该实现访问限制。

Native basic auth

最简单的实现访问限制的方式是通过基本认证(这与其它的web服务器的认证机制十分相似)。

警告: 你不能在不安全的registry中使用认证。所以必须先配置TLS。

首先创建一个密码文件，用户名“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

现在你可以：

docker login myregistrydomain.com:5000

然后作为一个认证用户去push和pull镜像。

问题

看到X509错误通常是你要使用自签名证书，或是没有正确配置你的docker daemon。

备选方案

1. 你可能想通过代理设计在registry之前，使用更高级的基本身份验证。你可以在这里找到一些例子。
2. 另外，这个Registry也支持委托认证，重定向用户到一个指定的，受信任的token服务器。这种途径明显需要更多的投入，并且如果你想充分的配置ACLs(访问控制列表)和完全的控制Registry集成到你的认证系统。

你可以看看这个背景信息，和配置信息。

注意你需要实现你自己的认证服务为此或是用第三方的实现。

通过Compose管理

当你的registry配置变得更复杂时，处理它就会变的很烦人。

强烈推荐使用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

下一步

你可以通过下面的章节发现更多更详细的内容：

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