由于docker registry只提供了基本的镜像上传下载保存功能，在用户认证及鉴权、多用户管理、安全扫描、镜像清理、镜像同步等部分有所欠缺，因此如果要在公司内部使用镜像仓库，推荐使用harbor。
Harbor 2.0版本支持OCI（Open Container Initiative）镜像（如镜像、Helm Chart等）以及OCI镜像索引。镜像索引是一种high level manifest，指向一个manifest列表。通过镜像索引，可以根据client端的架构不同，自动下载对应架构的镜像。（创建多架构支持的镜像方法参考）
Harbor 2.0的整体架构如下图所示。
image.png
整个Harbor架构可以分为三层，分别为Consumer、Fundamental Service和Data Access Layer。
Consumer是Harbor的使用方。除了Harbor自带的前端界面（web portal）外，也可以通过其他client访问harbor，如kubelet、helm、docker等。
Fundamental Service模块较多，后面介绍。
Data Access Layer用于数据存储。主要有三块：
- 键值对存储： 使用的是Redis。redis主要用来进行registry缓存、session存储包括后期的helm chartmuseum缓存。
- 数据存储： 用于存储registry（镜像）和chart数据。支持对接块存储、文件存储和对象存储。
- 数据库： 使用的是PG，存储Harbor使用到的各个表。包括projects, users, roles, replication policies, tag retention policies, scanners, charts, images等
下面介绍下Fundamental Service的各个组成模块。
Harbor自带的模块主要有以下几个：
- Core： Core模块包含较多子模块，每个模块中也有自己的子模块。
- API Server： 接收Rest 请求，并通过子模块处理后返回结果。
- Authentication & Authorization
- Authentication服务：通过本地数据库、AS/LDAP或OIDC对请求进行Authentication（登陆认证）
- Authorization服务：对action进行RBAC鉴权，如pull/push镜像。
- Token Service：根据用户对project的权限，签发不同的token用于push/pull等操作。如果docker client发送的请求不含token，Registry会将请求重定向到token服务。
- MiddleWare： 中间件用于请求的预处理，确定请求是否需要转发到后端。包含的预处理功能有“quota management”， “signature check”， “vulnerability severity check”和“robot account parsing”等。
- API Handlers： 解析、验证请求参数，根据相应的API controller完成业务逻辑处理，并生成相应的响应。
- Authentication & Authorization
- Config Manager： 系统配置管理。
- Project Management： 管理Project(namespace)。
- Quota Manager: 管理Project的quota配额。
- Chart Controller： 转发chart相关的处理请求到后端
chartmuseum。提供了一些扩展来优化chart管理。 - Retention Manager：管理tag回收（保留）策略，并执行和监控。
- Content Trust： 方便使用Notary功能的一个扩展（插件）。
- Replication Controller： 管理镜像复制（备份）策略，并执行和监控；适配不同registry。当前适配的registry有docker registry、Docker hub、Huawei SWR等，参考架构图。
- Scan Manager： 镜像扫描，提供扫描结果。支持对接Trivy，Clairs等。
- Notification Manager：webhook回调管理。支持HTTP POST请求和Slack channel。
- OCI Artifact Manager：提供OCI制品的全生命周期管理（CRUD）。包括安全扫描报告、镜像构建历史等镜像元数据及额外信息的管理；helm charts的readme、dependencies、value.yaml文件管理；制品的Tag管理等。
- Registry Driver： 与底层的registry（目前是docker registry）进行通信的registry client SDK。OCI Artifact Manager需要通过该组件获取制品的manifest及Config JSON等信息。
- API Server： 接收Rest 请求，并通过子模块处理后返回结果。
- GC controller： GC。删除镜像后，需要通过GC将存储空间释放。
- Log Collector： 日志记录。
- Job Service： 异步任务处理。如镜像定时扫描等。
依赖的外部模块有：
- Proxy：提供代理服务，使用的是Nginx，将consumer的请求代理转发到后端的各个模块。
- Notary：Notary 是一套镜像的签名工具， 用来保证镜像层在 pull、push、transfer 过程中的一致性和完整性。避免中间人攻击，阻止非法的镜像更新和运行。镜像层的创建者可以对镜像层做数字签名，生成摘要，保存在 Notary 服务中。开启 Content Trust 机制之后，未签名的镜像无法被拉取。
关于notary的详细功能见： https://github.com/zj1244/Blog/blob/master/2019/harbor%E7%9A%84Notary%E5%8A%9F%E8%83%BD%E6%B5%8B%E8%AF%95.md
- Chart Museum：用于保存helm chart镜像的组件。
-
Docker Distribution（docker registry）：harbor本身不提供镜像上传/下载等功能，相关功能是通过调用docker registry的API实现的。因此，需要依赖到docker registry服务。
另外支持对接一些外部模块，如镜像扫描使用的Clair和Trivy，镜像备份使用的Docker Distribution、Docker Hub等。
docker login的过程
- Proxy在80端口接收到请求，并转发给Registry container。
- Registry container需要token-based authentication。会返回401，并告诉client从指定的URL（指向token service）获取token。
- docker client发送请求到token service。（请求头中包含username和password，用于HTTP的basic authentication）
- proxy在80端口接收到请求后，会将请求转发到UI container中（UI container中包含token service）。token service接收到请求后，获取其中的username和password。
- token service将username和password在数据库或者是LDAP/AD等服务中进行authentication。成功后，返回一个HTTP状态码表示认证成功，并将通过私钥生成的token放在返回的body中。
- docker client接收到成功的返回后，将用户名密码编码后保存在本地的文件中。
docker push镜像过程。
docker push xxx/library/hello-world
- 首先，同登陆一样，docker client会发送请求，并拿到token service的URL。
- 然后，docker client向token service发送请求，除了用户名密码外，在请求中还会提供一些额外信息（action为push，resource为library/hello-world）。
- token service查询数据库，获取用户绑定的角色（role），查看是否有权限进行push镜像。有权限则编码push操作对应的信息，并使用私钥签发token给docker client。
- docker client发送push请求到registry，并在header中带上token。registry使用公钥解码token后，验证内部信息。如果验证通过，则开始上传流程。
如果需要临时访问密钥，则可以用harbor的私钥签发一个带有时效的token即可。
