河北
自动更新通常是无缝的，一般也值得推荐，直到某次它在您睡觉时破坏了您的系统。这就是我用Watchtower的亲身经历。它一直很可靠，直到一次半夜的例行更新让我的一个容器陷入了重启循环。我花了整个上午来修复它。
然而，一劳永逸的办法是我用OliveTin构建的一个小型调度器，只在我手动操作时才更新。从那以后，我再也没在半夜被更新搞崩溃过。
自动更新，真不是省心的朋友
真正的问题不是软件差，而是失去了控制权
然而，我忽略了一个重要的细节，不过这其实不怪Watchtower。问题在于，即使一个容器被标记为latest，这个标签并不能说明更新里有没有会搞坏东西的改动。这就是为什么我的媒体服务器容器在拉取了一个引入了数据库架构变更的更新后，陷入了反复崩溃重启。整个过程中我都没有收到什么实际预警，而且即使Watchtower发送了通知，我也是等出了问题才看到那条通知。通知是发了，我也知道出了事，但它动手之前根本没问过我。
不过，我并不是想要更少的更新；我只是需要在这个过程中有更多选择权，能选“先不”“等会儿”或者推迟更新。这样，我就能决定变更何时发生，而不是等事情发生了才知道。
OliveTin改变了我的工作流程
我终于把更新和调度分开了
整个流程是这样的：调度器在我选的时间触发，调用一个OliveTin操作，该操作运行更新脚本，脚本调用Docker Compose来拉取并重新创建容器，最后，一个webhook发通知告诉你搞定了（调度器 -> OliveTin -> 更新脚本 -> Docker Compose -> 通知）。
真正关键的，其实是把触发器和更新逻辑分开，这比OliveTin本身还重要。两者成为独立实体后，我可以根据每个服务的情况，把触发时间安排在合适的时候。我不再靠一个无人值守的更新时间表来管所有事情了。
这套方案很理想，因为它在Linux、Docker Desktop或WSL主机上都能跑。容器也好，OliveTin也好，都不在乎自己跑在哪台主机上。
最大的升级，其实不是OliveTin
维护变得可预期之后，一切都变了
我的更新流程还是很无聊，但这是好事。现在更新只在备份完成之后、而且服务没人用的时候才跑。更新跑的时候，我通常还醒着，人也在电脑前。这听起来好像是小事，但如果你有过一觉醒来发现容器挂了这种经历，你就会懂这个细节有多重要。
每一步我都清楚发生了什么变化以及何时发生，这样我需要排查问题时也更容易。另外，我是看着服务重启的，而不是几天后才发现问题，所以回滚也更方便。这套流程我更信得过。
表格里看不出来这套方案如何帮我不再惧怕更新。Watchtower 的任何单一功能，都比不上提前知道什么时候会有变化。
不同的家庭实验室需要不同的更新策略
尽管我已经换成了自定义调度器进行更新，但 Watchtower 在我这套东西里还是有用的。对于开发容器和其他用完就扔的资源，如果其中一个坏了，我可以重新建一个接着用。这些我不用一直盯着。
说到底，这不只是换个工具替代 Watchtower 那么简单。我决定自己掌控容器的更新时机。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
