harbor调研

三月 02, 2020

前提：因为公司想要将线上服务统一使用K8s进行部署，那之前的tar安装包就成了images，因此要考虑新的存储方案。结合github信息和网友的使用经验，整理出了以下harbor信息。

开源镜像存储仓库
私有化的镜像部署
官方的说法是：Harbor是一个用于存储和分发Docker镜像的企业级Registry服务器。通过添加一些企业必需的功能特性，例如安全、标识和管理等，扩展了开源Docker Distribution。作为一个企业级私有Registry服务器，Harbor提供了更好的性能和安全。提升用户使用Registry构建和运行环境传输镜像的效率。

harbor存在的原因：

提供分层传输机制，优化网络传输
Docker镜像是是分层的，如果每次传输都使用全量文件显然不经济，所以用FTP的方式并不适合。必须提供识别分层传输的机制，以层的UUID为标识，确定传输的对象。
提供WEB界面，优化用户体验
只用镜像的名字来进行上传下载显然很不方便，需要有一个用户界面可以支持登陆、搜索功能，包括区分公有、私有镜像。
支持水平扩展集群
当有用户对镜像的上传下载操作集中在某服务器，需要对相应的访问压力作分解。上面这些就是Docker Registry所完成的主要工作，而Habor在此之上，又提供了用户、同步等诸多特性。
Harbor两个容易误解的点：
harbor功能
镜像的存储harbor使用的是官方的docker registry服务去完成，至于registry是用本地存储或者s3都是可以的，harbor的功能是在此之上提供用户权限管理、镜像复制等功能，提高使用的registry的效率。
镜像复制
通过docker registry 的API去拷贝，这种做法屏蔽了繁琐的底层文件操作、不仅可以利用现有docker registry功能不必重复造轮子，而且可以解决冲突和一致性的问题。
harbor的组件及功能：

组件
功能
proxy
nginx前端代理，主要分发前端页面ui访问、镜像上传下载流量
ui
提供了一个web管理页面，包括前端页面和后端API，底层使用mysql数据库
registry
镜像仓库，负责存储镜像文件，当镜像上传完毕后通过hook通知ui创建repository， registry的token认证通过ui组件完成
adminserver
系统的配置管理中心附带检查存储用量，ui和jobserver启动时候需要加载adminserver的配置
jobserver
负责镜像复制工作，和registry通信，从一个registry pull镜像push到另一个registry，并记录job log
log
日志汇总组件，通过docker的log-driver把日志汇总到一起

功能优点：
用户管理三种角色：在最高管理员权限系统管理员admin外还有，项目管理员 MDRWS 、开发人员 RWS 、访客 RS 、
项目管理：项目是一组镜像仓库的逻辑集合，是权限管理和资源管理的单元划分。一个项目下面有多个镜像仓库，并且关联多个不同角色的成员，镜像复制也是基于项目的，通过添加复制规则，可以将项目下面的镜像从一个harbor迁移到另一个harbor，通过日志可查看复制过程，并有retry机制。
配置管理、日志查询：配置管理主要是配置harbor的认证模式，企业内部使用，通常都是对接到公司LDAP上面，harbor也支持数据库认证，可以设置token的有效时间。用户对镜像的pull和push操作都可以被harbor记录下来。
优点：
本身自带 docker 私有仓库
支持基于角色的权限管理
支持 LDAP
安装环境：
支持k8s的helm安装和本地安装
需要安装docker并运行
docker-compose
docker engine
Harbor offline installer
redis
mysql
Openssl
要求：
最低配置要求2核4G40G
需要开放443 4443 80端口 https http
生产环境中建议使用https

应用：
我们在当前的企业应用中，Docker的镜像仓库配置成harbor，在容器启动是会拉取harbor中的镜像。在实际使用过程中，一个镜像库可能是不够用的，下例情况下我们可能会需要部署多个镜像仓库：
1. 国外的公有镜像下载过慢，需要一个中转仓库进行加速
2. 容器规模较大，一个镜像仓库不堪重负
3. 对系统稳定性要求高，需要多个仓库保证高可用性
4. 镜像仓库有多级规划，下级仓库依赖上级仓库
集群考虑：
一致性
实时性
可用性
应用场景的考虑：
1. 国内地区和海外地区的harbor统一还是分开、如果统一，优点、难点，如果分开，优点、难点
2. 国内业务和海外业务是否有关联性会互相影响
3.海外是否会受网络影响速度
海内外统一harbor：
优点：统一镜像管理、统一权限管理、节省服务器成本
难点：选择节点、节点之间通信、网络速度、项目管理
海内外harbor分开：
优点：集群架构简单、集群节点通信无阻碍、没有网络延迟问题
难点：集群分开管理
目标：容灾备份
目前有两种主流的方案解决这个问题：
双主复制
多harbor实例共享后端存储
双主复制：双主复制其实就是复用主从同步，实现两个harbor节点之间的双向同步，来保证数据的一致性，然后在两台harbor前端顶一个负载均衡器，将进来的请求分流到不同的实例中去，只要有一个实例中有了新的镜像，就自动的同步复制到另外的的实例中去，这样实现了负载均衡，也避免了单点故障，在一定程度上实现了Harbor的高可用性。
问题：可能会存在数据不一致问题，需要手动重启复制策略才能再次进行同步。
多harbor实例共享后端存储：共享后端存储算就是多个Harbor实例共享同一个后端存储，任何一个实例持久化到存储的镜像，都可被其他实例中读取。通过前置LB进来的请求，可以分流到不同的实例中去处理，这样就实现了负载均衡，也避免了单点故障。

在实际生产环境中部署需要考虑三个问题：

选取共享存储，Harbor的后端存储目前支持AWS S3、OSS 、Openstack Swift, Ceph等。
Session在不同的实例上共享，在最新的harbor中，默认session会存放在redis中，我们只需要将redis独立出来即可。可以通过redis sentinel或者redis cluster等方式来保证redis的可用性。
Harbor多实例数据库问题，将harbor中的数据库拆出来独立部署即可。让多实例共用一个外部数据库，数据库的高可用也可以通过数据库的高可用方案保证。
harbor高可用部署：
```
通过三个harbor完成高可用部署，通过负载均衡器对外提供服务，共享数据库与缓存。
```

github：https://github.com/goharbor/harbor/blob/v1.10.0/README.md
https://github.com/goharbor/harbor/blob/v1.10.0/docs/installation_guide.md
https://github.com/goharbor/harbor/tree/master/docs/1.10
demo： https://demo.goharbor.io/harbor/projects
参考文档：https://www.kubernetes.org.cn/1738.html
https://tonybai.com/2017/06/09/setup-a-high-availability-private-registry-based-on-harbor-and-cephfs/

查看评论