Docker镜像仓库Webhook不直接构建，而是监听push事件触发外部部署：先完成构建并push镜像，仓库发送Webhook，接收端校验签名、解析tag后执行滚动更新或调用Jenkins/GitHub Actions等平台。
在 Docker 环境中，镜像仓库的 Webhook 本身不直接“构建”，而是监听 镜像 push 成功 这一事件，再触发外部系统执行部署。所谓“构建成功自动部署”，实际是：本地或 CI 系统完成构建 → docker push 到仓库 → 仓库发出 Webhook → 你的部署服务收到后拉取新镜像并更新运行实例。
确认仓库支持并启用 Webhook
主流镜像仓库均提供 Webhook 功能，但配置入口和能力略有不同：
- Docker Hub：进入仓库 Settings → Webhooks，添加公网可访问的回调地址；仅私有仓库（Pro/Team）稳定支持，公开仓库限制较多；payload 字段较简略（含 repo、tag、digest）
- Harbor：项目级别 → Webhook → 新建；支持事件过滤（如仅 push）、签名验证、失败重试，推荐用于生产环境
- 阿里云 ACR / 腾讯云 TCR：控制台中找到“事件通知”或“Webhook”模块，需确保目标地址可被云厂商网络访问，并配置对应角色权限
-
自建 Registry：开源版 distribution 默认无 Webhook，需借助
registry-webhook等代理服务，或用 containerd 的事件监听 + 自研转发器间接实现
部署端接收与安全校验
你需要一个轻量 HTTP 服务（如 Python Flask、Node.js Express 或 Go 小程序）监听 Webhook 请求，重点做三件事：
- 强制使用 HTTPS 接收，避免敏感信息明文传输
- 校验请求签名：
X-Hub-Signature-256（Docker Hub/Harbor 支持），或通过 URL 参数/请求头传入固定 token（如token=abc123），服务端比对防止伪造 - 解析 JSON payload，提取关键字段：
repository.name、push_data.tag、push_data.digest；可结合命名规范判断是否触发部署（例如只响应v[0-9].*或prod标签）
执行零停机部署动作
收到合法 Webhook 后，部署逻辑应兼顾安全与可用性：
- 若用
docker-compose：更新docker-compose.yml中对应 service 的image:字段为新 tag，再执行docker-compose pull && docker-compose up -d --no-deps --force-recreate [service] - 若用 Kubernetes：推荐调用
kubectl set image或通过 Helm/Kustomize 更新镜像，交由 Deployment 控制器执行滚动更新 - 加锁防并发：同一服务短时多次 push 可能引发多个 Webhook 并发调用，可用文件锁、Redis 分布式锁或简单队列（如
redis-cli lpush deploy-queue ...）确保串行执行 - 部署前记录当前运行容器 ID 或镜像 ID，出错时可快速
docker start回滚，或docker run拉起上一版本
与 CI/CD 工具集成（进阶推荐）
比起自建接收器，接入成熟流水线平台更可靠、可观测：
-
Jenkins：安装
Generic Webhook Trigger插件；在 Job 配置中启用，映射 payload 字段（如$.repository.name→ 参数REPO_NAME）；Webhook URL 形如http://jenkins.example.com/generic-webhook-trigger/invoke?token=xxx -
GitHub Actions：用
workflow_dispatch触发器，配合repository_dispatch事件或自定义 webhook endpoint；由 Action 脚本执行ssh登录服务器并运行部署命令 -
GitLab CI：虽不直连镜像仓库 Webhook，但可通过
trigger pipeline+API call方式间接联动，适合已用 GitLab 统一管理代码与镜像的团队
