Harbor企业级实践丨零侵入改造！

本文作者 / 阿杜

玩Docker，玩K8s，玩Harbor

爱技术，爱运动，爱生活

“K8s＆云原生技术开放日”特邀讲师

在上一篇中，我们分享了Harbor存储选型，Harbor高并发压测以及Harbor备份还原方案。本次分享将围绕着Harbor的零侵入改造展开，依次介绍：Harbor API无侵入改造，Harbor认证&鉴权 无侵入改造以及Harbor高可用方案……

——阿杜

harbor API无侵入改造

Harbor支持丰富的RESTFUL API接口。企业平台可以调用这些API完成绝大多数的需求，但是随着需求复杂度的增加，这些API就不能完全满足企业的需求了。比如：Harbor只提供获取指定Project对应的Repository查询接口，但是企业可能需要在不指定Project的情况下获取相应查询字段的Repository接口，类似这种情况下，Harbor API接口就显得不够用了，那么如何适配业务的这些需求？

这里有两种方式进行适配：

• Internal：通过修改Harbor内部代码，修改和添加Harbor API接口，实现API适配
• External：Harbor外部添加一个适配器，所有适配操作通过Adapter来进行，无需修改Harbor

这两种方式各有优缺点：

• Internal
  • 优点：直接，效率高
  • 缺点：修改了Harbor源码，对于Harbor的升级来说不易维护
• External
  • 优点：对Harbor零侵入，易于Harbor的升级维护
  • 缺点：多了一个中转和拼接，效率差；有些添加、修改Harbor原有表结构并对这些结构操作的API不适合这种方式

在对比了这两种方式的优缺点后，我们选择用第二种方式进行适配，原因很简单：在允许一定效率损失的情况下，通过Harbor Adapter无侵入改造Harbor API，对Harbor更加友好，有利于Harbor的升级与维护。

harbor认证&鉴权 无侵入改造

Harbor对认证和鉴权支持得比较完善。Harbor主要支持三种认证方式：

• Database(PostgreSQL)——Users are stored in the local database
• LDAP——Under this authentication mode, users whose credentials are stored in an external LDAP or AD server can log in to Harbor directly.
• OIDC Provider——With this authentication mode, regular user will login to Harbor Portal via SSO flow.

Harbor的鉴权也即RBAC是基于Project的，用户对Project可以有不同的角色并对应不同的权限，例如：

• Guest——读权限，可以下载镜像
• Developer——读写权限，可以下载和上传镜像
• Admin——管理权限，除了下载和上次镜像外，还具有管理该Project下用户的权限

虽然Harbor支持完善的认证和鉴权机制，但是企业内部一般都有自己定制的认证和鉴权逻辑，而这些特殊逻辑是无法通过Harbor现有的方式来兼容的，那么问题来了：如何在不修改Harbor的情况下适配企业级的认证&鉴权？

这里我们分两部分对Harbor认证&鉴权无侵入改造方案进行介绍：

1、API无侵入认证&鉴权

将认证&鉴权逻辑从Harbor内部抽取到外部，由上层完成。也即：产品平台根据认证中心进行认证和鉴权，权限通过后，通过admin账号调用Harbor API执行相关操作，执行成功后，将相应的RBAC信息写入数据库：

2、Docker cmd无侵入认证&鉴权

这里Docker cmd的无侵入改造方案利用了Docker Token的六次握手协议，如下：

通过配置外部认证服务器auth server，走认证中心进行统一的认证和鉴权，并产生相应的token给Docker，最终实现Docker cmd无侵入认证&鉴权方案：

这里在讲完harbor API无侵入改造和harbor认证&鉴权 无侵入改造的方案后，我们还需要再补充说明一点：虽然上述方案可以满足企业二次定制的一般情况，但是如果遇到无法通过非侵入改造的情况，那么就只能修改Harbor了，这里保留一个原则即可：尽量不改动Harbor内部逻辑，实在不行那也必须对Harbor进行代码定制。

harbor高可用方案落地

我们将Harbor组件按照有无状态分为两部分，针对这两部分分别设计高可用策略：

• 无状态组件：可直接将实例数目设置>1来实现高可用
• 有状态组件：需要专门研究高可用方案

这里我们对有状态组件：Redis进行展开说明。由于Redis在Harbor中只是起到缓存作用，数据量少，比较合适用Redis主从模式，所以我们需要对这种模式进行高可用适配。按照官方推荐的哨兵方式，我们部署了Redis一主两从+三哨兵的高可用集群：

但是这里还存在一个问题：由于Harbor并不支持Redis哨兵协议，为了让Harbor更加透明地访问Redis，需要部署Redis的智能代理服务：

这样便实现了Harbor的高可用。

harbor展望

未来镜像P2P方案是Harbor的主要工作方向，目前Harbor还不支持该方案，希望不久的将来Harbor将支持镜像P2P特性来实现更大程度的并发拉取性能。

猜你还想看这些内容

●Harbor企业级实践丨20倍性能提升so easy!

●Ceph Bulestore磁盘空间分配初探

●Kustomize上篇丨Helm 和 Kustomize：不只是含谷量的区别

●Kustomize下篇丨Kustomize 中的增删改查

· END ·

记得文末点个好看鸭~

点就完事儿了！