阿里云开源 image-syncer 东西,容器镜像搬迁同步的终极利器

为何需求做这个东西?

因为阿里云上的容器服务 ACK 在运用本钱、运维本钱、方便性、长时间安稳性上大大超越公司自建自维护 Kubernets 集群,有不少公司纷乱想把之前自己维护 Kubernetes 负载搬家到阿里云 ACK 服务上。在搬家进程中,往往会碰到一个不大不小的坑:那就是怎样把已有的容器镜像滑润的搬家到阿里云镜像服务 ACR 上。这样的一个问题看起来格外的简略,假设只需三五个镜像,只需做一次 docker pull/docker push 就能结束,但实践出产中涉及到成千上百个镜像,几 T 的镜像仓库数据时,搬家进程就变的耗时非常漫长,甚至丢掉数据。

阿里如此原生运用途径的工程师——也就是我们,发现这是一个通用的需求,用户会在各种容器镜像仓库之间做搬家,或许进一步,期望有同步拷贝的才干,所以我们研发了 image-syncer 这个项目来支撑迁云,并一同开源给业界大众,用来处理通用的容器镜像批量搬家/同步的问题。

这个东西在实践出产中,现已帮忙了多家客户进行镜像搬家,其间最大镜像仓库的总量抵达 3T 以上,同步时能跑满机器带宽,进行同步任务的机器磁盘容量没有要求。

image-syncer 简介

如上所述,在 k8s 集群搬家场景中,镜像仓库之间进行镜像搬家/同步是底子需求,而运用 docker pull/push 结合脚本的传统方法来进行镜像同步,有如下几个局限性:

  1. 依托磁盘存储,需求及时进行本地镜像的收拾,并且落盘构成剩下的时间开支,难以担任出产场景中许多镜像的搬家
  2. 依托 docker 程序,docker daemon 对 pull/push 的并发数进行了严峻的束缚,无法进行高并发同步
  3. 一些功用只能通过 HTTP api 做相关操作,单纯运用 docker cli 无法做到,使脚本变得复杂

image-syncer 的定位是一个简略、易用的批量镜像搬家/同步东西,支撑几乎全部现在干流的根据 docker registry V2 树立的镜像存储服务,比如 ACR、Docker
Hub、Quay、自建 Harbor 等,现在现已初步通过了 TB 等级的出产环境镜像搬家验证,并开源于 https://github.com/AliyunContainerService/image-syncer ,欢迎我们下载运用以及供应贵重的建议~

东西特性

image-syncer 的特性如下:

1.支撑多对多镜像仓库同步
2.支撑根据 Docker Registry V2 树立的 docker 镜像仓库服务 (如 Docker Hub、 Quay、 阿里云镜像服务 ACR、 Harbor等)
3.同步只通过内存和网络,不依托磁盘存储,同步速度快
4.增量同步, 通过对同步过的镜像 blob 信息落盘,不重复同步已同步的镜像
5.并发同步,可以毕竟靠配备文件调整并发数
6.自动重试失利的同步任务,能处理大部分镜像同步中的网络颤抖问题
7.不依托 docker 以及其他程序

凭仗 image-syncer,只需求保证 image-syncer 的作业环境与需求同步的 registry 网络连通,你可以快速地结束从镜像仓库的搬家、仿制以及增量同步,并且对硬件资源底子上没有要求(因为 image-syncer 严控网络连接数目=并发数,所以只需在当单个镜像层过大的情况下,并发数目过大或许会打满内存,内存占用 <= 并发数 x 最大镜像层大小);除了运用重传机制逃避同步进程中或许会出现的偶发问题之外, image-syncer 会在作业结束时核算毕竟同步失利的镜像个数,并且打印出详细的日志,帮忙运用者定位同步进程中出现的问题。

运用攻略

image-syncer 作业,只需求用户更好的供应一个配备文件,内容如下:

