Go 开源说第七期：Harbor助你玩转云原生

本文由“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、机器人帐号等）。

 

Harbor提供了多种途径来帮助用户快速搭建Harbor镜像仓库服务，包括：

• 离线安装包：经过docker-compose编排运行。安装包除了包含相关的安装脚本外，还包含了全部安装所须要的Harbor组件镜像，能够在离线环境下安装使用。

• 在线安装包：与离线安装包相似，惟一的区别就是不包含harbor组件镜像，安装时镜像须要从网络上的仓库服务拉取。

• Helm Chart：

  经过Helm的方式将Harbor部署到目标的Kubernetes集群中。

  目前仅覆盖Harbor自身组件的部署安装,其所依赖的诸如数据库、Redis缓存以及可能的存储服务须要用户本身负责。

• Kubernetes Operator：

  基于Kubernetes Operator框架编排部署，重点关注all-in-one的HA部署模式的支持。

  目前还处于开发中，很快就会发布。

   

接下来，咱们深刻了解一下Har bor 所提供的核心功能。

 

首先就是Harbor的资源隔离与多租户体系，以下图所示。

Harbor实现了以项目为单位的资源逻辑隔离体系，基于项目实现RBAC访问控制和配额管理。用户对项目资源的访问是基于其在此项目中所被指派的角色。目前Harbor提供了多个预约义的角色，访客、开发者、维护者，项目管理员以及系统管理员，权限从低到高逐级递进，具体详情可参见： 角色权限集合 （https://goharbor.io/docs/2.2.0/administration/managing-users/user-permissions-by-role/） 。另外，须要特别提到的是，由于是逻辑隔离，在后端实际存储中仍是共享空间的，这样避免镜像的数据层重复存储，有效下降存储空间大小。

 

Harbor也支持多种用户系统，默认支持内嵌的数据库用户系统，同时也支持对接AD/LDAP系统以及经过一致的OIDC机制对接其它用户系统提供商，社区验证过的提供商能够参考  OIDC adapters （https://goharbor.io/docs/2.2.0/install-config/harbor-compatibility-list/） 。同时，考虑到CI/CD场景，也提供了项目层面的机器人帐号，方便CI/CD中的集成使用。

 

在刚发布不久的Harbor  2.2 版本中，对机器人帐号也作了很大的加强。

