自动更新适合低风险容器，高价值数据服务仍然要人工确认。

\n
Watchtower 很容易让人心动：它能自动检查新镜像、拉取、重建容器，还能清理旧镜像。对家庭服务器来说，这确实能减少维护负担。但自动更新不是免费的省心，它只是把“什么时候升级”这件事交给了一个定时任务。如果范围没控好，某天早上醒来发现几个核心服务一起换了版本，排障压力会很大。

我现在只把 Watchtower 用在低风险容器上。仪表盘、轻量工具、状态页、临时服务可以考虑自动更新；数据库、密码管理、同步任务、承载重要资料的应用，我更愿意手动升级。高价值服务需要先看变更、做备份、留回滚版本，再观察运行。

label-enable 是边界

我不会让 Watchtower 默认扫描所有容器，而是开启 --label-enable，只更新明确打标签的服务。

services:
  watchtower:
    image: containrrr/watchtower:1.7.1
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    command: --cleanup --label-enable --schedule "0 0 4 * * *"

  homepage:
    image: ghcr.io/gethomepage/homepage:v0.9.12
    labels:
      - "com.centurylinklabs.watchtower.enable=true"

这样新增服务时不会被自动纳入更新。哪个服务要自动更新，必须在 Compose 里明示。这个小边界很重要，因为 HomeLab 服务经常是陆续加的，今天随手启动一个测试容器，明天它不应该被自动升级任务悄悄接管。

低风险不等于不用观察

就算是低风险服务，我也会给自动更新安排时间窗口。比如凌晨四点更新，早上巡检时看一次状态。不要把更新时间放在家里正在使用服务的高峰，也不要让它和备份、磁盘校验、系统升级挤在同一时间段。

更新后至少看四件事：

docker logs --tail=160 watchtower
docker compose ps
docker compose logs --tail=120 homepage
docker image ls

Watchtower 日志能告诉我它处理了哪些容器；compose ps 看有没有重启异常；服务日志看新版有没有配置警告；镜像列表看旧镜像是否按预期清理。自动更新不是拉完镜像就结束，观察才是闭环。

回滚要提前准备

如果一个服务用 latest，回滚会很难。你可能知道今天更新坏了，却不知道昨天跑的是哪个版本。所以哪怕启用 Watchtower，我也更偏向给镜像写明确版本，或者至少记录更新前的镜像 digest。对低风险工具可以放宽，对核心服务不要省。

高风险服务如果要升级，我会手动做：

docker compose pull app
docker compose up -d app
docker compose logs --tail=160 app

升级前先备份 config 和 data，升级后确认页面、登录、定时任务、数据读写都正常。出问题时，把镜像版本改回旧值，再恢复备份。这个流程慢一点，但不会把多个服务同时推到未知状态。

不要忽略 Docker socket 风险

Watchtower 也需要访问 Docker socket。它能重建容器，权限并不低。它的 Compose、访问网络和日志都应该清楚，不要把它当成无害小工具。尤其是开启通知、私有镜像仓库认证时，变量里可能有敏感信息，.env 和备份权限要处理好。

我的实际策略

我把自动更新分成三档：低风险展示类服务可以 label-enable；中等风险服务只提醒不自动重建；高风险服务完全人工升级。每个月固定看一次镜像版本和变更，顺手清理不用的旧镜像。这样 Watchtower 帮我减少重复劳动，但不会替我决定所有升级。

自动更新适合解决“我忘了维护”的问题，不适合解决“升级一定安全”的问题。边界、窗口、观察和回滚都准备好，它才是 HomeLab 的助手，而不是新的故障来源。