随着容器技术的广泛使用，镜像管理成为实际运维中的重要问题。在 2017 上海站 CNUTCon 全球运维技术大会上，InfoQ 有幸采访到 VMware 中国研发中心先进技术中心技术总监张海宁老师。

关于如何在 Kubernetes 的实际开发运维中，高效安全地部署镜像仓库并管理容器镜像的方法，张海宁老师都有自己独到的见解。以下是现场采访内容：

InfoQ： 张老师你好！请谈谈您对高效安全的镜像运维的理解。

张海宁： 你好，大家好！很多现在做容器的用户，他们很关心的一个问题是怎么样把这个容器的应用跑得好，可能他会想，我是用 Kubernetes，还是用 Docker Swarm，或者其他的一些技术来跑我的容器应用呢。

我们觉得这仅仅是在容器运维上面一个比较动态的侧面，就是说，把这个运行的平台弄好了之后，还有另外一个侧面就是静态的容器的平台，所谓静态的就是这个容器的镜像。通常来说，就是容器除了动态地在内存里面跑的一个容器化的实例之外，它还需要有一个静态的镜像放到磁盘里，这个磁盘需要很好地去维护，我们认为这是一个很重要的方面。就是说容器动态和静态的结合，才是完整的一个容器平台。所以高效安全的容器镜像的管理，在任何一个企业的运维里面都是非常必要的，同时也是一个必须的步骤，应该说，做得好不好，会实际影响到它的效率，以及安全性的一些问题，我认为这个是非常重要的一个事情。

InfoQ： 您的演讲主题是说采用 Harbor 开源企业级 Registry 实现高效安全的镜像运维，与其它的 Registry 项目相比，Harbor 有哪些优势？

张海宁： 首先介绍一下我们的 Harbor 这个项目，这个项目是最早在我们 VMware 中国研发中心的一个很小的一个副产品，Side Project，这个项目做出来之后，我们在公司内部用了一段时间，觉得效果还不错，后来去年我们把它开源出来，面向全球的用户让他们去使用，最终效果也非常好。

总结起来，大部分用户对我们 Harbor 项目喜欢的地方，主要有几个，第一个是说，我们这是开源的一个解决方案，而且是面向企业用户的开源解决方案，用的是 Apache License 2.0，这样的话，基本上谁都可以拿去使用，或者修改，没有太多的义务或者约束，这样是很受欢迎的一个主要原因。

第二点，我们是结合了很多社区里边的反馈信息，提炼出这么一个作品出来，这样使得 Harbor 一诞生的时候，已经非常符合整个用户的需求。

那怎么设计的呢？我们是用了最简单的功能去实现了用户百分之八九十的需求，相对来说它是非常简单的，像用户模型的设计，我们只有一层的设计，其他的 Registry 可能是有很复杂的用户模型，相比起来非常复杂难理解。简单是一个优势。

还有一点，可能就是说，我们有些特色的功能，除了标准的，像大家常见的 Role-based Access Control，就是基于角色的访问控制之外，我们还有大家非常喜欢用的 Replication，就是镜像的复制，是解决了运维中很常见的一类移动镜像问题。传统来说，可能需要用一些脚本，一些软件去做这个事情，我们全部用一个可视化的图形界面去把它有序地管理起来，同时能在出错时自动去重试。这也是用户选择我们 Harbor 的一个主要的原因，包括现在有的世界级的银行他们也在用我们的方案，把镜像从一个大洲的 Office 办公点，处理中心，复制到其他大洲的服务中心里，所以这是第二个优势。

那么第三个，特别对中国用户来说，我们有很多本地化的输入，一些考虑，我们有微信群，那么有几百个用户在给我们提供反馈，所以对我们中国用户来说，可能第一时间可以得到很多很好的适合他们使用需求的定制化功能。而且，我们原生我们就支持中文的界面。在容器的项目里面，很少是能原生支持中文的，所以这也是我们广大中国用户非常喜欢 Harbor 的一个原因。所以总结来说，我们 Harbor 还是有很多优势，所以得到很多的用户的喜爱。

InfoQ ： 在运维环境中，如何实现镜像来源验证和镜像漏洞扫描，这为用户带来哪些价值？

张海宁： 这两个问题其实在镜像管理工作中是困扰很多企业的，第一个就是说镜像的真实可靠性，或者说镜像来源，因为大家现在知道很多时候你从 Docker Hub 或者别的地方抓过来的镜像，到底是谁产生的，是不清楚的，或者这个镜像里面有没有带什么漏洞、病毒也不知道，如果冒冒然去使用是个很危险的事情，所以就造成了需要去验证镜像可靠性的需求。一般来说，我们使用叫做 Content Trust 的功能，就是内容可信任，主要的原理是说，我们在发布这个镜像的里头，做个签名，签名之后，这个签名生成的一个摘要，会存在一个 Notary Service 这样一个地方。存进去之后，在其他的使用者去使用这个镜像的时候，它会去先获取这个签过名的摘要，然后再根据 Registry V2 协议 pull by content 的功能去获取镜像，如果是没有签过名的镜像 Registry 是拿不到的，只有签过名的镜像才会有一个对应的镜像存在里面，这样才能拿下来。通过这样一种机制，就可以实现这个 Content Trust 功能。