{
"auth": {                   // 认证字段,其间每个政策为一个registry的一个账号和
// 暗码;一般,同步源需求具有pull以及访问tags权限,
// 同步政策需求具有push以及创建仓库权限,假设没有供应,则默许匿名访问
"quay.io": {            // registry的url,需求和下面images中对应registry的url相同
"username": "xxx",               // 用户名,可选
"password": "xxxxxxxxx",         // 暗码,可选
"insecure": true                 // registry是否是http服务,假设是,insecure 字段需求为true,默许是false,可选,支撑这个选项需求image-syncer版别 > v1.0.1
},
"registry.cn-beijing.aliyuncs.com": {
"username": "xxx",
"password": "xxxxxxxxx"
},
"registry.hub.docker.com": {
"username": "xxx",
"password": "xxxxxxxxxx"
}
},
"images": {
// 同步镜像规则字段,其间条规则包括一个源仓库(键)和一个政策仓库(值)
// 同步的最大单位是仓库(repo),不支撑通过一条规则同步整个namespace以及registry
// 源仓库和政策仓库的格式与docker pull/push指令运用的镜像url类似(registry/namespace/repository:tag)
// 源仓库和政策仓库(假设政策仓库不为空字符串)都至少包括registry/namespace/repository
// 源仓库字段不能为空,假设需求将一个源仓库同步到多个政策仓库需求配备多条规则
// 政策仓库名可以和源仓库名不同(tag也可以不同),此时同步功用类似于:docker pull + docker tag + docker push
"quay.io/coreos/kube-rbac-proxy": "quay.io/ruohe/kube-rbac-proxy",
"xxxx":"xxxxx",
"xxx/xxx/xx:tag1,tag2,tag3":"xxx/xxx/xx"
// 当源仓库字段中不包括tag时,标明将该仓库全部tag同步到政策仓库,此时政策仓库不能包括tag
// 当源仓库字段中包括tag时,标明只同步源仓库中的一个tag到政策仓库,假设政策仓库中不包括tag,则默许运用源tag
// 源仓库字段中的tag可以一同包括多个(比如"a/b/c:1,2,3"),tag之间通过","离隔,此时政策仓库不能包括tag,并且默许运用原本的tag
// 当政策仓库为空字符串时,会将源镜像同步到默许registry的默许namespace下,并且repo以及tag与源仓库相同,默许registry和默许namespace可以毕竟靠指令行参数以及环境变量配备,参看下面的描绘
}
}

用户都可以根据配备不同的镜像同步规则组合,以匹配不同的搬家/同步需求,如将单个镜像 repo 同步到多个不同的镜像 repo、将多个源镜像同步到单个镜像 repo 中(以 tag 差异)、在同一个 registry 中以不同的名字仿制一个镜像 repo 等等。
运用时必需求格外留心,假设匿名访问作为同步源的 registry 地址,或许存在权限问题无法 pull 镜像以及无法获取 tags,这样的一种情况下需求在" auth "中参与有对应权限的账号暗码;而假设匿名访问作为同步政策的 registry 地址,或许存在权限问题无法 push 镜像,相同也或许需求用户更好的供应有对应权限的账号暗码。
image-syncer 一同支撑 insecure 的 registry(类比 docker 的-- insecure - registry 参数,在" auth "的相应条目中添加 " insecure ": true ),可以一同在 http 和 https 两种类型的镜像服务之间搬家。
image-syncer 还供应了一些简略的参数来控制程序的作业,包括并发数目控制、重传次数设置等等:

-h  --help       运用阐明,会打印出一些发起参数的其时默许值
--config     设置用户更好的供应的配备文件地址途径,运用之前需求创建配备文件,默许为其时作业目录下的image-syncer.json文件
--log        打印出来的log文件途径,默许打印到标准差错输出,假设将日志打印到文件将不会有指令行输出,此时需求通过cat对应的日志文件查看
--namespace  设置默许的政策namespace,当配备文件内一条images规则的政策仓库为空,并且默许registry也不为空时有用,可以毕竟靠环境变量DEFAULT_NAMESPACE设置,一同传入指令行参数会优先运用指令行参数值
--registry   设置默许的政策registry,当配备文件内一条images规则的政策仓库为空,并且默许namespace也不为空时有用,可以毕竟靠环境变量DEFAULT_REGISTRY设置,一同传入指令行参数会优先运用指令行参数值
--proc       并发数,进行镜像同步的并发goroutine数量,默许为5
--records    指定传输进程中保存已传输结束镜像信息(blob)的文件输出/读取途径,默许输出到其时作业目录,一个records记录了对应政策仓库的已搬家信息,可拿来进行连续的多次搬家(会节约许多时间,但不要把之前自己没实行过的records文件拿来用),假设有unknown blob之类的差错,可以删去该文件从头检验
--retries    失利同步任务的重试次数,默许为2,重试会在全部任务都被实行一遍之后初步,并且也会从头检验对应次数生成失利任务的生成。一些偶尔出现的网络差错比如io timeout、TLS handshake timeout,都可以毕竟靠设置重试次数来减少失利的任务数量

