Harbor可靠和高效的云原生制品远程复制

题图摄于巴塞罗那港

注：微信公众号不按照时间排序，请关注“亨利笔记”，并加星标以置顶，以免错过更新。

【编者注】云原生制品，如镜像、Helm Charts等，在不同环境中传输云原生制品是很常见且重要的操作。Harbor 从 v0.3 开始提供可靠的云原生制品同步功能，很受用户欢迎，并且衍生出各种应用场景。

相关文章：

生产系统中升级 Harbor 的完整流程

用 Go 开发的 Docker 竟然在这个大会上首发

CNCF的中国云原生调查报告

本文内容节选自最新出版的《 Harbor权威指南》第 7 章，相关作者为 Harbor 开源项目维护者尹文开，值得 Harbor 用户收藏以备后用。

（目前在当当网满100元减50元的优惠活动中，请抓紧机会购买，点击以下图片即可。）

概述

在日常的开发运维过程中，往往需要同时用到多个Artifact（制品）仓库服务来完成不同的任务，比如开发测试对应一个仓库服务实例，生产环境对应另一个不同的实例，一个 Artifact 经过开发测试后需要从开发仓库推送到生产仓库中；又或者为了提高下载速度，在不同的数据中心搭建多个不同的仓库服务，一个 Artifact 在被推送到其中任意一个仓库后，就会被自动分发到其他数据中心的仓库；并且在构建一个 Artifact 后会将其推送到中心仓库，这个 Artifact 需要被分发到其他仓库服务中以供使用。

在一些简单场景中，这些推送、分发任务可以通过自动化脚本甚至手动完成，但如果仓库数量较多，或者需要在异构仓库服务之间复制镜像等制品，则实现便于管理的通用解决方案就不是一件简单的事情了。Harbor 提供的远程复制功能可以帮助用户实现上述需求，该功能可以支持多种不同的仓库服务、运行模式、过滤规则和触发方式，解决镜像等云原生制品跨系统可靠移动的问题。

当前 Harbor 已经对使用广泛的多种仓库产品和服务提供了支持，并且支持列表还在不断更新。在2.0版本中，根据所管理的 Artifact 类型，已支持的仓库服务可分为两类：镜像仓库服务和 Helm Chart 仓库服务。所支持的镜像仓库服务有Harbor、Docker Hub、Docker Registry、AWS Elastic Container Registry、Azure Container Registry、AliCloud Container Registry、Google Container Registry、Huawei SWR、GitLab、Quay.io 和 JFrog Artifactory；所支持的Helm Chart 仓库服务有 Harbor 和 Helm Hub 。

复制策略

复制策略支持推送和拉取两种模式。推送指将当前 Harbor 实例的 Artifact 复制到远程 Artifact 仓库服务下；拉取指将其他 Artifact 仓库服务中的 Artifact 复制到当前 Harbor 实例中。在推送模式下，当前的 Harbor 实例是源仓库，复制的目标Artifact 仓库是远程仓库；在拉取模式下恰好相反，其他 Artifact 仓库是源仓库，当前 Harbor 实例是复制的目标仓库，在其他 Artifact 仓库看来，当前 Harbor 实例是远程仓库。这两种模式分别适用于不同的使用场景，比如在配置了特定规则防火墙的环境下，处于防火墙内的仓库服务实例只能通过拉取模式获得远程Artifact。

在源仓库的项目中可能会有较多的 Artifact，但用户不一定希望全部Artifact都被复制到目标仓库中，因此需要对 Artifact 进行筛选。在复制策略中可以设置多种过滤器规则，以满足不同场景对所需复制的 Artifact 的过滤需求。Harbor 支持 4 种过滤器，分别针对 Artifact 的不同属性进行过滤：名称过滤器、Tag 过滤器、标签过滤器、资源过滤器。

在创建复制策略时，可以根据不同的使用场景选择不同的触发方式以满足不同的需求，Harbor 当前支持三种不同的触发方式：手动触发、定时触发、事件驱动。

手动触发指在需要进行复制时由系统管理员手动单击“复制”按钮来触发一次性的复制流程，会复制当前 Harbor 实例中所有符合过滤器条件的 Artifact。

