本文由“GO开源说”第七期 《Harbor助你玩转云原生》直播内容修改整理而成,视频内容较长,本文内容有所删减和重构。
云原生技术的兴起为企业数字化转型带来新的可能。作为云原生的要素之一,带来更为轻量级虚拟化的容器技术具有举足轻重的推动作用。其实很早之前,容器技术已经有所应用,而Docker的出现和兴起彻底带火了容器。其关键因素是Docker提供了使用容器的完整工具链,使得容器的上手和使用变得非常简单。工具链中的一个关键,就是定义了新的软件打包格式-容器镜像。镜像包含了软件运行所需要的包含基础OS在内的所有依赖,推送至运行时可直接启动。从镜像构建环境到运行环境,镜像的快速分发成为硬需求。同时,大量构建以及依赖的镜像的出现,也给镜像的维护管理带来挑战。镜像仓库的出现成为必然。
图1 镜像仓库
镜像构建之后可以推送至仓库储存和管理,运行时环境在有应用运行需求时,从仓库拉取特定的应用镜像来运行。镜像仓库作为镜像的分发媒介,可以实现特定的管理和访问控制机制。仓库作为镜像传输流动的主要媒介,成为云原生应用平台运转的核心要件。Docker开源了其registry实现, 目前已经成为CNCF的沙箱项目Distribution。不过,Distribution项目仅仅实现了对镜像存储的支持,对企业级的一些管理诉求并无法提供支持。
为了实现企业级镜像仓库的支持,Harbor项目应运而生。
Harbor Registry(又称Harbor云原生制品仓库或Harbor镜像仓库)由VMware公司中国研发中心云原生实验室原创,并于2016年3月开源。Harbor在Docker Distribution的基础上增加了企业用户必需的权限控制、镜像签名、安全漏洞扫描和远程复制等重要功能,还提供了图形管理界面及面向国内用户的中文支持,开源后迅速在中国开发者和用户社区流行,成为中国云原生用户的主流容器镜像仓库。
2018年7月,VMware捐赠Harbor给CNCF,使Harbor成为社区共同维护的开源项目,也是首个源自中国的CNCF项目。在加入CNCF之后,Harbor融合到全球的云原生社区中,众多的合作伙伴、用户和开发者都参与了Harbor项目的贡献,数以千计的用户在生产系统中部署和使用Harbor,Harbor每个月的下载量超过3万次。2020年6月,Harbor成为首个中国原创的CNCF毕业项目。目前Harbor主项目已经在GitHub上已经获得了1万3千多颗星。Harbor项目目前有来自于全球多家公司的14名维护者,200多名核心提交者,以及50多个贡献公司。Harbor社区依然在蓬勃发展,欢迎更多的贡献者加入!
Harbor是为满足企业安全合规的需求而设计的,旨在提供安全和可信的云原生制品管理,支持镜像签名和内容扫描,确保制品管理的合规性、高效性和互操作性。Harbor的功能主要包括四大类:多用户的管控(基于角色访问控制和项目隔离)、镜像管理策略(存储配额、制品保留、漏洞扫描、来源签名、不可变制品、垃圾回收等)、安全与合规(身份认证、扫描和CVE例外规则等)和互操作性(Webhook、内容远程复制、可插拔扫描器、REST API、机器人账号等)。
-
离线安装包:通过docker-compose编排运行。安装包除了包含相关的安装脚本外,还包含了所有安装所需要的Harbor组件镜像,可以在离线环境下安装使用。
-
在线安装包:与离线安装包类似,唯一的区别就是不包含harbor组件镜像,安装时镜像需要从网络上的仓库服务拉取。
-
Helm Chart:
通过Helm的方式将Harbor部署到目标的Kubernetes集群中。
目前仅覆盖Harbor自身组件的部署安装,其所依赖的诸如数据库、Redis缓存以及可能的存储服务需要用户自己负责。
-
Kubernetes Operator:
基于Kubernetes Operator框架编排部署,重点关注all-in-one的HA部署模式的支持。
目前还处于开发中,很快就会发布。
基于策略的镜像复制机制,可以帮助用户实现将源仓库中的特定镜像集合在指定的条件下复制到目标镜像仓库中。在复制策略中,除了指定源仓库或者目标仓库之外,可以指定多种过滤器(镜像库、tag和标签)与多种触发模式(手动,基于时间以及定时)且实现对推送(将镜像从源仓库推送至目标仓库)和拉取(将目标仓库的镜像拉取到当前仓库)两种模式的支持。首次复制为全量复制,之后会实现增量复制以提升效率。目前Harbor的复制功能已经支持包含Docker Hub、Quay、GCR、ECR等在内的十多种第三方镜像仓库,具体列表可参考 Replicaiton adpaters(https://goharbor.io/docs/2.2.0/install-config/harbor-compatibility-list/)。
基于复制功能,可有构建主从或者中心-边缘的多层分发体系,以实现镜像内容的高效和稳定的分发。如下图所示。镜像推送至中心Harbor仓库,然后复制到其它地理位置上的边缘仓库,容器运行时可从就近的边缘仓库拉取。
在进行大量部署的时候,对仓库的镜像拉取请求会产生井喷,进而造成比较重的负担。而这其中可能有很多重复的镜像请求,这样也就造成更多的不必要的资源和流量浪费。P2P网络可以加速内容的分发,自然也可以加速镜像的分发。因为P2P的特质,内容可来源于其它peer节点,这样可以有效地减少对上游仓库的请求。Harbor是镜像仓库,本身不支持P2P协议。但是可以与其它P2P提供者实现集成,进而利用P2P vendor能力实现镜像的加速。这就是Harbor的镜像预热功能。用户通过在特定项目中创建特定的预热策略,使用过滤器(repository和tag)来确定哪些镜像满足什么样的条件(是否签名,持有特定标签或者满足特定的漏洞状态)需要预热,在什么时候(就有事件或者基于定时)触发预热,将所选镜像提前从Harbor仓库传输到特定P2P引擎的缓存中,在有拉取请求时,P2P可以直接开始工作,不需要从上游仓库获取首份镜像内容。目前已经支持的P2P引擎包括CNCF的Dragonfly和Uber的Kraken。
$ export DOCKER_CONTENT_TRUST=1
$ export DOCKER_CONTENT_TRUST_SERVER=https://
Harbor对旧式的Helm V2 chart的支持是通过chartmuseum来实现的,其签名机制保持了和Helm社区一致的形式,即通过GPG key的模式。在打包chart时,添加—sign和—key来生成包含有签名内容的prov文件,之后通过Harbor的web界面或者helm V2的push 插件随chart的tgz包一同上传到Harbor。Harbor会识别文件以展示chart是否被签过名。之后在使用时,可以对内容进行校验。
Harbor支持对镜像制品进行漏洞扫描。考虑到用户对扫描引擎有不同的偏好或者已经投入了特定的扫描引擎,Harbor通过插件式的方式可以对接多种不同的扫描引擎来实现对其所管理的镜像制品的漏洞扫描能力。目前已经支持的扫描引擎包括 Clair、Trivy、Aqua CSP、Anchore、Sisdig、小佑DoSec以及探真扫描器等,具体列表可以参考Scanner adapters。未来会支持更多诸如恶意软件,非法配置以及BOM等形式的扫描。
Tag保留机制基于用户设置的规则计算出需要保留的镜像tag,而不在保留列表里的tag则会被清除。用户可以设置最多15条规则,每条规则可以独立定义过滤器和诸如“保留最近拉取的#个镜像”或者“保留最近#天内被拉取的镜像”的附件条件。这里需要提到的是,之前提到的不可变镜像tag是不会被清理的。另外,每次清理或者保留的tag列表会在每次规则执行的文本日志里保留。Tag的清理不会释放存储资源,但是会释放配额。
清理后端的无用存储数据则需要GC垃圾回收机制。Harbor支持在线垃圾回收,用户可通过Harbor的管理界面来触发或者设置定时循环触发。每次GC执行的具体信息会被记录在执行记录的文本日志里,这些信息包含总共分析了多少数据,释放了多少数据。在2.1版本之前,GC的运行时阻塞式的,即GC运行时系统处于只读状态,不允许任何写操作进行。2.1之后实现非阻塞式GC模式,GC过程依然支持推送新镜像到Harbor。
要使用Harbor搭建高可用的镜像仓库服务,无论是那种部署模式,基本可以从基于Harbor的镜像复制功能或者使用共享服务/存储两个角度考虑。具体内容可以参阅《Harbor权威指南》这本书的相关章节。
Harbor自身也具有很强的扩展能力,可以支持不同场景下的集成需求。这些扩展能力可以总结为以下几点:
-
基于Swagger的完善Rest API,很容易构建API客户端来实现API的集成。
-
支持AD/LDAP/OIDC,可以实现用户系统的对接。
-
插件化的漏洞扫描机制,扫描引擎vendor可以基于扫描器API规范实现与Harbor的集成。
-
P2P提供商可以通过实现特定的接口规范来完成与Harbor的集成。
-
第三方镜像仓库可以通过实现特定的复制适配器接口规范来实现与Harbor的互操作。
-
对于符合OCI规范的制品,可以通过预先定义的OCI annotation来实现元数据的扩展识别,进而使得Harbor API和web界面支持对特定元数据的识别和渲染。
-
Harbor从版本2.2开始开放了相关的系统和业务监控参数,可以方便的实现特定监控平台对Harbor的接入和监控,方便日常运维工作。
之后的版本,Harbor会重点关注:
-
发布针对Kubernetes平台部署的harbor operator
-
支持更多组件的监控参数暴露
-
组建性能工作组来不断解决Harbor中遇到的性能问题并实现持续改进
-
P6网络的支持
-
更强大的安全扫描与审查机制
-
组建多架构工作组以实现在非X86 CPU架构平台上(ARM、AMD和龙芯)构建运行Harbor服务
-
响应更多其他来自于用户和社区的需求
Harbor一致致力于构建开放、透明和活跃的社区,欢迎大家积极参与到社区中,共同努力并推动Harbor项目不断向前发展。大家可以通过多种途径联系社区和参与进来:
-
CNCF workspace下的slack channel:#harbor与#harbor-dev
-
公开邮件组:lists.cncf.io/g/harbor-users 和lists.cncf.io/g/harbor-dev
-
Twitter:@project_harbor
-
双周社区例会:双周周三晚21:00点 zoom https://zoom.us/j/734959521拨入。会议邀请会发送到slack channel和邮件组。
-
Demo环境: demo.goharbor.io, 自助注册账户进入。
下面是Harbor公众号,欢迎大家关注!