第二个是镜像扫描，有点像我们平常在电脑上进行病毒扫描，就把全盘的文件扫一遍，发现有没有被病毒感染过的，或者有病毒存在的一些文件。那么在企业跑的镜像里边，这个扫描也是很需要的功能，就是我的镜像来源，可能是不同的地方，那最终到底有没有一些漏洞，我怎么样能发现，需要有一个对镜像里面所有文件进行扫描的功能，然后发现和报警的机制。这部分功能其实叫做 Scanning，就是扫描镜像的 vulnerability 的 scanning，我们现在在 Harbor 里集成了 CoreOS 的 Clair，这是另外一个开源项目，可以帮助我们去扫描 Harbor 里面放的这个镜像，同时扫描完之后，我们有个很详细的一个报告，会告诉我们这个镜像里面，有多少个 Package，这些软件包有多少个是有问题的，严重程度是怎么样的。用户可以决定性地去使用，比如发现严重问题的，我就不允许这个镜像去下载了，如果是很轻微的，可以允许获取镜像。在我们 Harbor 里有一个 Threshold Value，阈值，它去定义镜像漏洞的严重程度，使得用户可以去选择。通过这样的机制保证有问题的镜像是不可以从我们 Harbor 流出去的，这也是我们最新的一版做到的一个功能。同时它也有一个很好的图视化、格式化的界面去给大家展现出来，比较直观地可以看到扫描的结果，这个也是大家可以去尝试的。

InfoQ： 现在这个 Harbor 项目适用于哪些存储技术？

张海宁： 我们 Harbor 是用 Docker Distribution 去做的扩展，从本质上讲，只要是基本的 Docker Distribution 可以支撑的后端存储，我们 Harbor 都可以去使用。现在常见的本地文件系统，有 AWS 的 S3，或者是阿里等云上面的各种对象存储，主流的各种存储都是支持的，我们有很多的用户是有千奇百怪的存储，除了本地文件系统之外，各种各样的存储基本上都试过了，也是可靠的一件事情。

InfoQ： 为确保镜像高可用，采用了哪些技术方案？遇到了哪些难点？如何解决？

张海宁： 任何一个跑在生产环境的用户他们很关心 Server 高可用这个问题，就是说我们这个 Registry 能够跑起来，然后又没有单点的故障，这是他们最关心的一个事情。通常我们在我们那个微信群里面，在 Github 上很多用户都提这个问题，其实这是一个需要从多种角度去看的一个问题，首先要看看你真正的需求到底是什么样子的，有的用户他说他要 HA，他要高可用，他可能仅仅是需要这个服务不要随便就宕掉，宕掉的时候有个 backup 机制，但是他可能不一定明白它真正需要的代价是什么，比如说做 HA 其实是有个前提条件的，就是说，我要达到什么样的不间断性，比如说我不能够一分钟之内断，或者我能承受的是一小时或者一天之内可以断，这样不同的这个 HA 的要求，决定我们使用的这个底层的技术是有区别的。如果有的很低端的环境允许断一天或者半天，都没问题的，可能有些低端的技术来实现，有的环境一分钟不能断的，肯定用高端的一些硬件设备来搞定这个事情。

从高可用上看，目前有大概有几种方法，一种就是说我们共享存储功能，多个实例来共享一个后端的镜像的存储。共享存储常见的有高端的，NAS 的存储，像 EMC 等等，或者是一些对象存储，像那些 Cloud 上 S3，或者各种云端的对象存储，只要是具备共享能力的，他们都可以接入 Harbor 的后端，形成一个多前端的，在无状态的 Harbor Registry 去连接后端存储这样的功能，这部分 HA 只要基本上实现后端存储，再加上一些其他的绘画层的一些共享之外，基本上可以实现，这个比较标准了，成本也相对的会高一些，因为 HA 的一些共享存储在里面。

有一些便宜的方案，或者叫穷人的方案，就说用一些低端的方案来做，就是说我不想用这个共享存储，因为可能技术原因，或者是成本原因，我不想用，我可以用一些简单的方案，比如我两个实例，对 Harbor 的一个实例，中间通过一个复制，使得我镜像有个备份的能力，这样的话，这个镜像当于有了多份的副本，那么在一个实例宕掉之后，我可以用手动，或者半自动或者自动的方式，去切换到另外一个 Harbor  Registry 上面，就实现了 Registry 的 HA，这种是低端的手段，虽然不是太好看，但是能满足用户的需求，这也是一种可行的方案，也有用户在用，所以就说可能因地制宜，或者是根据用户真正的需求才比较合适地去使用。

还有一种方案是，如果你有现有的 HA 的平台，像 VMware vSphere HA 的平台，可以用 vSphere HA 直接把虚拟机保护起来，存储可以用我们的 VSAN 分布式存储来实现 HA，这样也可以达到整体这个 Registry  HA 的目的。

这是一个综合性的话题，所以可能需要根据需求，根据大家熟悉的技术，或者实际的场景综合地去判断和使用。

InfoQ： 这里边涉及到技术上有哪些难点？

张海宁： 从我们用户上讲，无非就是刚才说的那个共享存储，如果你要决定采用共享存储，这个共享存储你要去维护，维护这个共享存储的高可用性，像一些大的互联网公司，公司里都有自己的一层共享存储，像 Ceph，或者其他 GlusterFS 这样一些共享存储，如果这个共享存储的设施已经存在，或者是已经比较完整的话，架设 HA 在共享存储上是没有太大问题的，它就不需要额外的成本。如果一个企业里完全是没有这些积累的话，它要去做这个共享存储，会面临一个选型和怎样维护的问题，它的人员不一定能够很熟悉这些共享存储的技术，需要花时间去维护。剩下前端的 Harbor 有若干个实例做一个协调，前面可能加一个负载均衡器，去分流一些应用，使得前端来的请求能够分配到不同的实例当中去做一个负载均衡和一个高可用的互备，这是要注意的问题。

InfoQ： 感谢张老师今天接受我们采访，今天的分享就到这里。

张海宁： 非常感谢。