在平时的工作中,不晓得你有没有常常须要构建容器镜像进行测试,并且不肯定是在构建环境中应用镜像。这时候就须要将镜像推送到镜像仓库做直达,而后在别处拉取并运行容器。长此以往,因为遗记清理镜像仓库中的“垃圾”镜像越来越多。
当然,也能够应用相似 Harbor 这种带有主动清理性能镜像仓库。但只是作为长期镜像的直达,Harbor 这种未免太重了。
明天要介绍的 ttl.sh 正适宜解决这种场景。
ttl.sh
ttl.sh 是一个匿名的长期镜像仓库,收费应用无需登录,并且曾经开源。无需登录,镜像名称自身就提供了保密性,比方你能够应用 UUID 来作为镜像名称,应用同一个 UUID 来推送和拉取镜像。
应用
ttl.sh 的应用分外简略,跟平时应用 Docker Hub 或者 Docker Registry 没差异,只是 tag 的须要留神一下。
docker build
构建镜像时通过 tag 为镜像指定有效期,比方ttl.sh/b0a2c1c3-5751-4474-9dfe-6a9e17dfb927:1h
。有效期默认是 1 小时,最长是 24 小时。无效的 tag 能够是5m
、300s
、4h
、1d
,如果超过 24 小时有效期会被设置为 24 小时;如果工夫格局有效,有效期设置为默认的 1 小时;- 应用
docker push
推送镜像; - 应用
docker pull
拉取镜像。
比方:
# macOS 下默认生成大写的 UUID,须要转成小写;Linux 下间接应用 uuidgen 即可
# docker 镜像不反对大写镜像名
$ IMAGE_NAME=$(uuidgen | tr "[:upper:]" "[:lower:]")
$ docker build -t ttl.sh/${IMAGE_NAME}:5m .
$ docker push ttl.sh/${IMAGE_NAME}:5m
实现
ttl.sh 的源码开源在 GitHub,实现也不简单。
ttl.sh 基于 Registry v2 的镜像仓库,利用 Registry 的 notification 性能,将镜像的 push event 发送给 Hooks web 服务。
Hooks 将 event 中的镜像信息解析并记录在 Redis 中,次要是记录镜像的过期工夫;同时有个 Reaper 的定时工作定期从 Redis 获取镜像的信息,过期的镜像会调用 Registry 的 REST API 进行清理。
文章对立公布在公众号
云原生指北