企业官网建设流程全解析

如何用Zot做跨区域镜像复制：定时与按需同步完整指南

【免费下载链接】zotzot - A scale-out production-ready vendor-neutral OCI-native container image/artifact registry (purely based on OCI Distribution Specification)项目地址: https://gitcode.com/GitHub_Trending/zo/zot

Zot 是一个 OCI 原生的容器镜像/制品仓库，它内置的 sync 扩展能持续从远程仓库把镜像内容拉到本地实例——这正是实现跨区域镜像同步的核心机制。

镜像同步解决的是什么问题

如果你的业务跑在多个地域，而镜像都从中心仓库拉，高峰期拉取又慢链路又长；如果只有一个 registry，它一挂所有地域跟着遭殃；开发和生产共用一个 registry 时，标签又容易串，生产环境可能拉到不该拉到的版本。镜像复制的本质，就是给每个地域就近放一份“本地副本”：拉取链路变短，主仓库出事也不至于全线停摆。

📦 三步跑通第一个 Zot 同步

所有配置都挂在extensions.sync节点下，跑通最小配置只需三步：

1. 写一个凭证文件，存远端仓库的账号密码或 token；
2. 在registries里填远端地址，指定凭证路径，把enable打开；
3. 重启 zot，第一轮同步会在下一个轮询点自动开始。

{ "extensions": { "sync": { "enable": true, "credentialsFile": "./sync-auth.json", "registries": [ { "urls": ["https://registry.example.com"], "pollInterval": "6h", "content": [{ "prefix": "/myapp/**" }] } ] } } }

registries是一个数组，可以同时挂多个远端源，每份配置有独立的轮询间隔和过滤规则，上面这份就是最精简的定时同步。

🔍 Zot 定时同步怎么配，按需拉取是什么机制

到点自动跑：定时同步

pollInterval控制同步频率，示例值"6h"表示每 6 小时跑一轮全量检查。每一轮里，同步引擎按content规则枚举目标仓库、比对标签，只把新增和变化的部分拷过来，本地已存在的 blob 直接复用不重复传输。你不用关心上游什么时候推了镜像，下一轮定时跑就会追平。

用多少拉多少：按需同步

定时同步覆盖不了所有标签。把onDemand设为true后，客户端请求一个本地不存在的镜像时，Zot 会当场从远端把它拉下来再响应，相当于加了一层“透明代理”：

{ "urls": ["https://index.docker.io"], "onDemand": true, "syncTimeout": "10m", "maxRetries": 5 }

这种模式的价值在于不用预heat所有标签：成百上千个长尾镜像，第一次被用到时才进本地，磁盘占用始终可控。

两种模式不互斥

同一条 registry 配置里可以同时给pollInterval和onDemand: true：热门镜像靠定时轮询保持新鲜，长尾镜像靠按需拉取兜底，这是生产里最省心的组合。

🗺️ 过滤与路径映射：只同步你要的镜像

content数组是规则主体，每条用prefix指向远端的仓库路径，**表示覆盖所有子路径。

你只想同步 4.x 版本？加一行就行：

"tags": { "regex": "4.*", "semver": true }

regex负责正则匹配标签，semver: true会再按语义化版本筛一遍，4.2.1能进，4beta这类不符合规范的就进不来。反过来黑名单用excludeRegex，比如排除以-(amd64|arm64)$结尾的标签，就只保留多架构索引、不重复拉单架构镜像。

路径映射是更进一步的玩法：destination指定内容落到本地的哪个前缀，stripPrefix: true表示剥掉原前缀——

{ "prefix": "/team-a/**", "destination": "/prod", "stripPrefix": true }

这样/team-a/web落到本地就是/prod/web，命名空间随你规划，不会和上游结构硬绑定。

🛡️ Zot 镜像同步上生产，先避开这几个坑

• TLS 校验：tlsVerify别图省事关成false，内网自签证书场景应该把 CA 放进certDir（如/etc/zot/certs）再保持校验开启；关掉校验等于明文裸奔。
• 重试：跨地域链路抖动很常见，maxRetries配 3 左右、retryDelay给个"5m"之类的间隔，一次断网不至于让整轮同步失败；不配的话，偶发超时就会留下没同步完的仓库。
• 超时：大镜像层多，syncTimeout建议放宽到"10m"；不设的话，大镜像中途超时，下一轮还得从头再传。
• onlySigned：打开onlySigned后只放行带有效签名的镜像，防止未审计的内容顺着同步通道混进你的 registry；前提是上游确实有签名流程，否则什么都同步不进来。

🌏 三个有画面感的落地场景

跨区分发：每个地域放一台 zot 实例，urls统一指向中心仓库，热门镜像pollInterval给 6 小时加onDemand兜底。业务从“跨地域拉取”变成“地域内拉取”，高峰期延迟肉眼可见地降下来。

灾备备份：给远端备份仓库单独配一条更长周期（比如 12 小时）的规则，prefix: "**"配semver: true，只留语义化版本标签，形成一份可回滚的干净快照。主仓库出故障时，业务改指备份实例即可顶上。

环境隔离：开发和生产用独立实例，生产只同步上游的/team-a/**前缀，再用destination映射到/prod命名空间。开发标签根本进不了生产，版本流动被限制在同步通道里，想推什么全由配置说了算。

把sync配好之后，跨区域复制就从“手工 cron + rsync”变成了一段声明式配置，剩下的事交给引擎。想看更多字段和细节，可以直接翻 sync 扩展源码，以及仓库里带完整过滤、重试、TLS 示例的配置 examples/config-sync.json。

【免费下载链接】zotzot - A scale-out production-ready vendor-neutral OCI-native container image/artifact registry (purely based on OCI Distribution Specification)项目地址: https://gitcode.com/GitHub_Trending/zo/zot