在同步结束之后,image-syncer
会核算成功和失利的同步任务数目(每个同步任务代表一个镜像),并在标准输出和日志中打印 "Finished, <NUMBER OF
FAILED TASKS> sync tasks failed, <NUMBER OF GENERATED FAILED
TASKS> tasks generate failed" 的字样,然后能获得同步的效果。更多FAQ参见 FAQs.md

运用示例

ACR(Alibaba Cloud Container Registry)是阿里云供应的容器镜像保管服务,支撑全球20个地域的镜像全生命周期处理,联合容器服务等云产品,打造云原生运用的一站式领会。这儿通过将自建 harbor 上的镜像同步到 ACR,供应 image-syncer 的底子运用示例

从自建 harbor 同步镜像到 ACR

1.在阿里云控制台上注册容器镜像服务,并进入 ACR 控制台

2.创建命名空间,默许仓库类型抉择了当仓库不存在时,docker push 自动创建的仓库类型是公有的仍是私有的;假设部分需求同步的政策仓库不存在,需求翻开自动创建仓库按钮,让类似" docker push "的操作能自动创建仓库

3.创建访问凭证,对应的账号即为 docker login 的账号,如下图:

阿里云开源 image-syncer 东西,容器镜像搬迁同步的终极利器

4.上面的操作运用的是主账号,默许具有全部权限;为了进行权限处理,我们也可以毕竟靠创建 RAM 子账号,并配备对应权限,这儿的场景中我们只运用到了创建、更新镜像仓库相关权限,最小权限设置如下,访问控制的资源粒度为 image-syncer 命名空间:

{
"Statement": [
{
"Effect": "Allow",
"Action": [
"cr:CreateRepository",
"cr:UpdateRepository",
"cr:PushRepository",
"cr:PullRepository"
],
"Resource": [
"acs:cr:*:*:repository/image-syncer/*"
]
}
],
"Version": "1"
}

5.相同,RAM 账号需求通过 RAM 用户登陆进口登陆阿里云控制台,并进入 ACR 控制台创建访问凭证(同3.)

6.然后我们你们可以通过访问凭证中创建的暗码,结束如下 image-syncer 的同步配备(配备中运用 RAM 子账号的访问凭证);这儿我们将本地树立的 harbor( http 服务,要设置 insecure,通过 harbor.myk8s.paas.com:32080 访问)中的 library/nginx 仓库同步到华北2(通过为 registry.cn-beijing.aliyuncs.com 访问)中的 image-syncer 命名空间下,并且坚持仓库名称为 nginx,config.json 如下:

{
"auth": {
"harbor.myk8s.paas.com:32080": {
"username": "admin",
"password": "xxxxxxxxx",
"insecure": true
},
"registry.cn-beijing.aliyuncs.com": {
"username": "acr_pusher@1938562138124787",
"password": "xxxxxxxx"
}
},
"images": {
"harbor.myk8s.paas.com:32080/library/nginx": ""
}
}

7.下载最新的 image-syncer 可实行文件(现在只支撑 linux amd64 版别,可以自行编译),解压,并作业东西

实行指令:

# 设置默许政策registry为registry.cn-beijing.aliyuncs.com,默许政策namespace为image-syncer
# 并发数为10,重试次数为10
# 日志输出到./log文件下,不存在会自动创建,不指定的话默许会将日志打印到Stderr
# 指定配备文件为harbor-to-acr.json,内容如上所述
./image-syncer --proc=10 --config=./harbor-to-acr.json --registry=registry.cn-beijing.aliyuncs.com --namespace=image-syncer --retries=10 --log=./log

一次同步会履历三个阶段:生成同步任务、实行同步任务以及重试失利任务;其间,每个同步任务都代表了一个需求同步的 tag (镜像),假设配备文件中某条规则没有指定 tag,在“生成同步任务”阶段会自动 list 源仓库全部 tag,并生成对应的同步任务,假设生成同步任务失利,也会在重试阶段进行重试,(故意配错账号暗码时)实行输出如下:

阿里云开源 image-syncer 东西,容器镜像搬迁同步的终极利器

正常作业的输出:

