信用卡鼻祖 Capital One 如何解决私有开源Docker镜像中心瓶颈
2019-08-06 10:37:08   来源：东方头条   

背景

Capitaol One 是一家美国的数字化银行，全球有上万的研发，具有非常丰富的 DevOps 的落地经验，该公司开源的 DevOps 报表 Hygieia 也受到大多数公司的关注。在 JFrog 的用户大会上，Capital One 的运维专家 Wayne 有理有据的披露了 Capital One 迁移开源镜像中心到 Artifactory 的理由和迁移过程。

Catpital One 大量使用了容器技术发布他们的应用，在 Docker 镜像中心这块，运维团队基于开源的 Docker 镜像中心打造了内部的 Docker 镜像服务，用 AngularJs 封装了自服务的 UI，MongoDB 记录了镜像的元数据，支持了180,000种镜像，50TB 的数据。

您可能会好奇，开源的镜像中心已经支持了这么多的镜像，为什么要将它迁移到 Artifactory？理由是当越多人用开源镜像中心的服务时，就越不稳定，特别是在生产环境，导致很多内部研发团队开始抱怨，同时镜像在多地复制时也遇到了瓶颈，作为镜像中心服务的提供者，Capital One 的运维团队需要寻求稳定的方案。

于是运维团队开始评估：基于开源方案投入的时间成本，人力成本，另外也在做镜像中心的选型，他们选择了3家，Artifactory，亚马逊 ECR，Harbor 进行评估。

评估镜像中心方案

运维团队梳理了之前开源方案的痛点，罗列出来了新的方案必须满足的功能点。这些关注的点都是他们趟过的坑，如果您正在评估 Docker 镜像中心的方案，可以拿走这些功能点放到立项目标里。

云原生支持

· 能够部署到云环境，降低资源的消耗

· 能够重用云原生的技术，例如 S3，负载均衡，数据库等等

· 高可用，保证服务的连续性，能够处理高并发请求

· 快速搭建，落地

自动扩容和技术支持

· 很容易为研发提供支持

· 开发者比较熟悉

· 必须能够支持大并发的流量

· 能够按需扩容

· 和现有的流程集成

自助式服务

· 团队能够实现自助式服务，开发自行申请 Docker镜像仓库服务

· 不依赖管理员权限

· 提供 API 进行自动化创建仓库，用户，权限等等

· 构建一次，处处运行

运维团队从以下几个方面评估了 Artifactory，ECR 和 Harbor：

云原生的支持

Artifactory 对云原生部署支持得很好，很多用户将 Artifactory 部署在云环境里，ECR 和 Harbor 均可以支持S3存储。

高可用

Artifactory 和 ECR 都支持高可用，但 Artifactory 支持全球的镜像复制，而 ECR 原生并不支持跨广域网的复制。Harbor 对高可用支持较弱，需要较多的人工搭建工作，运维成本较高，而且出问题了没有官方的支持服务。

程序员熟悉度

Artifactory 和 ECR 在北美的知名度较高，一般运维工程师都已经接触过 Artifactory 或者 ECR，而 Harbor 在北美，硅谷几乎没有用户。

和现有流程对接

由于 Capital One 已经使用 Artifactory 作为 Maven，NPM 等多语言的私服，所以在现有的流程里可以直接拿来使用，而 Harbor 可以自行安装，自主控制和公司内部工具的对接，也满足要求。

自助式服务能力

Artifactory 和 Harbor 在自助式服务这块，需要依赖部分管理员权限，而运维团队不太愿意开放这些权限给用户。Artifactory 将在新版本中支持非管理员能够创建用户，仓库等权限。而 ECR 原生对权限进行了隔离，所以支持度最好。

自动化 API

同样的，Artifactory 虽然提供了所有的 API 调用，但在某些 API 的调用上，需要管理员权限，而 ECR 原生对权限进行了隔离，所以支持度最好。

构建一次，处处运行

Artifactory 支持构建一次，多次升级或者复制的能力。一个 Docker 镜像 Push 到 Artifactory 开发库之后，可以通过 Promote 的方式升级到测试库，生产库，而无需重复构建。而 ECR 在复制镜像从开发者账号复制到生产环境账号时，需要 Pull，再 Push，这种实现方式比较丑陋。

最终 Capital One 选择了 Artifactory 作为 Docker 镜像中心，并且基于 Artifactory 的 API，自己打造了公司内部的 Docker 镜像自服务系统，并且封装了 Artifactory 的 API，对外提供了自服务的接口，供 Jenkins Job 调用。

迁移数据到 Artifactory

迁移计划: 运维团队在 Artifactory 创建了一个大的本地 Docker 仓库，聚合了所有之前的开源 Docker 注册中心，每个团队在这个本地仓库里拥有独立的文件夹进行权限的隔离。

同时使用了 Artifactory 的虚拟 Docker 仓库，来聚合所有本地副本仓库。用户可以在自己的命名空间里自定义权限。

在执行迁移的时候，运维团队考虑了通过S3 桶同步的操作，虽然数据可以复制到新的仓库，但缺乏元数据的同步。所以运维团队最后写了脚本去从之前的开源注册中心执行递归的 Pull，然后 Push 到 Artifactory。由于老的镜像中心还在使用，所以需要每天定期的将新的数据 Push 到 Artifactory 集群。

在迁移大镜像(超过2GB)的时候，发现 Push 频繁出现失败，后来定位问题是在 Nginx 的配置 proxy_max_temp_file_size 需要调大，来支持大文件的下载。

迁移数据之后，还需要进行性能测试，来保证 Artifactory 集群能够禁得起高并发的流量。之前的开源镜像中心有3个节点，新的 Artifactory 集群搭建了8个节点，每个节点都设置了 SSD 缓存，减少后端 S3存储的压力，同时增加并发 Pull 的支持能力，事实证明 Artifactory 对性能压测表现良好。

做好压测之后，即可以往生产环境进行切换了。首先运维团队对所有的开发和部门的领导进行的公示，声明 Artifactory Docker 镜像中心正式对外提供生产基级别的服务，并且提供 Slack 的实时消息回复支持。每个团队可以自行申请 Docker 镜像服务，测试效果，自行决定是否使用。同时将之前的开源注册中心的 DNS 指向了 Artifactory 集群。

后续

Artifactory 目前支持了 Capital One 的 Docker 镜像文件超过9百万个，从之前的50TB 到现在的115TB，为全球10000+的开发者提供的镜像服务，使用外部的脚本进行 Artifactory HA 集群直接的跨数据中心的同步。目前使用 Clair 进行镜像的漏洞扫描，他们的目标是将来使用 JFrog Xray 进行漏洞扫描。

END