阿里云容器镜像服务的运维总结

一、背景

容器镜像服务，作为一个可选付费产品，主要作用是存储docker的镜像仓库，供k8s拉取到Pod节点里。 你可以自己搭建一个harbor镜像仓库，在公司的开发环境下，将image推送到仓库；然后在生产k8s从仓库拉取image到本地。
如下图的方案二所示，阿里云的容器镜像服务，其实也就是一个镜像仓库。它可以被harbor/nexus等私有部署所替代。

• 方案一
  

• 方案二
  
  既然是一个镜像仓库，那么需要运维的地方就和harbor类似，存储空间的治理就显得非常重要。

本文主要介绍，我们在运维阿里云镜像仓库过程中，需要主要的一些问题。

二、实例

规格选择基础版，对于我们生产环境来说，足够使用。

• 总仓库数，已使用138个
• 总命名空间，已使用3个
• OSS存储容量5.7TB，这块涉及到的OSS费用，需要引起关注。

三、仓库管理-命名空间

阿里云容器镜像仓库服务，支持你新建多个命名空间，用于支持不同镜像的部署。

四、仓库管理-镜像仓库

• 创建仓库
  

• 删除仓库

这一点，建议产品设计做交互的时候，向阿里云学习。点击“删除”，弹出确认删除的提示框，让你再次勾选后才触发删除。

第二步，删除后，列表的整行背景变灰，不允许用户再次去删除。并且在表格的状态列，展示“删除中”的字眼。

第三步，待服务端将该仓库删除完成，客户端界面将被删除的那行从表格里移除。

背后的技术实现，删除是异步操作，可能是以下两种：

• 客户端和服务端建立长连接，可以是websocket协议。服务端彻底删除记录后，发送ws消息推送给客户端。这样，客户端就能实时感知得到服务端的删除结果。
• 客户端采用Long Polling的http协议，相当于定期轮询服务端的操作结果，好处是不用频繁创建http连接，性能更佳。

五、仓库管理-版本管理

作为存储空间的优化重点，我们需要对镜像进行定期清理。

阿里云的策略比较简单，不会像harbor那么复杂，当然也足够受用了。


因为是但环境下的镜像仓库，所以用不上什么正则匹配。
选择保留最近构建的3个镜像，再早的就自动废弃了。
每周会跑定时任务。（具体周几的几点，阿里云对于我们使用的用户来说，都是透明的）

我这里等不及定时清理了，所以点击了一次“立即执行”，可以看到，在用的实例下成功地清理掉了671个image，总花费6分钟的时间。

这里，建议产品经理们学一下它这里是如何设计异步操作交互。

单独的一个刷新按钮，而非整个页面刷新。
清理的Tag数，会随着手动刷新而逐渐变多，直至清理状态是“已完成”。点击“查看”，可以看到清理的明细进度。

六、总结

本文主要是介绍了一下阿里云的容器镜像服务，需要主要的一些运维问题，希望可以帮助到你。