为什么有了Docker registry还需要Harbor？-云计算-火龙果软件

捐助

为什么有了Docker registry还需要Harbor？

来源：EAWorld 发布于 2017-3-20

次浏览

一、Harbor的安全机制

二、Harbor的镜像同步

三、Harbor与K8s的集成实践

四、两个小贴士

五、总结

Habor是由VMWare公司开源的容器镜像仓库。事实上，Habor是在Docker Registry上进行了相应的企业级扩展，从而获得了更加广泛的应用，这些新的企业级特性包括：管理用户界面，基于角色的访问控制，AD/LDAP集成以及审计日志等。

容器的核心在于镜象的概念，由于可以将应用打包成镜像，并快速的启动和停止，因此容器成为新的炙手可热的基础设施CAAS，并为敏捷和持续交付包括DevOps提供底层的支持。

而Habor和Docker Registry所提供的容器镜像仓库，就是容器镜像的存储和分发服务。之所以会有这样的服务存在，是由于以下三个原因：

提供分层传输机制，优化网络传输

Docker镜像是是分层的，而如果每次传输都使用全量文件（所以用FTP的方式并不适合），显然不经济。必须提供识别分层传输的机制，以层的UUID为标识，确定传输的对象。

提供WEB界面，优化用户体验

只用镜像的名字来进行上传下载显然很不方便，需要有一个用户界面可以支持登陆、搜索功能，包括区分公有、私有镜像。

支持水平扩展集群

当有用户对镜像的上传下载操作集中在某服务器，需要对相应的访问压力作分解。

上面这些就是Docker Registry所完成的主要工作，而Habor在此之上，又提供了用户、同步等诸多特性，这篇文章中我们就这几个方面作一些阐述，同时实例代码介绍Harbor与K8s的集成。

一、Harbor的安全机制

企业中的软件研发团队往往划分为诸多角色，如项目经理、产品经理、测试、运维等。在实际的软件开发和运维过程中，这些角色对于镜像的使用需求是不一样的。从安全的角度，也是需要通过某种机制来进行权限控制的。

举例来说，开发人员显然需要拥有对镜像的读写（PULL/PUSH）权限以更新和改正代码；测试人员中需要读取（PULL）权限；而项目经理需要对上述的角色进行管理。

Harbor为这种需求提供了用户和成员两种管理概念。

在Harbor中，用户主要分为两类。一类为管理员，另一类为普通用户。两类用户都可以成为项目的成员。而管理员可以对用户进行管理。

成员是对应于项目的概念，分为三类：管理员、开发者、访客。管理员可以对开发者和访客作权限的配置和管理。测试和运维人员可以访客身份读取项目镜像，或者公共镜像库中的文件。

从项目的角度出发，显然项目管理员拥有最大的项目权限，如果要对用户进行禁用或限权等，可以通过修改用户在项目中的成员角色来实现，甚至将用户移除出这个项目。

二、Harbor的镜像同步

为什么需要镜像同步

由于对镜像的访问是一个核心的容器概念，在实际使用过程中，一个镜像库可能是不够用的，下例情况下，我们可能会需要部署多个镜像仓库：

国外的公有镜像下载过慢，需要一个中转仓库进行加速

容器规模较大，一个镜像仓库不堪重负

对系统稳定性要求高，需要多个仓库保证高可用性

镜像仓库有多级规划，下级仓库依赖上级仓库

更常用的场景是，在企业级软件环境中，会在软件开发的不同阶段存在不同的镜像仓库，

在开发环境库，开发人员频繁修改镜像，一旦代码完成，生成稳定的镜像即需要同步到测试环境。

在测试环境库，测试人员对镜像是只读操作，测试完成后，将镜像同步到预上线环境库。

在预上线环境库，运维人员对镜像也是只读操作，一旦运行正常，即将镜像同步到生产环境库。

在这个流程中，各环境的镜像库之间都需要镜像的同步和复制。

Harbor的镜像同步机制

有了多个镜像仓库，在多个仓库之间进行镜像同步马上就成为了一个普遍的需求。比较传统的镜像同步方式，有两种：

第一种方案，使用Linux提供的RSYNC服务来定义两个仓库之间的镜像数据同步。

