前面用 Portainer 把容器管得清清楚楚，但每次应用出新版本，还是得手动去拉镜像、重建容器。十几二十个容器时，更新就成了负担。Watchtower 干的就是这件事：盯着你指定容器的镜像，发现新版本自动拉取、优雅停止、用新镜像重启，应用始终跑在最新版。本文在雨云 KVM 云服务器上把 Watchtower 配成「自动更新管家」。
为什么用 Watchtower
手动更新容器的流程是「docker pull → stop → rm → run」，容器一多就烦。Watchtower 把这套自动化：
- 自动跟进新版：镜像仓库有更新，它拉下来并按原参数重建，数据卷原样保留；
- 可控范围：用 label 精确指定「哪些容器允许自动更新」，其余不动，避免误更生产服务；
- 通知到位：更新成功/失败可推钉钉、Telegram、Webhook，心里有数；
- 清理旧镜像：
--cleanup顺手删掉被替换的旧镜像，不占盘。
它和 Portainer 是两套思路：Portainer 给你「手动控制台」，Watchtower 给你「自动更新开关」。生产里建议关键服务手动、边缘服务自动，组合起来最稳。
服务器与部署
Watchtower 自己也是个容器，雨云 KVM（官网入口）Debian 12 + Docker，下单优惠码填 admin01 五折，7 天无理由退款。没用过雨云的先看 选购与上手指南。
全局模式（更新所有容器，仅适合测试机）：
docker run -d --name watchtower
-v /var/run/docker.sock:/var/run/docker.sock
containrrr/watchtower --cleanup --interval 86400
--interval 86400 是每天检查一次（单位秒）。生产更推荐标签模式：先给「允许自动更新」的容器打 com.centurylinklabs.watchtower.enable=true label，再让 Watchtower 只管带标的：
docker run -d --name watchtower
-v /var/run/docker.sock:/var/run/docker.sock
containrrr/watchtower --cleanup --label-enable --interval 86400
应用容器加 label 示例（compose 里）：
services:
myapp:
image: myapp:latest
labels:
- "com.centurylinklabs.watchtower.enable=true"
日常使用姿势
- 只更新特定容器：靠 label 控制，数据库、反向代理这类「动了容易出事」的服务不打标，永远手动；
- 加通知：加环境变量
WATCHTOWER_NOTIFICATIONS=shoutrrr与WATCHTOWER_NOTIFICATION_URL=钉钉/Telegram 的 shoutrrr 链接，每次更新结果推到群里； - 先看再更：用
--monitor-only只报告有更新、不真动手，观察几天确认稳定再放开； - 手动触发：不想等定时，给 Watchtower 发信号
docker kill -s SIGUSR1 watchtower立刻检查一轮。
踩坑记录
- 自动更新把生产搞挂：没用 label 全量更新，某个 breaking change 的镜像直接让服务起不来。务必
--label-enable，只更新边缘、非关键容器，核心服务手动升级并先备份。 - 数据卷没丢但配置丢了：Watchtower 只换镜像、不动卷，数据通常安全；但有些镜像新版改了配置路径或环境变量，重建后得按新镜像要求补环境变量，更新前先看 release note。
- 镜像越堆越多：不清理旧镜像会占盘，加
--cleanup让更新后删旧层。 - 通知没收到：shoutrrr URL 格式错最常见，先单独测通通知 URL 再写进 Watchtower。
合规提醒
自动更新会改变线上服务版本，请先在测试环境验证再放开生产容器，避免因镜像 breaking change 导致业务中断；核心、含用户数据的服务建议保持手动更新并提前备份。依据《网络安全法》《数据安全法》，更新操作应可回溯、有通知。
小结
容器多了，更新是最容易被拖的事。Watchtower 用标签把「自动更新」和「手动管控」划清边界：边缘服务交给它每天自动跟进，核心服务留在 Portainer 里手动把握。雨云 KVM 1 核 1G 就能跑 Watchtower，优惠码 admin01 五折——把「记得去更新」变成「它自己会更新，结果推给我」，运维省下一截心力。
