CC00013.CloudDocker——|Cloud&Docker镜像.V05|——|Harbor架构|

一、 Harbor 原理说明：软件资源介绍

### --- 软件资源介绍

~~~     Harbor是 VMware公司开源的企业级 DockerRegistry项目，
~~~     项目地址为 https://github.com/vmware/harbor。
~~~     其目标是帮助用户迅速搭建一个企业级的 Dockerregistry服务。
~~~     它以 Docker公司开源的 registry为基础，
~~~     提供了管理 UI，基于角色的访问控制 (Role Based Access Control)， 
~~~     AD/LDAP集成、以及审计日志 (Auditlogging) 等企业用户需求的功能，同时还原生支持中文。 
~~~     Harbor的每个组件都是以 Docker容器的形式构建的，使用 Docker Compose来对它进行部署。
~~~     用于部署 Harbor的 Docker Compose模板位于 /Deployer/docker-compose.yml，
~~~     由 5个容器组成，这几个容器通过Docker link的形式连接在一起，
~~~     在容器之间通过容器名字互相访问。
~~~     对终端用户而言，只需要暴露 proxy ( 即Nginx)的服务端口

~~~     # Proxy：
~~~     由 Nginx 服务器构成的反向代理。
~~~     # Registry：
~~~     由 Docker官方的开源 registry 镜像构成的容器实例。
~~~     # UI：
~~~     即架构中的 core services， 构成此容器的代码是 Harbor 项目的主体。

~~~     # MySQL：
~~~     由官方 MySQL 镜像构成的数据库容器。
~~~     # Log：
~~~     运行着 rsyslogd 的容器，通过 log-driver 的形式收集其他容器的日志

二、Harbor 特性

### --- Harbor 特性

~~~     # 基于角色控制：
~~~     用户和仓库都是基于项目进行组织的， 而用户基于项目可以拥有不同的权限
~~~     # 基于镜像的复制策略：
~~~     镜像可以在多个 Harbor实例之间进行复制
~~~     # 支持 LDAP： 
~~~     Harbor的用户授权可以使用已经存在 LDAP用户

~~~     # 镜像删除 & 垃圾回收： 
~~~     Image可以被删除并且回收 Image占用的空间，绝大部分的用户操作 API， 方便用户对系统进行扩展
~~~     # 用户 UI：
~~~     用户可以轻松的浏览、搜索镜像仓库以及对项目进行管理

~~~     # 轻松的部署功能： 
~~~     Harbor提供了 online、 offline安装，除此之外还提供了 virtualappliance安装
~~~     # Harbor 和 docker registry 关系： 
~~~     Harbor实质上是对 docker registry 做了封装，扩展了自己的业务模块

三、Harbor 认证过程

### --- Harbor 认证过程

~~~     dockerdaemon从 docker registry拉取镜像。
~~~     如果 dockerregistry需要进行授权时， registry将会返回 401 Unauthorized响应，
~~~     同时在响应中包含了 docker client如何进行认证的信息。
~~~     dockerclient根据 registry返回的信息，向 auth server发送请求获取认证 token。
~~~     auth server则根据自己的业务实现去验证提交的用户信息是否存符合业务要求。
~~~     用户数据仓库返回用户的相关信息。
~~~     auth server将会根据查询的用户信息，生成 token令牌，
~~~     以及当前用户所具有的相关权限信息 .上述就是完整的授权过程 .
~~~     当用户完成上述过程以后便可以执行相关的 pull/push操作。
~~~     认证信息会每次都带在请求头中

四、Harbor 认证流程

### --- Harbor 认证流程

~~~     首先，请求被代理容器监听拦截，并跳转到指定的认证服务器。
~~~     如果认证服务器配置了权限认证，则会返回 401。
~~~     通知 dockerclient在特定的请求中需要带上一个合法的token。
~~~     而认证的逻辑地址则指向架构图中的 core services。
~~~     当 docker client接受到错误 code。 
~~~     client就会发送认证请求 (带有用户名和密码 )到 coreservices进行 basicauth认证。
~~~     当 C的请求发送给 ngnix以后， 
~~~     ngnix会根据配置的认证地址将带有用户名和密码的请求发送到 coreserivces。
~~~     coreservices获取用户名和密码以后对用户信息进行认证 
~~~     (自己的数据库或者介入 LDAP都可以 )。成功以后，返回认证成功的信息