Docker和镜像在工作中是越来越常见了，而镜像仓库的需求也变得越来越常见。Docker官方给的解决方案是私有Registry仓库，官方也给了镜像进行对应的使用。但不得不说Docker的Registry是真的不好用：
此外还有很多，这里就不一并列举了。
因此，市面上也有不少alternative替代方案，做的最好的应该是harbor。如果是大型企业或者是有比较严谨的权限控制需求的话，推荐使用harbor。
但针对小公司来说，更简单快速的部署和更简单的运维是相对来说更重要的事情，因此Docker Registry的使用也是有市场的。这里就简单做下使用上的介绍。
使用的还是官方的镜像：registry。
官方文档在：Deploy a registry server。
启动命令：
$ docker network create registry
$ docker run -d \
--name docker_registry \
--network registry \
--restart=always \
-p 15000:5000 \
-v /tmp/registry/auth:/data/registry/auth \
-v /tmp/registry/data:/var/lib/registry \
-v /tmp/registry/config.yml:/etc/docker/registry/config.yml \
-e REGISTRY_AUTH=htpasswd \
-e REGISTRY_AUTH_HTPASSWD_REALM="Registry Realm" \
-e REGISTRY_AUTH_HTPASSWD_PATH=/data/registry/auth/htpasswd \
registry:2.7.1容器内配置文件的位置：/etc/docker/registry/config.yml。
当前例子中使用的是没有前置proxy，并且仅设置了最简单的用户名密码访问限制的情况。关于这块的访问限制相关，更详细的内容可以查看官方文档：Restricting access。
生成秘钥可以使用命令：
$ docker run --rm \
--entrypoint htpasswd \
registry:2.7.1 \
-Bbn username password > /tmp/registry/auth/htpasswd如果需要结合nginx使用的话（一般推荐这样做），需要参见：Authenticate proxy with nginx。
参考配置文件：
events {
worker_connections 1024;
}
http {
upstream docker-registry {
server registry:5000;
}
## Set a variable to help us decide if we need to add the
## 'Docker-Distribution-Api-Version' header.
## The registry always sets this header.
## In the case of nginx performing auth, the header is unset
## since nginx is auth-ing before proxying.
map $upstream_http_docker_distribution_api_version $docker_distribution_api_version {
'' 'registry/2.0';
}
server {
listen 443 ssl;
server_name myregistrydomain.com;
# SSL
ssl_certificate /etc/nginx/conf.d/domain.crt;
ssl_certificate_key /etc/nginx/conf.d/domain.key;
# Recommendations from https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html
ssl_protocols TLSv1.1 TLSv1.2;
ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
# disable any limits to avoid HTTP 413 for large image uploads
client_max_body_size 0;
# required to avoid HTTP 411: see Issue #1486 (https://github.com/moby/moby/issues/1486)
chunked_transfer_encoding on;
location /v2/ {
# Do not allow connections from docker 1.5 and earlier
# docker pre-1.6.0 did not properly set the user agent on ping, catch "Go *" user agents
if ($http_user_agent ~ "^(docker\/1\.(3|4|5(?!\.[0-9]-dev))|Go ).*$" ) {
return 404;
}
# To add basic authentication to v2 use auth_basic setting.
auth_basic "Registry realm";
auth_basic_user_file /etc/nginx/conf.d/nginx.htpasswd;
## If $docker_distribution_api_version is empty, the header is not added.
## See the map directive above where this variable is defined.
add_header 'Docker-Distribution-Api-Version' $docker_distribution_api_version always;
proxy_pass http://docker-registry;
proxy_set_header Host $http_host; # required for docker client's sake
proxy_set_header X-Real-IP $remote_addr; # pass on real client's IP
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_read_timeout 900;
}
}
}在刚才的启动命令部分已经提到了如何制作用户名和密码的访问限制秘钥。而作为用户访问Registry则是另一回事。
私有Registry如果架设的是HTTP，而不是HTTPS的话，访问的客户端需要修改配置，将该Registry的地址列入允许的不安全访问列表内，才可以正常访问。一般来说这个配置文件是在：~/.docker/daemon.json。
范例：
{
"insecure-registries" : [
"127.0.0.1:15000"
]
}修改完成之后必须重启本地的docker进程，该配置才会生效。
然后使用docker login 127.0.0.1:15000进行登录，这会在~/.docker/config.json文件中生成一个登录项。但访问凭证一般不会直接存储在这里，OSX操作系统是使用keychain来进行存储。参见：Credentials store。
在某些场合，需求预先生成访问凭证，而不是到实际运行的主机上进行docker login。这时候使用命令来生成凭证，并手动生成对应的登录项配置文件，放到指定的位置来生效。
根据用户名和密码来生成凭证：
$ echo -n "$username:$password" | base64
# dGVzdDphYmMxMjNf生成登录项配置文件~/.docker/config.json：
{
"auths": {
"127.0.0.1:15000": {
"auth": "dGVzdDphYmMxMjNf"
}
}
}这样后续的使用就没有问题了，当然这样做是非常不安全的，不推荐使用。
因为registry没有提供UI界面，所有的操作都必须通过RESTful API来进行。
官方文档在：HTTP API V2。
常用API范例：
查看所有的仓库清单
$ curl -u $username:$password http://127.0.0.1:15000/v2/_catalog | jq .结果：
{
"repositories": [
"fullstack/builder",
"fullstack/common",
"fullstack/gateway",
"fullstack/runner",
"fullstack/server"
]
}查看某个仓库的所有tag
$ curl -u $username:$password http://127.0.0.1:15000/v2/fullstack/common/tags/list | jq .结果：
{
"name": "fullstack/common",
"tags": [
"0.0.42",
"0.0.43",
"0.0.35",
"0.0.32",
"0.0.33",
"0.0.34"
]
}查看某个仓库某个tag的digest
$ curl -u $username:$password http://127.0.0.1:15000/v2/fullstack/common/manifests/0.0.43 \
--header "Accept: application/vnd.docker.distribution.manifest.v2+json" | jq '.config|.digest'结果：
"sha256:23ffb64a5f8c7bf748eb80830d7f3be7f5de613ba9d37817fe7771180b59fdc5"
根据digest删除某个仓库的某个tag
$ curl $username:$password -I -X DELETE "http://127.0.0.1:15000/v2/fullstack/common/manifests/sha256:23ffb64a5f8c7bf748eb80830d7f3be7f5de613ba9d37817fe7771180b59fdc5"结果：
HTTP/1.1 202 Accepted
Docker-Distribution-Api-Version: registry/2.0
X-Content-Type-Options: nosniff
Date: Thu, 26 Dec 2019 09:17:51 GMT
Content-Length: 0
只要返回的CODE是202，说明就是没问题的，正常删除。
刚才在API中已经提到了根据digest删除某个tag，但是这时候镜像的真实数据还并没有被删除。还需要做几步操作。
首先需要修改Registry的配置文件，允许删除操作。注意下面范例的：storage.delete.enabled: true。
version: 0.1
log:
fields:
service: registry
storage:
cache:
blobdescriptor: inmemory
filesystem:
rootdirectory: /var/lib/registry
delete:
enabled: true
http:
addr: :5000
headers:
X-Content-Type-Options: [nosniff]
health:
storagedriver:
enabled: true
interval: 10s
threshold: 3然后需要进入容器内部进行删除操作：
$ docker exec -it /bin/sh
/# /bin/registry garbage-collect /etc/docker/registry/config.yml即便这样，被删除的tag仍旧会出现在tag列表API的结果里。Docker官方对删除就完全没做好支持。
EOF