企业级Registry开源项目Harbor架构简介

xman

VMware公司最近开源了企业级Registry项目Harbor，其的目标是帮助用户迅速搭建一个企业级的Dockerregistry服务。它以Docker公司开源的registry为基础，提供了管理UI,基于角色的访问控制(RoleBasedAccessControl)，AD/ ...

企业级Registry开源项目Harbor架构简介 　　作者：张海宁姜坦 　　1.Harbor项目 　　VMware公司最近开源了企业级Registry项目Harbor，其的目标是帮助用户迅速搭建一个企业级的Dockerregistry服务。它以Docker公司开源的registry为基础，提供了管理UI,基于角色的访问控制(RoleBasedAccessControl)，AD/LDAP集成、以及审计日志(Auditlogging)等企业用户需求的功能，同时还原生支持中文，对广大中国用户是一个好消息。本文将介绍Harbor项目的主要组件，并阐述Harbor的工作原理。 　　2.架构介绍 　　1)主要组件 　　Harbor在架构上主要由五个组件构成： 　　Proxy：Harbor的registry,UI,token等服务，通过一个前置的反向代理统一接收浏览器、Docker客户端的请求，并将请求转发给后端不同的服务。 　　Registry：负责储存Docker镜像，并处理Dockerpush/pull命令。由于我们要对用户进行访问控制，即不同用户对Dockerimage有不同的读写权限，Registry会指向一个token服务，强制用户的每次Dockerpull/push请求都要携带一个合法的token,Registry会通过公钥对token进行解密验证。 　　Coreservices：这是Harbor的核心功能，主要提供以下服务： 　　o　UI：提供图形化界面，帮助用户管理registry上的镜像（image）,并对用户进行授权。 　　o　webhook：为了及时获取registry上image状态变化的情况，在Registry上配置webhook，把状态变化传递给UI模块。 　　o　token服务：负责根据用户权限给每个Dockerpush/pull命令签发token.Docker客户端向Regi?stry服务发起的请求,如果不包含token，会被重定向到这里，获得token后再重新向Registry进行请求。 　　Database：为coreservices提供数据库服务，负责储存用户权限、审计日志、Dockerimage分组信息等数据。 　　Logcollector：为了帮助监控Harbor运行，负责收集其他组件的log，供日后进行分析。 　　各个组件之间的关系如下图所示： 　　2)实现 　　Harbor的每个组件都是以Docker容器的形式构建的，因此很自然地，我们使用DockerCompose来对它进行部署。 　　在源代码中(https://github.com/vmware/harbor),用于部署Harbor的DockerCompose模板位于/Deployer/Docker-compose.yml.打开这个模板文件，会发现Harbor由5个容器组成： 　　１.proxy:由Nginx服务器构成的反向代理。 　　２.registry:由Docker官方的开源registry镜像构成的容器实例。 　　３.ui:即架构中的coreservices,构成此容器的代码是Harbor项目的主体。 　　４.mysql:由官方MySql镜像构成的数据库容器。 　　５.log:运行着rsyslogd的容器，通过log-driver的形式收集其他容器的日志。 　　这几个容器通过Dockerlink的形式连接在一起，这样，在容器之间可以通过容器名字互相访问。对终端用户而言，只需要暴露proxy（即Nginx）的服务端口。 　　工作原理下面以两个Docker命令为例，讲解主要组件之间如何协同工作。 　　1)Dockerlogin 　　假设我们将Harbor部署在IP为192.168.1.10的虚机上。用户通过Dockerlogin命令向这个Harbor服务发起登录请求： 　　Dockerlogin192.168.1.10当用户输入所需信息并点击回车后，Docker客户端会向地址“192.168.1.10/v2/”发出HTTPGET请求。Harbor的各个容器会通过以下步骤处理： 　　(a)首先，这个请求会由监听80端口的proxy容器接收到。根据预先设置的匹配规则，容器中的Nginx会将请求转发给后端的registry容器； 　　(b)在registry容器一方，由于配置了基于token的认证，registry会返回错误代码401，提示Docker客户端访问token服务绑定的URL。在Harbor中，这个URL指向CoreServices； 　　(c)Docker客户端在接到这个错误代码后，会向token服务的URL发出请求，并根据HTTP协议的BasicAuthentication规范，将用户名密码组合并编码，放在请求头部(header)； 　　(d)类似地，这个请求通过80端口发到proxy容器后，Nginx会根据规则把请求转发给ui容器，ui容器监听token服务网址的处理程序接收到请求后，会将请求头解码，得到用户名、密码； 　　(e)在得到用户名、密码后，ui容器中的代码会查询数据库，将用户名、密码与mysql容器中的数据进行比对（注：ui容器还支持LDAP的认证方式，在那种情况下ui会试图和外部LDAP服务进行通信并校验用户名/密码)。比对成功，ui容器会返回表示成功的状态码，并用密钥生成token，放在响应体中返回给Docker客户端。 　　这个过程中组件间的交互过程如下图所示: 　　至此，一次Dockerlogin成功地完成了，Docker客户端会把步骤(c)中编码后的用户名密码保存在本地的隐藏文件中。 　　2)Dockerpush 　　用户登录成功后用Dockerpush命令向Harbor推送一个Dockerimage： 　　Dockerpush192.168.1.10/library/hello-world(a)首先，Docker客户端会重复login的过程，首先发送请求到registry,之后得到token服务的地址； 　　(b)之后，Docker客户端在访问ui容器上的token服务时会提供额外信息，指明它要申请一个对imagelibrary/hello-world进行push操作的token； 　　(c)token服务在经过Nginx转发得到这个请求后，会访问数据库核实当前用户是否有权限对该image进行push。如果有权限，它会把image的信息以及push动作进行编码，并用私钥签名，生成token返回给Docker客户端； 　　(d)得到token之后Docker客户端会把token放在请求头部，向registry发出请求，试图开始推送image。Registry收到请求后会用公钥解码token并进行核对，一切成功后，image的传输就开始了。 　　我们省去proxy转发的步骤，下图描述了这个过程中各组件的通信过程：