webhook 仅由镜像推送（push）触发，不响应拉取等读操作；主流仓库均只支持 push 事件，典型流程为 push → webhook → 主动拉取/通知，Diun 可替代 webhook 实现轮询检测与通知。
镜像拉取本身不触发 webhook，webhook 是由 镜像推送（push） 事件发出的。所谓“结合 webhook 实现镜像更新自动通知”，实际是指：当新镜像被推送到仓库时，通过 webhook 通知下游系统，再由该系统主动拉取并完成更新或发送通知。整个链条是 push → webhook → 拉取/通知，而非拉取行为反向触发 webhook。
明确 webhook 的触发源头
所有主流镜像仓库（Harbor、ACR、TCR、Docker Hub）的 webhook 都只响应写操作，最常见且唯一可靠的是 push 事件。pull、pull-by-tag、login 等读操作不会触发 webhook —— 这是设计使然，也是安全考虑。
- Harbor：在“项目 → Webhook”中勾选 pushImage 事件
- 阿里云 ACR：配置“事件通知”时选择 镜像推送 类型
- 腾讯云 TCR：“事件通知”里启用 Push 镜像 触发器
- Docker Hub：Settings → Webhooks 中添加 URL，仅私有仓库支持，payload 含
push_data.tag和repository.name
用 webhook 驱动拉取与通知的典型路径
收到 webhook 后，接收端（如轻量服务、Jenkins 或自建 API）解析 payload，提取关键字段（如 repo_name、tag、digest），再执行后续动作：
Docker Image Puller
下载
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
-
主动拉取 + 重启容器：调用 Docker CLI 或 containerd API，
docker pull registry.example.com/app:v1.2，再docker stop && docker run（需保留卷、网络等配置） - 触发部署流水线：将 tag 作为参数传给 Kubernetes Helm 或 Argo CD，执行滚动更新
-
发升级通知：把
app:v1.2 已就绪推送至 Slack/钉钉/Gotify，供运维确认 - 启动安全扫描：调用 Trivy 或 Clair 对新 digest 扫描 CVE，结果异步反馈
推荐轻量落地方案：Diun + Webhook 回调
如果你只需要“发现更新→发通知”，不用自己写接收服务，Diun 是更直接的选择。它不依赖 webhook，而是主动轮询镜像仓库（支持 Harbor/ACR/TCR/Docker Hub 等），检测到新 tag 或 digest 变化后，直接推送通知：
- 配置
watch.providers.docker.watchByDefault: true监控本地运行的容器所用镜像 - 或在
diun.yml中显式声明远程镜像：registry.example.com/app:latest - 搭配 Gotify/企业微信/邮件等通知模块，模板可嵌入
{{ .Entry.Image }}和{{ .Manifest.Created }} - 无需公网暴露回调地址，规避 webhook 安全配置（如签名校验、IP 白名单）复杂度
注意事项与避坑点
真正落地时容易忽略几个关键细节：
- Webhook 接收地址必须公网可达（若部署在内网，需反向代理或内网穿透）
- Harbor/ACR 等平台默认不校验请求来源，务必启用 secret 签名 并在接收端验证
X-Harbor-Signature或X-ACR-Signature - 避免重复触发：同一镜像多次 push 同一 tag（如 :latest），建议用 digest（
@sha256:xxx）做幂等判断 - 不要指望 webhook 告诉你“该不该拉”——它只说“已推送”，是否拉取、如何更新，逻辑必须由你控制