第二种方案，对于使用IaaS服务进行镜像存储的场景，利用IaaS的配置工具来对镜像的同步进行配置。

这两种方案都依赖于仓库所在的存储环境，而需要采用不同的工具策略。Harbor则提供了更加灵活的方案来处理镜像的同步，其核心是三个概念：

用Harbor自己的API来进行镜像下载和传输，作到与底层存储环境解耦。

利用任务调度和监控机制进行复制任务的管理，保障复制任务的健壮性。在同步过程中，如果源镜像已删除，Harbor会自动同步删除远端的镜像。在镜像同步复制的过程中，Harbor会监控整个复制过程，遇到网络等错误，会自动重试。

提供复制策略机制保证项目级的复制需求。在Harbor中，可以在项目中创建复制策略，来实现对镜像的同步。与Docker Registry的不同之处在于，Harbor的复制是推（PUSH）的策略，由源端发起，而Docker Registry的复制是拉（PULL）的策略，由目标端发起。

Harbor的多级部署

在实际的企业级生产运维场景，往往需要跨地域，跨层级进行镜像的同步复制，比如集团企业从总部到省公司，由省公司再市公司的场景。

这一部署场景可简化如下图：

更复杂的部署场景如下图：

三、Harbor与K8s的集成实践

Harbor提供了基于角色的访问控制机制，并通过项目来对镜像进行组织和访问权限的控制。kubernetes中通过namespace来对资源进行隔离，在企业级应用场景中，通过将两者进行结合可以有效将kubernetes使用的镜像资源进行管理和访问控制，增强镜像使用的安全性。尤其是在多租户场景下，可以通过租户、namespace和项目相结合的方式来实现对多租户镜像资源的管理和访问控制。

集成的核心概念和关键步骤

两者的集成，一个核心概念是k8s的secret。作为kubernetes中一个重要的资源secret，它的设计初衷是为了解决容器在访问外部网络或外部资源时验证的问题，例如访问一个Git仓库，连接一个数据库，设置一些密码配置等，需要额外验证的场景Secret存储了敏感数据,例如能允许容器接受请求的权限令牌。通过将Harbor的用户信息与K8s的Secret相关联，即达成了两者的集成。步骤如下：

在Harbor中创建创建用户，项目，将项目设置为私有。

将创建的用户加入到项目中，设置用户的角色为开发者或者为项目管理员。确保该账户具有拉取该仓库镜像的权限。

创建K8s下的Secret，其中secret中的用户名、密码和邮箱地址信息为在Harbor中创建的用户的信息。

在此过程中需要注意的是，第三步中创建的secret，对应的用户必须在Harbor的对应私库中有下载镜像的权限，否则应用部署时会报无法下载镜像。

举例来说

在Harbor中创建了用户，如userD

在Harbor中创建一个私有项目，如projectA

在Harbor中使用Docker命令行登陆并上传镜像至步骤2中的私有库

在K8s中创建Namespace

在K8s的Namespace中创建SecretC，该Secret对应Harbor中的用户账号userD

使用Harbor私库中的镜像在K8s的Namespace中部署应用，指定镜像下载时使用上面创建的SecretC

如果只需要能够拉取Harbor的镜像在K8s中部署应用，Harbor中的userD需要在projectA中有最低权限的访客成员角色。

Harbor与K8s集成的代码实践

imagePullSecret在K8s中用来保存镜像仓库的认证信息，以方便Kubelet在启动Pod时，能够获得镜像仓库的认证信息，确保能Kubelet够有权限从镜像仓库中下载Pod所需的镜像。

首先我们来看一下k8s中的ImagePull类型的Secret如何来创建。官方文档为：https://kubernetes.io/docs/user-guide/images/#specifying-imagepullsecrets-on-a-pod

以下代码实践Harbor版本是0.3.5。

首先，我们需要在harbor中选择一个用户，使用它的用户名与密码生成一个字符串，用户名与密码中间用冒号相连，然后使用base64对它进行加密，如下所示：[root@k8s-01 ~]# echo "test:tT001"|base64

dGVzdDp0VDAwMQo=

然后，我们需要生成一个dockerconfig.json，需要使用上面生成的加密字符串，内容大致如下，假如对应的harbor库的地址为：hub.testharbor.com：

