近日,由VMware联合Intel、PingCAP、EMQ、灵雀云等合作伙伴联合主办的大型开源活动——智能云边开源峰会(OpenSourceAceCon)成功落下帷幕。作为开源技术生态的年度盛会,大会邀请了多位来自开源领域的技术领导者及重要贡献者,分享“云原生、边缘计算、人工智能”三大热门技术趋势及洞察。
灵雀云DevOps团队工程师张晨宇在云原生分论坛分享了《Harbor企业级落地实践》主题演讲,下面是演讲视频及实录。
想了解更多Harbor企业级实践干货,可添加小助手native,(备注:Harbor)拉您进入交流群。
演讲实录
大家好,我叫张晨宇,来自灵雀云,今天我给大家分享Harbor云原生制品仓库的企业级落地实践。
主要从以下6个部分来介绍:
Harbor在企业内部承担的角色
Harbor从1.x到2.x版本的演进过程
企业内部的Harbor治理维护规范
Harbor和灵雀云ACP产品的融合
灵雀云对Harbor社区的开源贡献
Harbor企业版
Harbor在企业内部承担的角色
在企业内部的开发流程里,开发人员在开发某一个特性时,会将代码推送到自己的功能分支,然后这个分支需要给Master分支提一个PullRequest。之后通过代码仓库的事件机制,发送Webhook通知到企业内部的DevOps内部组件上,然后这些组件会负责去触发对应的流水线。在这个过程里,Harbor主要承担镜像仓库的角色。流水线里面会去构建镜像,之后会推送到Harbor上,Harbor上的镜像会有测试人员去拉取,还有一些自动化构建或者打包的脚本去从Harbor上拉取镜像,之后去做一些自动化的部署以及测试等。
灵雀云从年之前就已经开始使用Harbor了,可以看一下近三年数据规模的变化,年我们的镜像仓库只有个左右,到今年已经增长到超过个了;另外一块是对应的Harbor里面的制品数量,从最早的1万个,到今年已经超过了10万个;存储空间从最早的1T到今年已经超过10T的一个规模。
另一方面,是关于请求规模,年每天的日均推送是次左右,到今年每天请求次数已经超过00次了,日均拉取的数量提升更为明显,从最早的0次,到今年每天拉取次数已经超过10万次。
Harbor从1.x到2.x版本的演进过程
首先看我们企业内部在使用Harbor1.x版本时遇到的问题。之前业务组件都是通过chart去部署,也有多架构镜像的需求,是需要提供两种架构:AMD和ARM。Harbor1.x只能支持单架构的镜像,想实现多架构的需求,社区主要是通过给镜像tag加架构信息后缀的方式,这种方式有三个缺点,第一:需要维护两个架构版本的chart,第二:tag信息冗余,第三:有额外的tag维护成本。
后来我们采用另外一种方式,通过部署两套Harbor来维护两种架构的镜像,分别是AMDHarbor和ARMHarbor。优点是业务chart只需要维护一套,接着通过指定registry拉取不同架构的镜像。另外非常显著的优点是tag比较统一,不需要专门维护镜像架构的后缀来作为标志信息。缺点是需要额外的Harbor维护成本。
Harbor发布2.0版本后,增加了对OCI制品的支持,可以通过同一个tag维护多个架构的镜像。我们将之前的流程做变化,直接使用Harbor2.x提供的多架构的能力,这个过程涉及到多架构镜像迁移,因为之前是部署了两套Harbor,又额外部署了Harbor2.x版本。
迁移主要分成两个步骤,第一通过将1.x版本里的单架构镜像push到2.x的Harbor上,过程中注意需要给对应的镜像加上对应架构后缀,如果分成两次push这个镜像,第二次的会覆盖第一次的,所以需要用不同后缀作为区分。
第二push完镜像后,需要手动创建镜像的manifests的index的文件,这是OCI对多架构的index的定义,需要手动创建,创建方式是docker提供了manifests的子命令来完成,只需要去指定镜像的tag信息,然后通过-a的方式来指定index里所包含的对应的不同架构的镜像tag信息,完成后,manifests文件是存在本地,要通过dockermanifestspush命令将这个index推送到Harbor上,这样就完成了迁移过程。
Harbor2.x版本上线后,能够存放多架构镜像,我们企业内部对流水线进行了改造。可通过Buildx构建多架构镜像,目前主要有两种方式,第一是QEMU,相当于在机器上安装QEMU,通过QEMU模拟其他架构环境,该方式配置简单方便,缺点是它的构建速度慢于原生架构的构建。
最后我们通过异构集群(buildxkubernetesdriver)来实现。这是需要部署两个集群,AMD和ARM的集群,构建时会根据你所需构建的镜像架构信息调度到对应的不同节点上去构建,这相当于原生的构建,速度比较快。缺点是需要去部署异构集群,配置及维护成本略高。
选择异构集群方案前我们做了原生构建和QEMU构建的耗时对比,以docker