容器自动更新开还是关？按这棵决策树决定，再配维护流程

容器越跑越多之后，更新就成了一件绕不开的事。一个个手动拉镜像、停容器、再启动，费时又容易出错；全部交给自动更新，又怕半夜某个服务悄悄升级后起不来，第二天才发现。本文不直接给你一个开或者关的答案，而是给一棵决策树：按服务的性质一步步往下走，走到叶子节点，自然就知道这个容器该用什么更新策略。

本文提到的工具行为按公开文档与项目说明核实，核实日期为 2026-11-09。凡是写了「未核实」的地方，都是没有验证过的说法，不要把它当成事实。不同工具的默认行为差别很大。

先说风险：自动更新最怕的不是更新本身

先备份，再动手。自动更新的本质，是让程序在你不在场的时候停掉旧容器、拉新镜像、再启动新容器。如果新版本有兼容问题，或者更新过程中断电断网，服务可能停在一个起不来的状态。数据卷里的数据一般不会因为换镜像而消失，但数据库升级失败、配置文件格式变化，都有可能造成数据损坏或丢失。开自动更新之前，先确认重要数据有备份，而且备份真的能恢复。

生产服务与个人实验服务的标准不一样。家里跑的练手项目，更新失败大不了重装一次；对外提供服务、存着重要数据、或者家人正在用的服务，更新失败就是一次服务中断。决策树的第一条分叉就是这个区别，先分清服务的性质，再谈要不要自动更新。

自动更新不等于不用管。哪怕开了自动更新，也需要有人定期看日志、确认服务状态、处理失败的更新。把自动更新当成完全不用管的方案，是最常见的误解。

决策树第一层：这个服务有多重要

先问自己三个问题。第一，这个服务停一两个小时，会不会影响别人使用；第二，服务里有没有不能丢失的数据；第三，服务出问题后，能不能在半小时内恢复。三个问题的答案，决定了这个服务走哪条分支。

如果三个答案都是影响很小。例如本地跑的练手项目、临时测试用的工具、没有重要数据的演示服务，这类服务可以直接走自动更新分支。更新失败的影响有限，恢复成本也低，自动更新省下的时间比它带来的风险更值得。

如果任何一个答案是影响很大。例如存着照片与文档的网盘、家人的媒体服务、对外开放的网站、存着账本的数据库，这类服务不要直接开全自动更新。它们应当走受控更新分支，也就是先收到更新通知，再由人决定什么时候更新。

拿不准的时候，默认走受控分支。判断服务重要性时，人很容易低估自己数据的价值。拿不准就先按重要的处理。这个保守的默认选择，是决策树里最重要的一条规则。

决策树第二层：选哪种更新模式

模式一是全自动更新。工具定期检查镜像仓库，发现新版本就拉下来并重启容器。适合前面判断为影响很小的服务，优点是省心，缺点是一旦新版本有问题，服务会在无人值守的时候出问题。

模式二是仅通知不更新。工具只检查有没有新版本，发现之后发一条通知，是否更新由人决定。适合大多数个人服务，既不会错过安全更新，也不会在半夜被一次有问题的更新打断服务。通知渠道要选一个你真的会看的渠道。

模式三是定时窗口更新。只在你指定的时间段里自动更新。适合白天有人在用、晚上没人用的服务。定时窗口的好处，是把更新失败的影响限制在你有空处理的时间段里。

决策树第三层：这个服务能不能安全地自动重启

无状态服务最适合自动更新。只提供计算与展示、不长期保存数据的服务，例如一些前端工具与接口服务，重启后重新拉起就能恢复，更新失败的影响也有限。这类服务即使开了全自动更新，风险也相对可控。

有状态服务要先看数据怎么保存。数据库、文件同步、笔记服务这类有状态的服务，数据保存在数据卷里，容器重启本身不会丢数据，但新版本升级数据格式时可能出问题。升级之前要确认新版本是否要求先备份、是否支持从旧版本直接升级。升级路径未核实之前不要自动更新。

决策树第四层：更新失败了怎么办

第一步是看日志，不要急着重装。更新失败后，先看容器的日志与更新工具的日志，确认是拉镜像失败、启动失败还是健康检查没通过。拉镜像失败多半是网络或仓库问题；启动失败则可能是新版本不兼容，要按下面的回滚流程处理。

第二步是回滚到上一个能用的版本。回滚之前先确认旧镜像还在本地，旧的数据卷没有被覆盖。固定版本的服务回滚很直接，把版本号改回去再启动就行；追最新版的服务回滚要麻烦一些，需要知道上一个能用的镜像版本。

第三步是把这个服务移出自动更新。同一个服务连续两次更新失败，就说明它不适合当前的自动更新策略，应当先把它改成仅通知或手动更新，等查清原因、确认新版本没问题之后，再考虑恢复自动更新。反复让一个有问题的服务自动更新，只会反复制造中断。

常用工具与维护流程

自动更新工具的代表是 Watchtower。它本身也是一个容器，定期检查其他容器的镜像，发现新版本就拉下来并重启容器。它的默认检查间隔在不同资料里的说法并不一致，有的写每 24 小时，有的写每 5 分钟，本文未核实当前版本的默认间隔，使用前请以官方文档为准。它的更新范围可以用标签限制，只更新你标记过的容器。

仅通知的工具适合不想自动重启的人。例如只检查新版本并发送通知的工具，更新动作仍然由人来做。这类工具的名字与具体配置因项目而异，本文未核实某一款工具的当前版本与配置细节，选用前请核对它的项目主页。选工具之前先定模式，定了模式再找对应工具，不要反过来先装一个工具再决定策略。

每周做一次快速检查。看一遍所有容器的运行状态，确认没有容器反复重启；看一遍更新通知，决定哪些更新这周做、哪些下周做；看一遍磁盘使用量，确认日志与旧镜像没有把磁盘写满。

每月做一次完整维护。先备份重要数据，再按计划更新一批容器，更新后逐个验证服务是否正常；清理已经不用的旧镜像与停止的容器，释放磁盘空间；检查一次备份能不能恢复，不要等到真正需要恢复时才发现备份是坏的。

一张表收尾：按服务类型直接对照

无状态小工具，数据不重要，恢复容易，可以开全自动更新；个人常用服务，有数据但能恢复，适合仅通知或定时窗口更新；数据库与核心服务，数据重要、升级有风险，适合固定版本手动更新；对外提供服务或家人正在用的服务，中断影响大，适合固定版本手动更新加定期检查。拿不准的服务先按更保守的一档处理。

自动更新不是越自动越好，维护也不是越频繁越好。按决策树给每个服务定一个合适的策略，再配一套每周与每月的检查流程，就能一直清楚每个服务的状态。