镜像拉取本身不会触发自动同步更新，需借助外部服务实现定时检查与更新：watchtower适用于容器级自动更新，diun适用于镜像变更通知，jenkins/cron+skopeo或harbor复制策略适用于仓库级批量同步，webhook仅响应push事件而非pull。
镜像拉取本身不会触发自动同步或更新，它只是一个被动操作。要实现“自动化定时同步更新”，核心思路是：让一个外部服务定期检查远程镜像是否有新版本，发现变化后主动拉取并应用（如更新容器），整个过程无需人工干预。
用 Watchtower 实现容器级自动更新
Watchtower 是最常用、最轻量的方案，适合已运行容器的持续更新：
- 它以容器形式运行，挂载宿主机的
/var/run/docker.sock，可读取本地所有容器信息 - 默认每 24 小时轮询一次镜像仓库（如 Docker Hub、Harbor、ACR），检查当前容器所用镜像是否存在新 tag 或 digest
- 检测到更新后，自动执行
docker pull，再优雅停止旧容器、用相同配置启动新容器 - 支持精确控制范围：可指定只监控
nginx和redis，不碰其他容器 - 通过
--interval 300设为每 5 分钟检查一次，或用--schedule "0 0 * * *实现每天零点执行 - 加
--cleanup参数可在更新后自动清理旧镜像，节省磁盘空间
用 Diun 实现镜像级变更通知
如果你不需要自动重启容器，只希望“知道有新镜像了再手动处理”，Diun 更合适：
minimax-mcp-docker版（适配极空间）
下载
MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。
- 它不依赖 Docker 守护进程，而是直接对接镜像仓库 API（支持 Docker Hub、Harbor、ACR、TCR 等）
- 可配置为轮询特定镜像（如
my-registry/app:latest）或监听本地运行中的容器所用镜像 - 检测到新 tag 推送或 digest 变化时，直接推送通知到 Slack、钉钉、Gotify 或邮件
- 无需暴露公网回调地址，规避 webhook 的签名校验、IP 白名单等运维负担
- 通知内容可定制，例如嵌入
{{ .Entry.Image }}和{{ .Manifest.Created }}显示镜像名与构建时间
用 Jenkins Pipeline 或 cron + skopeo 实现仓库级批量同步
适用于跨仓库、跨地域的镜像复制场景（比如把 GitHub 构建的镜像同步到私有 Harbor）：
- 用
skopeo copy命令完成镜像层级复制，支持校验和验证，保证一致性 - Jenkins Pipeline 可结合
git pull检测源代码变更，再触发docker build和skopeo copy - 纯脚本方式可用
cron定时执行 shell 脚本，例如每 30 分钟检查一次 git commit 变更，有更新则同步对应镜像 - Harbor 自带复制策略，支持 push 或 pull 模式，配置后由 Harbor 后台自动完成同步，适合企业级多项目管理
注意：Webhook 不是拉取的触发器
很多人误以为“拉取镜像能发 webhook”，其实所有主流仓库（Docker Hub、Harbor、ACR、TCR）的 webhook 都只响应 push 事件，pull、login 等读操作不会触发。所谓“webhook 驱动更新”，真实链路是：开发者 push 新镜像 → 仓库发 webhook → 你的服务收到后调用 docker pull。这需要你自建接收端，而 Watchtower 和 Diun 已内置轮询逻辑，省去这一环。
