别让 NAS 上的容器悄悄过期：给 Docker 服务排一套自动更新与回滚

在 NAS 上用 Docker 跑服务已经是很多家庭玩家的标配：相册、笔记、媒体库、反向代理，一个容器拉起来就能用。但方便的另一面是容易忘了管，不少人的 NAS 里还跑着两三年前的旧镜像，里面可能已经积了若干个已知漏洞。本文讲清楚容器为什么会悄悄过期，如何给它们排一套自动更新与回滚的机制，既保持新鲜又不至于一夜回到解放前。

一、为什么容器会悄悄过期

Docker 镜像不是装好就一劳永逸。你当年拉的是某个时间点的快照，之后上游修了漏洞、发了新版，本地的镜像不会自己变。更麻烦的是很多人习惯用 latest 标签，首次拉取后便再没碰过，时间一长连自己跑了什么版本都记不清。等到某天 CVE 通报出来，才知道那台一直很乖的容器早该升级了。

二、Watchtower：让镜像自己保持最新

社区里最省心的工具是 Watchtower。它定时去镜像仓库比对摘要，发现新版本就自动拉取并替换掉正在运行的容器，连通知都能推到你的即时通讯工具。对于纯无状态的小工具，比如网络测速、短链服务，开着自动更新基本不用操心。

但它是一把双刃剑：自动替换意味着你放弃了人工确认的机会。一个带破坏性变更的大版本可能让配置不兼容，容器起来却跑偏了。所以自动更新适合无状态服务，有状态的核心服务要谨慎。

三、先备份数据卷，再谈升级

无论手动还是自动，升级前第一件事永远是确认数据卷已备份。Docker 的数据通常放在挂载出来的卷或宿主机目录里，容器本身可以随便删，卷里的数据才是命根子。建议在更新前对关键服务的目录做一次快照式拷贝，最好纳入你既有的 3-2-1 备份体系。这样即便新镜像出问题，你丢的也只是几分钟的服务时间，而不是数据。

四、避开 latest：用固定版本号

想睡得安稳，就别再用 latest。改成固定的版本标签，比如把镜像写成 nginx:1.27 而不是 nginx:latest。这样做的好处是升级可控：你主动去改版本号才升级，而不是被自动拉来的未知版本推着走。配合 Watchtower 的监控模式（只报告不替换），你能先看到有新版本，再决定什么时候、在哪个维护窗口动手。

五、升级失败如何回滚

回滚的核心是记得上一版的标签。升级前把当前镜像版本记下来，或者直接保留旧镜像不删除。一旦新版本起不来或功能异常，用原来的标签重新跑一个容器，把同一个数据卷挂回去，服务几分钟内就能恢复。如果用的是编排文件，把镜像版本写进配置里并纳入版本管理，回滚就是改一个数字的事。切记：回滚恢复的是应用，数据卷要始终独立、不被回滚动作覆盖。

六、哪些服务不该自动更新

数据库、家庭网络的核心网关、以及任何保存了唯一状态的服务，不建议无脑自动更新。它们一旦因为版本跳跃出问题，影响的是全站而不是单个小工具。给这类服务单独设成监控模式，只在你手动验证过新版本兼容性后再升级。另外，重要的更新尽量放在你醒着、能立刻响应的时间段，别安排在深夜自动执行。

容器运维的本质是让更新变成一件有准备、可撤销的平常事。固定版本号掌握主动权，数据卷备份守住底线，Watchtower 负责提醒和轻量服务，回滚预案兜住意外。做到这四点，你 NAS 上的那些小服务就能长期保持新鲜，又不会哪天突然给你摆脸色。