- Harbor功能介绍
Harbor 的功能主要包括四大类：多用户的管控（基于角色访问控制和项目隔离）、镜像管理策略（存储配额、制品保留、漏洞扫描、来源签名、不可变制品、垃圾回收等）、安全与合规（身份认证、扫描和CVE例外规则等）和互操作性（Webhook、内容远程复制、可插拔扫描器、REST API、机器人账号等）。
Harbor实现了以项目为单位的资源逻辑隔离体系，基于项目实现RBAC访问控制和配额管理。用户对项目资源的访问是基于其在此项目中所被指派的角色。目前Harbor提供了多个预定义的角色，访客、开发者、维护者，项目管理员以及系统管理员，权限从低到高逐级递进。
另外，需要特别提到的是，因为是逻辑隔离，在后端实际存储中还是共享空间的，这样避免镜像的数据层重复存储，有效降低存储空间大小。
Harbor也支持多种用户系统，默认支持内嵌的数据库用户系统，同时也支持对接AD/LDAP系统以及通过一致的OIDC机制对接其它用户系统提供商。
同时，考虑到CI/CD场景，也提供了项目层面的机器人账号，方便CI/CD中的集成使用。在发布不久的Harbor 2.2版本中，对机器人账号也做了很大的增强。
镜像仓库的一个关键功能就是实现镜像的分发。Harbor在镜像分发方面，除了常规的镜像推送和拉取能力外，还提供了多种有效的机制和方法供用户来应对不同的场景需要。例如：
基于策略的镜像复制机制：可以帮助用户实现将源仓库中的特定镜像集合在指定的条件下复制到目标镜像仓库中。在复制策略中，除了指定源仓库或者目标仓库之外，可以指定多种过滤器(镜像库、tag和标签）与多种触发模式（手动，基于时间以及定时）且实现对推送（将镜像从源仓库推送至目标仓库）和拉取（将目标仓库的镜像拉取到当前仓库）两种模式的支持。首次复制为全量复制，之后会实现增量复制以提升效率。目前Harbor的复制功能已经支持包含Docker Hub、Quay、GCR、ECR等在内的十多种第三方镜像仓库。
基于复制功能：可以构建主从或者中心-边缘的多层分发体系，以实现镜像内容的高效和稳定的分发。例如镜像推送至中心 Harbor 仓库，然后复制到其它地理位置上的边缘仓库，容器运行时可从就近的边缘仓库拉取。
复制还可以解决非实时的复制能力，对于实时场景，Harbor实现项目级别的缓存机制。在创建项目时，可以启用项目的缓存机制。这样在拉取镜像时，如果项目中不存在，则由适配器将请求代理到项目所配置的上游仓库中来响应此次拉取的请求，同时将镜像缓存到项目中，下次再请求此镜像时，则可直接响应请求。缓存到项目的镜像与“本地”镜像没有差异，相关的管理策略可以应用到缓存的镜像上，比如配额、扫描等。目前支持的缓存代理的上游仓库除了其它Harbor之外，还支持Docker Hub、GCR、ECR以及quay，未来会根据需求来验证更多第三方仓库支持（缓存代理与内容复制共享相同的适配器）。
Harbor是镜像仓库,本身不支持P2P协议。但是可以与其它P2P提供者实现集成，进而利用P2P vendor能力实现镜像的加速。这就是Harbor的镜像预热功能。用户通过在特定项目中创建特定的预热策略，使用过滤器（repository和tag）来确定哪些镜像满足什么样的条件（是否签名，持有特定标签或者满足特定的漏洞状态）需要预热，在什么时候（就有事件或者基于定时）触发预热，将所选镜像提前从Harbor仓库传输到特定P2P引擎的缓存中，在有拉取请求时，P2P可以直接开始工作，不需要从上游仓库获取首份镜像内容。目前已经支持的P2P引擎包括CNCF项目的Dragonfly和Uber的Kraken。
Harbor作为镜像制品仓库，也提供了与镜像相关联的多种安全机制。通过引入开源的Notary框架实现了与DTR兼容的镜像制品签名机制。用户只要在Docker客户端设置环境变量,就可开启签名流程。另外，镜像制品是否被签名，也可以设置成为镜像安全策略之一，这样可以保证只有签名过的镜像制品才可以被拉取。
Harbor 支持对镜像制品进行漏洞扫描。考虑到用户对扫描引擎有不同的偏好或者已经投入了特定的扫描引擎，Harbor 通过插件式的方式可以对接多种不同的扫描引擎来实现对其所管理的镜像制品的漏洞扫描能力。目前已经支持的扫描引擎包括 Clair、Trivy、Aqua CSP、Anchore、Sisdig、小佑DoSec 以及探真扫描器等。未来会支持更多诸如恶意软件，非法配置以及BOM等形式的扫描。Harbor 基于上述插件式的扫描机制，可向用户提供特定镜像的漏洞报告总汇和漏洞详情列表，便于用户及时掌握镜像的漏洞状态。另外，基于这些漏洞状态信息，设置与扫描有关的安全策略，即只允许包含某级别以下的镜像被拉取，大大提升了运行时端的安全可靠性。
Harbor 也考虑到了在特定情况下，某些镜像tag具有一定的稳定性要求，不能被误覆盖，实现了不可变tag的安全机制。用户通过设置不可变tag的规则，使得满足这个规则的tag都进入不可变更的状态。
Harbor作为资源的管理储存平台，资源的清理和垃圾回收自然也不能缺席。结合镜像的管理模型和存储模型，Harbor提供了tag保留机制和垃圾回收两种能力。
Harbor支持在线垃圾回收，用户可通过Harbor的管理界面来触发或者设置定时循环触发。
Harbor自身也具有很强的扩展能力，可以支持不同场景下的集成需求。这些扩展能力可以总结为以下几点：
1）基于Swagger的完善Rest API，很容易构建API客户端来实现API的集成。
2）支持AD/LDAP/OIDC，可以实现用户系统的对接。
3）插件化的漏洞扫描机制，扫描引擎vendor可以基于扫描器API规范实现与Harbor的集成。
4）P2P提供商可以通过实现特定的接口规范来完成与Harbor的集成。
5）第三方镜像仓库可以通过实现特定的复制适配器接口规范来实现与Harbor的互操作。
6）Harbor从版本2.2开始开放了相关的系统和业务监控参数，可以方便的实现特定监控平台对Harbor的接入和监控，方便日常运维工作。 - Harbor高可用方案
根据前面的镜像管理方案，选择把kubevirt的虚拟机镜像制作成容器镜像，由harbor统一管理。为了保证harbor的稳定性与高性能，需解决harbor的高可用和数据存储。
Harbor的高可用方案，大体分两种：一种是基于复制策略的高可用；一种是基于共享存储的高可用。
2.1.基于复制策略的高可用
基本思想是多个Harbor实例使用Harbor原生的远程复制功能实现Artifact的一致性，通过负载均衡器实现多台服务器提供单一的Harbor服务。每个Harbor实例都有自已独立的PostgreSQL、Redis和存储。其架构简单，但是实时性不如基于共享存储的方案。架构如下：
镜像复制策略，还可以用于一主多从的镜像发布模式，满足大规模的集群下的镜像下载需求。该模式下，只需往一个harbor主实例发布镜像，就可以分发到各处的harbor从实例。各个docker节点再分散地从harbor从实例拉取镜像，可以有效把流量均衡到各harbor实例。
2.2.基于共享存储的高可用
共享后端存储是一种比较标准的方案，将多个Harbor实例共享PostgreSQL、Redis及存储，任何一个实例持久化到存储的镜像，都可被其他实例中读取。通过前置LB组件，如Keepalived，可以分流到不同的实例中去处理，从而实现负载均衡，也避免了单点故障。其架构如下：
在基于共享存储高可用架构下，Harbor的无状态的应用组件，例如portal、core、nginx等只需要增加其相应的副本数量即可；有状态的存储数据层面，提供高可用的Postgresql、redis集群，针对镜像和chart服务提供共享存储。
在大规模环境或跨区域情况下，可以部署多套基于共享存储的harbor高可用，结合harbor的复制功能，实现多集群的harbor高可用。
版权声明：本文内容系天翼云实名用户自发贡献，版权归原作者所有，天翼云开发者社区不拥有其著作权，亦不承担相应法律责任，未经许可，不得转载。
如有疑问或争议，请联系ctyunbbs@chinatelecom.cn删除。
0条评论
0 / 1000