定时触发指通过定义类似的 Cron 任务周期性地执行复制操作。与手动触发模式相同，定时触发模式也会把当前 Harbor 实例中符合过滤器条件的所有 Artifact 进行复制。

事件驱动触发指将 Harbor 作为源仓库，在发生某些事件时自动触发复制操作。Harbor 目前支持两种事件：推送 Artifact 和删除 Artifact 。在这两种事件执行完成后，如果操作的资源满足过滤器设置的条件，则此操作会被立刻同步到远程仓库服务中，完成相应的 Artifact 推送或删除动作。这种驱动方式在一定程度上可以应对实时同步的场景，但是根据不同的网络环境会有不同程度的延迟发生。如果复制任务失败，则后续会进行3次重试，但无法保证 100% 的成功率（比如远程仓库服务宕机）。因此，如果是对数据一致性有很高要求的环境，则需要考虑其他方案。同步 Artifact 删除操作是可选的，可以在创建复制策略时进行设置，当目标仓库是生产环境时，可以选择不同步删除操作，以免造成误删。

使用场景

远程复制可以适用于 Artifact 的分发、双向同步、DevOps 镜像流转、数据迁移和数据备份等典型场景中，下面进行一一的介绍。

负载均衡

在大规模集群环境下，如果所有Docker主机都要从一个单点的镜像仓库中拉取镜像，那么此镜像仓库很可能会成为镜像分发的瓶颈，影响镜像分发的速度。通过搭建多个镜像仓库并配合使用远程复制功能，可以在一定程度上解决这个问题，实现负载均衡。

镜像仓库的拓扑结构如下图所示。图中的镜像仓库分为两级：主仓库和子仓库。在主仓库和子仓库之间配置了远程复制策略。在一个应用的镜像被推送到主镜像仓库后，根据所配置的复制策略，此镜像可以被立刻分发到其他子镜像仓库。集群中的Docker主机则可以就近在其中任意一个子仓库中拉取所需的镜像，减轻主仓库的压力。如果集群规模比较大或者地域分布较广，则子仓库也可被部署成多层级的结构，由一级子仓库再将镜像分发到二级子仓库，Docker主机则在就近的二级子仓库中完成镜像的拉取。

异地镜像同步

远程复制也可以用于实现简单的跨地理位置复制功能或者公有云与私有云之间的同步功能。镜像仓库的拓扑结构如下图所示。

在上图中有两个镜像仓库，仓库 1 通过配置复制策略可以实时地将推送到仓库1的镜像复制到仓库2；同时，在仓库2上也配置了类似的策略，可实时地将推送到仓库2的镜像复制到仓库1。这样当一个镜像被推送到其中任何一个仓库时，这个镜像都会被实时推送到另一个仓库，从而达到同步的效果。在拓扑结构中也可以包含多于两个的镜像仓库，这些仓库之间相互通过配置双向的复制策略来实现同步。

DevOps流水线集成

在开发和运维过程中，一个应用从开发到上线往往要经历多个步骤：开发、测试、进入准生产环境、最终上线进入生产环境，相应的镜像也要经过多个步骤的流转。利用镜像复制功能可以搭建如下图所示，DevOps 流水线来实现镜像的发布和管控。

上图中在开发、测试、准生产和生产镜像仓库之间都配置了相应的远程同步策略。在代码被提交到代码仓库后可以触发CI（持续集成）系统构建应用镜像，并将镜像推送到开发镜像仓库，将需要进行测试的镜像推送到测试镜像仓库进行测试，之后再推送到准生产仓库，经过验证后最终推送到生产环境仓库。其中镜像的多次流转可以利用镜像的远程复制功能，通过制定不同的策略来实现，以达到可控、灵活、自动的镜像发布。

数据迁移

远程复制也可以用来做数据迁移。当用户想要从使用其他仓库服务转向使用 Harbor时，可以在Harbor中配置拉取模式的复制策略来将其他仓库中的镜像数据迁移到 Harbor中。当需要在两个第三方仓库之间迁移数据时，也可以将Harbor作为中间仓库，利用复制策略完成数据迁移，如下图所示。