提供了新的系统级别的机器人帐号以支持经过一组受权来覆盖多个项目。同时，支持更多类型的权限来受权不一样的操做和API调用。另外，相对于以前的jwt令牌方式，新的方式带来更大的灵活性(即便受权范围或者过时时间发生变化，密码依然有效）。更多详情能够参考系  统级机器人帐号的设计提议 （https://github.com/goharbor/community/pull/148） 。

 

  镜像仓库的一个关键功能就是实现镜像的分发。 Harbor在镜像分发方面，除了常规的镜像推送和拉取能力外，还提供了多种有效的机制和方 法供用户来应对不一样的场景须要。

 

基于策略的镜像复制机制，能够帮助用户实现将源仓库中的特定镜像集合在指定的条件下复制到目标镜像仓库中。在复制策略中，除了指定源仓库或者目标仓库以外，能够指定多种过滤器(镜像库、tag和标签）与多种触发模式（手动，基于时间以及定时）且实现对推送（将镜像从源仓库推送至目标仓库）和拉取（将目标仓库的镜像拉取到当前仓库）两种模式的支持。首次复制为全量复制，以后会实现增量复制以提高效率。目前Harbor的复制功能已经支持包含Docker Hub、Quay、GCR、ECR等在内的十多种第三方镜像仓库，具体列表可参考 Replicaiton adpaters（https://goharbor.io/docs/2.2.0/install-config/harbor-compatibility-list/）。

 

基于复制功能，可有构建主从或者中心-边缘的多层分发体系，以实现镜像内容的高效和稳定的分发。以下图所示。镜像推送至中心Harbor仓库，而后复制到其它地理位置上的边缘仓库，容器运行时可从就近的边缘仓库拉取。

复制能够解决非实时的复制能力，对于实时场景，Harbor实现项目级别的缓存机制。在建立项目时，能够启用项目的缓存机制。这样在拉取镜像时，若是项目中不存在，则由适配器将请求代理到项目所配置的上游仓库中来响应这次拉取的请求，同时将镜像缓存到项目中，下次再请求此镜像时，则可直接响应请求。缓存到项目的镜像制品与“本地”镜像制品没有差别，相关的管理策略能够应用到缓存的镜像上，好比配额、扫描等。目前支持的缓存代理的上游仓库除了其它Harbor以外，还支持Docker  Hub 、G CR 、 ECR 以及quay，将来会根据需求来验证更多第三方仓库支持（缓存代理与内容复制共享相同的适配器）。在建立项目时选择启用缓存功能则新建项目为缓存项目，不可推送；以建立的普通项目没法直接转为缓存项目。另外，使用缓存镜像的路径有特定的模式， docker   pull   <harbor-host>/[cache_project_name]/<repository_path> （ docker   pull   goharbor.io/my_cache_pro/library/nginx:latest)。

在进行大量部署的时候，对仓库的镜像拉取请求会产生井喷，进而形成比较重的负担。而这其中可能有不少重复的镜像请求，这样也就形成更多的没必要要的资源和流量浪费。P2P网络能够加速内容的分发，天然也能够加速镜像的分发。由于P2P的特质，内容可来源于其它peer节点，这样能够有效地减小对上游仓库的请求。Harbor是镜像仓库,自己不支持P2P协议。可是能够与其它P2P提供者实现集成，进而利用P2P vendor能力实现镜像的加速。这就是Harbor的镜像预热功能。用户经过在特定项目中建立特定的预热策略，使用过滤器（repository和tag）来肯定哪些镜像知足什么样的条件（是否签名，持有特定标签或者知足特定的漏洞状态）须要预热，在何时（就有事件或者基于定时）触发预热，将所选镜像提早从Harbor仓库传输到特定P2P引擎的缓存中，在有拉取请求时，P2P能够直接开始工做，不须要从上游仓库获取首份镜像内容。目前已经支持的P2P引擎包括CNCF的Dragonfly和Uber的Kraken。

安全已经成为云原生关注的要点之一，同时也是平台的第一要务。Harbor做为镜像制品仓库，也提供了与镜像相关联的多种安全机制，这也是Harbor很重要的特色之一。

 

H arbor经过引入开源的Notary框架实现了与D TR 兼容的镜像制品签名机制。用户只要在 D ocker客户端设置如下环境变量,就可开启签名流程 :

$ export DOCKER_CONTENT_TRUST=1

$ export DOCKER_CONTENT_TRUST_SERVER=https://<harbor主机地址>:4443

以后在拉取使用镜像时，会对内容进行校验。

镜像制品是否被签名，也能够设置成为镜像安全策略之一，这样能够保证只有签名过的镜像制品才能够被拉取。

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等形式的扫描。

H arbor基于上述插件式的扫描机制，可向用户提供特定镜像的漏洞报告总汇和漏洞详情列表，便于用户及时掌握镜像的漏洞状态。另外，基于这些漏洞状态信息，设置与扫描有关的安全策略，即只容许包含某级别如下的镜像被拉取，大大提高了运行时端的安全可靠性。

H arbor也考虑到了在特定状况下，某些镜像tag具备必定的稳定性要求，不能被误覆盖，实现了不可变tag的安全机制。用户经过设置不可变tag的规则，使得知足这个规则的tag都进入不可变动的状态。

做为资源的管理储存平台，资源的清理和垃圾回收天然也不能缺席。结合镜像的管理模型和存储模型，Harbor提供了tag保留机制和垃圾回收两种能力。

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中遇到的性能问题并实现持续改进

• IPV6网络的支持

• 更强大的安全扫描与审查机制

• 组建多架构工做组以实如今非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公众号，欢迎你们关注！

本文分享自微信公众号 - GoCN（golangchina）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。