{
  "auths":{
   "hub.testharbor.com": {
     "auth": "dGVzdDp0VDAwMQo=",
     "email": ""
    }
  }
}

我们需要把这整个json使用base64进行加密。生成的字符串可能比较长，需要加上 -w 0 参数，不让它换行。将上面的json保存成dockerconfig.json文件，然后执行命令：

现在，我们可以来创建secret所需的yaml了。secret创建的时候，必须指定namespace。多个namespace中的secret可以同名。假如我们需要在名为hub中的namespace中创建名为testsecret的secret，对应的secret.yaml内容如下。需要使用上面生成的加密字符串。

此时在k8s中使用kubectl create 命令即可创建对应的secret：

kubectl create -f secret.yaml

最后，在部署应用的时候，我们需要为Pod指定下载镜像所需的secret名字，如下所示：

apiVersion: v1
kind: Pod
metadata:
  name: httpdpod
  namespace: hub
spec:
  containers:
    - name: httpdpod
      image:hub.testharbor.com/project1/httpd:2.2
  imagePullSecrets:
    - name:testsecret

注意，要想部署成功，test用户必须为harbor中的project1项目中的成员，它才能有下载这个httpd:2.2的权限。

容器云的用户与集成

作为容器云运行时，Harbor的用户与K8s的Secret可以有更集约的整合方式。在我们的项目实践中，一个容器云的用户与一个Harbor中同名Project一一对应，但此用户可以在k8s中可以创建多个namespace。为了简化管理过程，目前我们的做法是：

在容器云启动过程中，自动在Harbor中创建一个专用用户，专门用来在各私库中下载镜像

每个在Harbor中新建的私库，都会将这个专用用户添加为它的访客成员角色，使这个专用用户拥有下载此库中镜像的权限

在K8s中，每创建一个新的namespace的同时，在此namespace下，使用上面的专用用户的信息创建固定名称的secret（多namespace中可存在同名secret）

部署应用时，指定imagePullSecrets下面的名称为上面固定的secret名称。

四、两个小贴士

使用在线工具让Harbor的接口文档更易读

Harbor对外提了restful形式的接口供其它系统集成，它的接口描述以swagger格式的文档包含在源码中，文档地址为： https://github.com/vmware/harbor/blob/master/docs/swagger.yaml。

目前，越来越多的系统使用restful的接口对外暴露服务，而swagger已经成了事实上的restful接口的描述标准。直接使用文本编辑器去查看这种swagger文档，会有点晕，没法方便清晰地查看接口的整体结构。我们可以借助一些工具来看这些文档。在线的，比如官方提供的swagger在线编辑器，把文档内容复制至左边，右边即可显示html格式的文档，可以折叠等，让人对所有接口一目了然。离线的，则可以在一些编辑器安装插件，将它同样转化成html进行查看，比如vscode，安装 Swagger Viewer插件即可。关于Swagger的使用，也可以阅读我的同事李小飞的文章《微服务架构实战：Swagger规范RESTful API》。

两种格式的文档展示如下：

小贴士：Harbor的Java Client开源实现

对于熟悉Java编程的用户来说，Harbor官方没有提供java client，但是在github上也有人写了相关的项目，项目地址：https://github.com/grissomsh/harbor-java-client

五、总结

本文主要介绍了Harbor的用户机制、镜像同步和与K8s的集成实践。

Harbor的用户机制分为系统用户和项目成员两类。用户可以成为项目成员，而不同成员有不同的镜像读写权限。

Harbor的同步策略和任务调度机制，为镜像库间的镜像同步提供了灵活的机制。

利用K8s的Secret与Harbor用户的关联，可以在K8s中拉取Harbor私有库中的镜像来部署应用。我们也用代码进行了举例。

最后，再分享几个在Harbor（0.3.5）的使用过程中碰到的小坑：

在Harbor中创建用户时，密码必须为复杂密码。但是修改时，没有了此限制

用户更新密码的时候，原密码不能与新密码一致，否则报500内部错误

在为harbor的project添加成员的时候，成员角色没有相关API，需要给的id值也没有常量定义，目前来看，1为admin, 2为devlop，3为guest。

次浏览