阿里云开源 image-syncer 东西,容器镜像搬迁同步的终极利器

在作业时,image-syncer 会打印出如下的日志信息:

阿里云开源 image-syncer 东西,容器镜像搬迁同步的终极利器

从自建 harbor 同步镜像到 ACR 企业

ACR 企业版供应企业级容器镜像、Helm Chart 安全保管才干,具有企业级安全独享特性,具有千节点镜像分发、全球多地域同步才干。供应云原生运用交给链,结束一次运用改动,全球化多场景自动交给。强烈推荐安全需求高、业务多地域安置、具有大规模集群节点的企业级客户运用。

同步到 ACR 企业版和 ACR 一般版所需的操作底子相同:

1.创建 ACR 企业版实例

2.创建命名空间,并对默许仓库类型进行设置,并翻开自动创建仓库的功用

3.配备公网的访问控制,需求翻开 ACR 企业版的访问进口,并添加公网白名单,使外部能访问镜像服务

4.配备访问凭证,这部分和 ACR 一般版相同

5.运用访问凭证中创建的暗码,结束如下 image-syncer 的同步配备;与之前同步到ACR共享版不同的是,每个ACR企业版实例有自己单独的域名(一个公网可见,一个仅专有网络可见,假设镜像同步东西作业在个人环境上需求用公网域名;假设要运用仅专有网络可见的域名,则将镜像同步东西作业在阿里云ECS实例上,并且通过配备使域名对该ECS地址的专有网络可见;这儿运用的是公网域名
ruohe-test-registry.cn-shanghai.cr.aliyuncs.com),并且namespace关于每个不同企业版实例之间来说都是隔绝的。我们相同将本地树立的 harbor(http 服务,要设置i nsecure,通过 harbor.myk8s.paas.com:32080 访问)中的 library/nginx 仓库同步到 ACR 企业版实例中 image-syncer 命名空间下,并且坚持仓库名称为 nginx,config.json 如下:

{
"auth": {
"harbor.myk8s.paas.com:32080": {
"username": "admin",
"password": "xxxxxxxxx",
"insecure": true
},
"ruohe-test-registry.cn-shanghai.cr.aliyuncs.com": {
"username": "ruohehhy",
"password": "xxxxxxxx"
}
},
"images": {
"harbor.myk8s.paas.com:32080/library/nginx": ""
}
}

6.作业东西
实行指令

# 设置默许政策registry为ruohe-test-registry.cn-shanghai.cr.aliyuncs.com,默许政策namespace为image-syncer
# 并发数为10,重试次数为10
# 日志输出到./log文件下,不存在会自动创建,不指定的话默许会将日志打印到Stderr
# 指定配备文件为harbor-to-acr.json,内容如上所述
./image-syncer --proc=10 --config=./harbor-to-acr.json --registry=ruohe-test-registry.cn-shanghai.cr.aliyuncs.com --namespace=image-syncer --retries=10

输出与前述相同

更多才干

以上的 image-syncer 满足了你的容器镜像搬家同步的全部诉求吗?假设有更多的需求、甚至想共建更多的才干,欢迎访问 https://github.com/AliyunContainerService/image-syncer 留下 issue,也欢迎参与 Kubernetes 钉钉群谈论

开源不易,长时间的维护项目更不简略,我们觉得好就请给这个项目点个 star,公司内的老板会看这个项目的 star 数量来抉择后续能不能投更多的研发资源来维护这个项目,万分感谢:)

One More Thing

那么,镜像仓库能顺利搬家,是否迁云就能顺利进行呢?答案是——并没那么简略,仓库只是迁云进程中碰到的问题之一,还需求处理其他痛点。

关于现已在私有云/公有云上现已把业务运用跑在 k8s 上的用户来说,怎样让业务在迁云进程中不受影响是头等大事。阿里如此原生运用途径的处理方案架构师对此现已有了完善的考虑,力助用户运用高效安稳的搬家到 ACK 服务上。在帮忙这些用户履行迁云方案的一同,我们也在不断考虑怎样把这些案例中共性的东西做一些堆积,总结出一些优异的处理方案、最佳实践以及开发一些东西来帮忙用户快速结束迁云的这件作业,这是我们搬家进程中为用户考虑到的点

阿里云开源 image-syncer 东西,容器镜像搬迁同步的终极利器

假设你有搬家上阿里云 ACK 的需求,请点击我!等候你的留言~