Docker容器应用的开发和运行离不开可靠的镜像管理，虽然Docker官方也提供了公共的镜像仓库，但是从安全和效率等方面考虑，部署我们私有环境内的Registry
也是非常必要的。之前介绍了Docker私有仓库Registry，这里介绍另一款企业级Docker镜像仓库Harbor的部署和使用，在Kubernetes集群中，推荐使用Harbor仓库环境。
一、Harbor仓库介绍
我们在日常Docker容器使用和管理过程中，渐渐发现部署企业私有仓库往往是很有必要的, 它可以帮助你管理企业的一些敏感镜像, 同时由于Docker Hub的下载速度和GFW的原因, 往往需要将一些无法直接下载的镜像导入本地私有仓库. 而Harbor就是部署企业私有仓库的一个不二之选。
Harbor是由VMware公司开源的企业级的Docker Registry管理项目，Harbor主要提供Dcoker Registry管理UI，提供的功能包括：基于角色访问的控制权限管理(RBAC)、AD/LDAP集成、日志审核、管理界面、自我注册、镜像复制和中文支持等。Harbor的目标是帮助用户迅速搭建一个企业级的Docker registry服务。它以Docker公司开源的registry为基础，额外提供了如下功能:
-> 基于角色的访问控制(Role Based Access Control)
-> 基于策略的镜像复制(Policy based image replication)
-> 镜像的漏洞扫描(Vulnerability Scanning)
-> AD/LDAP集成(LDAP/AD support)
-> 镜像的删除和空间清理(Image deletion & garbage collection)
-> 友好的管理UI(Graphical user portal)
-> 审计日志(Audit logging)
-> RESTful API
-> 部署简单(Easy deployment)
Harbor的所有组件都在Dcoker中部署，所以Harbor可使用Docker Compose快速部署。需要特别注意：由于Harbor是基于Docker Registry V2版本，所以docker必须大于等于1.10.0版本，docker-compose必须要大于1.6.0版本！
二、Harbor仓库结构
Harbor的每个组件都是以Docker容器的形式构建的，可以使用Docker Compose来进行部署。如果环境中使用了kubernetes，Harbor也提供了kubernetes的配置文件。
Harbor大概需要以下几个容器组成：ui(Harbor的核心服务)、log(运行着rsyslog的容器，进行日志收集)、mysql(由官方mysql镜像构成的数据库容器)、Nginx(使用Nginx做反向代理)、registry(官方的Docker registry)、adminserver(Harbor的配置数据管理器)、jobservice(Harbor的任务管理服务)、redis(用于存储session)。
Harbor是一个用于存储和分发Docker镜像的企业级Registry服务器，整体架构还是很清晰的。下面借用了网上的架构图:
Harbor依赖的外部组件
-> Nginx(即Proxy代理层): Nginx前端代理，主要用于分发前端页面ui访问和镜像上传和下载流量; Harbor的registry,UI,token等服务，通过一个前置的反向代理统一接收浏览器、Docker客户端的请求，并将请求转发给后端不同的服务。
-> Registry v2: 镜像仓库，负责存储镜像文件; Docker官方镜像仓库, 负责储存Docker镜像，并处理docker push/pull命令。由于我们要对用户进行访问控制，即不同用户对Docker image有不同的读写权限，Registry会指向一个token服务，强制用户的每次docker pull/push请求都要携带一个合法的token, Registry会通过公钥对token进行解密验证。
-> Database(MySQL或Postgresql)：为core services提供数据库服务，负责储存用户权限、审计日志、Docker image分组信息等数据。
Harbor自有组件
-> Core services(Admin Server): 这是Harbor的核心功能，主要提供以下服务：
-> UI：提供图形化界面，帮助用户管理registry上的镜像（image）, 并对用户进行授权。
-> webhook：为了及时获取registry 上image状态变化的情况， 在Registry上配置webhook，把状态变化传递给UI模块。
-> Auth服务：负责根据用户权限给每个docker push/pull命令签发token. Docker 客户端向Regiøstry服务发起的请求,如果不包含token，会被重定向到这里，获得token后再重新向Registry进行请求。
-> API: 提供Harbor RESTful API
-> Replication Job Service：提供多个 Harbor 实例之间的镜像同步功能。
-> Log collector：为了帮助监控Harbor运行，负责收集其他组件的log，供日后进行分析。
再来仔细看下Harbor主要组件和数据流走向：
-> proxy，它是一个nginx前端代理，主要是分发前端页面ui访问和镜像上传和下载流量，上图中通过深蓝色先标识；
-> ui提供了一个web管理页面，当然还包括了一个前端页面和后端API，底层使用mysql数据库；
-> registry是镜像仓库，负责存储镜像文件，当镜像上传完毕后通过hook通知ui创建repository，上图通过红色线标识，当然registry的token认证也是通过ui组件完成；
-> adminserver是系统的配置管理中心附带检查存储用量，ui和jobserver启动时候回需要加载adminserver的配置，通过灰色线标识；
-> jobsevice是负责镜像复制工作的，他和registry通信，从一个registry pull镜像然后push到另一个registry，并记录job_log，上图通过紫色线标识；
-> log是日志汇总组件，通过docker的log-driver把日志汇总到一起，通过浅蓝色线条标识。
Harbor的误区
误区一: Harbor是负责存储容器镜像的 (Harbor是镜像仓库，那么它就应当是存储镜像的)
其实关于镜像的存储，Harbor使用的是官方的docker registry服务去完成，至于registry是用本地存储或者s3都是可以的，Harbor的功能是在此之上提供用户权限管理、镜像复制等功能，提高使用的registry的效率。
误区二：Harbor镜像复制是存储直接复制 (镜像的复制，很多人以为应该是镜像分层文件的直接拷贝)
其实Harbor镜像复制采用了一个更加通用、高屋建瓴的做法，通过docker registry 的API去拷贝，这不是省事，这种做法屏蔽了繁琐的底层文件操作、不仅可以利用现有docker registry功能不必重复造轮子，而且可以解决冲突和一致性的问题。
Harbor的部署
这里不建议使用kubernetes来部署, 原因是镜像仓库非常重要, 尽量保证部署和维护的简洁性, 因此这里直接使用compose的方式进行部署。官方提供3种部署Harbor的方式:
1）在线安装: 从Docker Hub下载Harbor的镜像来安装, 由于Docker Hub比较慢, 建议Docker配置好加速器。
2）离线安装: 这种方式应对与部署主机没联网的情况使用。需要提前下载离线安装包: harbor-offline-installer-.tgz 到本地
3）OVA安装: 这个主要用vCentor环境是使用
后面部署时会为Docker配置镜像加速器, 因此会采用在线部署的方式, 部署步骤如下：
-> 下载Harbor最新的在线安装包
-> 配置Harbor (harbor.cfg)
-> 运行install.sh来安装和启动Harbor
-> Harbor的日志路径:/var/log/harbor
Harbor仓库部署的官方要求的最小系统配置
-> 2个cpu
-> 4g内存
-> 40g硬盘，因为是存储镜像的所以推荐硬盘大点。
参考
Harbor GitHub
Harbor 安装手册
Harbor 用户手册
辅助工具)
