配置私有仓库(使用registry镜像搭建一个私有仓库)

$ docker –registry-mirror=https://myrepo.com:5000 daemon

11.验证选项

限定来自指定地址的客户端才可以执行push操作:

批量管理镜像

1.批量上传指定镜像

可以使用下面的push_images.sh脚本,批量上传本地的镜像到注册服务器中,默认是本地注册服务器127.0.0.1:5000,用户可以通过修改registry=127.0.0.1:5000这行来指定目标注册服务器:

建议把脚本存放到本地的可执行路径下,例如/usr/local/bin/下面。然后添加可执行权限,就可以使用该脚本了:

$ sudo chmod a+x /usr/local/bin/push_images.sh

例如,推送本地的ubuntu:latest和centos:centos7两个镜像到本地仓库:

$ ./push_images.sh ubuntu:latest centos:centos7

上传后,查看本地镜像,会发现上传中创建的临时标签也同时被清理了。

2.上传本地所有镜像

在push_images工具的基础上,还可以进一步的创建push_all工具,来上传本地所有镜像:

另外,把它放在/usr/local/bin/下面,并添加可执行权限。这样就可以通过push_all命令来同步本地所有镜像到本地私有仓库了。

可以试着修改脚本,实现批量化下载镜像、删除镜像、更新镜像标签等更多的操作。

使用通知系统

Docker Registry v2还内置提供了Notification功能,提供了非常方便、快捷的集成接口,避免了v1中需要用户自己实现的麻烦。

Notification功能其实就是Registry在有事件发生的时候,向用户自己定义的地址发送webhook通知。目前的事件包括镜像manifest的push、pull镜像层的push、pull。这些动作会被序列化成webhook事件的payload,为集成服务提供事件详情,并通过Registry v2的内置广播系统发送到用户定义的服务接口,Registry v2称这些用户服务接口为Endpoints。

Registry服务器的事件会通过HTTP协议发送到用户定义的所有Endpoints上,而且每个Registry实例的每个Endpoint都有自己独立的队列,重试选项以及HTTP的目的地址。当一个动作发生时,会被转换成对应的事件并放置到一个内存队列中。镜像服务器会依次处理队列中的事件,并向用户定义的Endpoint发送请求。事件发送处理是串行的,但是Registry服务器并不会保证其到达顺序。

Notification在Docker Registry中的相关配置如下:

上面的配置会在pull或者push发生时向http://cd-service-host/api/v1/cd-service发送事件,并在HTTP请求的header中传入认证信息,可以是Basic、token、Bearer等模式,主要用于接收事件方进行身份认证。更新配置后,需要重启Registry服务器,如果配置正确,会在日志中看到对应的提示信息,比如:

configuring endpoint listener (http:

headers=map[Authorization: [token ******]]

此时,用户再通过docker客户端去push或pull,或者查询一些manifiest信息时,就会有相应的事件发送到定义的Endpoint上。

接下来看一下事件的格式和其中的主要属性:

{ "events": [ { "id": "70f44894-c4b4-4be8-9691-d37db77074cd", "timestamp": "2016-06-05T01:57:04.654256149Z", "action": "push", "target": { "mediaType": "application/vnd.docker.distribution.manifest.v1+json", "size": 45765, "digest": "sha256:fd0af29ba2ae034449bffb18dd6db2ed90d798464cc43aa81e63770713edaea8", "length": 45765, "repository": "test-user/hello-world", "url": "http://registry-server/v2/test-user/hello-world/manifests/sha256:fd0af29ba2ae034449bffb18dd6db2ed90d798464cc43aa81e63770713edaea8" }, "request": { "id": "9d3d837f-d7ed-4fa9-afb4-dda58687a6ce", "addr": "client-host:46504", "host": "registry-server", "method": "PUT", "useragent": "docker/1.9.1 go/go1.4.2 git-commit/a34a1d5 kernel/4.2.0-35-generic os/linux arch/amd64" }, "actor": { "name": "test-user" }, "source": { "addr": "8e14c2a190f2:5000", "instanceID": "c564003e-dd9b-4a9b-8a30-fe8564e97ba9" } } ] }

每个事件的payload,都是一个定义好的JSON格式的数据。

通知系统的主要属性主要包括action、target.mediaType、target.repository、target.url、request.method、request.useragent、actor.name等,参见表。

理解了如何配置Docker Registry v2的Notification、Endpoint,以及接收到的Event的数据格式,我们就可以很方便地实现一些个性化的需求。

这里简单列举两个场景,一个是如何统计镜像的上传、下载次数,方便了解镜像的使用情况,另一个场景是对服务的持续部署,方便管理镜像,参见图。

1.镜像上传、下载计数

很常见的一个场景是根据镜像下载次数,向用户推荐使用最多的镜像,或者统计镜像更新的频率,以便了解用户对镜像的维护程度。

用户可以利用Notification的功能,定义自己的计数服务,并在Docker Registry上配置对应的Endpoint。在有pull、push动作发生时,对相应镜像的下载或者上传次数进行累加,达到计数效果。然后添加一个查询接口,供用户查看用户镜像的上传、下载次数,或者提供排行榜等扩展服务。

2.实现应用的自动部署

在这个场景下,可以在新的镜像push到Docker Registry服务器时候,自动创建或者更新对应的服务,这样可以快速查看新镜像的运行效果或者进行集成测试。用户还可以根据事件中的相应属性,比如用户信息、镜像名称等,调用对应的服务部署接口进行自动化部署操作。

原文链接:https://blog.csdn.net/weixin_34150503/article/details/89759322

© 版权声明
THE END
喜欢就支持一下吧
点赞0 分享