Somincola Garden
Back to the journal

Articles are currently published in Simplified Chinese.

让更新不再靠记忆：Mastodon 的自动维护流程

记录本站如何自动检查 Mastodon 新版本、验证自定义功能、构建容器镜像，并在通过检查后完成服务器更新。

By Somincola Garden
  • Mastodon
  • 站点运营
  • 自动化
  • Docker
  • 技术实践

维护 Mastodon 小站时，有些工作看起来只是“换一个版本号”，实际却包含许多不能漏掉的步骤：查看上游更新、确认自定义功能还能使用、分别构建 Web 和 Streaming 镜像、执行数据库迁移，再检查服务是否恢复正常。

如果每次都靠站长临时回忆，很容易在忙碌时遗漏某一步。

因此，Somincola Garden 现在有了一套自动维护流程：定期检查 Mastodon 新版本，在干净的官方源码上验证本站定制，通过后才构建镜像并更新服务器。

它会自动完成什么

当前流程每周检查一次 Mastodon 4.6.x 稳定版本，也可以由管理员手动启动。

GitHub Actions 中的 Mastodon 自动维护工作流与手动运行选项

大致顺序是：

发现新的稳定版本
        ↓
检查 5000 字与 Explore Patch
        ↓
构建 Web 与 Streaming 镜像
        ↓
拉取镜像并执行数据库迁移
        ↓
重启服务、记录版本与发布说明

一次成功运行的版本检测、Patch 验证、镜像构建与服务器部署流程

如果没有新版本，流程会直接结束，不重复构建相同镜像。遇到重要安全更新时，管理员也可以手动指定版本并立即执行，不必等待下一次定时检查。

为什么只自动跟进 4.6.x

自动化最重要的不是“追得最快”，而是知道什么时候应该停下来。

目前流程只会自动选择 v4.6.0、v4.6.1、v4.6.4 这类正式补丁版本，不会自行跳到 4.7 或更大的版本，也不会采用测试版和预发布版。

新的大版本可能改变数据库、前端资源、管理页面或 Docker 构建方式，需要先阅读官方升级说明并进行人工评估。把自动更新限制在已经确认过的版本线，可以兼顾安全修复速度和小站稳定性。

先验证本站功能，再开始构建

本站目前保留两项 Mastodon 定制：

  • 本地嘟文上限为 5000 字符。
  • Explore 热门嘟文、话题标签与链接阈值可以在后台调整。

它们分别放在独立 Patch 中。每次检测到新版本后，流程会另外下载一份干净的官方源码，先检查两份 Patch 能否完整应用，再检查相关 Ruby 文件、配置文件、中英文后台文案和关键字段。

只要其中一项不兼容，流程就会停止：

  • 不会构建带有残缺功能的镜像。
  • 不会连接生产服务器。
  • 正在运行的旧版本不会因为这次检查而被替换。

站长会根据失败位置重新适配 Patch，确认后再手动启动流程。

为什么要同时构建两种镜像

Mastodon 的主要网站、后台任务和实时流服务并不完全使用同一个容器入口。

自动流程会从同一个官方版本分别构建：

  • Mastodon Web 镜像，供 Web 与 Sidekiq 使用。
  • Mastodon Streaming 镜像，负责实时时间线与事件推送。

两者都带有明确版本号，同时更新 latest 标签。服务器上的 Compose 配置继续使用这两个稳定的 latest 镜像名，而版本标签则用于记录和必要时排查问题。

这样可以避免网站已经更新、Streaming 却仍停留在旧版本的情况。

服务器更新时发生了什么

镜像全部构建成功后，流程才会连接服务器，并依次执行：

  1. 拉取最新的 Web 与 Streaming 镜像。
  2. 用新 Web 镜像运行 Mastodon 官方数据库迁移。
  3. 迁移成功后重新创建服务容器。
  4. 清理不再使用的旧镜像层。
  5. 记录本次构建版本并生成发布说明。

数据库迁移通过临时容器执行，完成后容器会自动删除。它的作用是让数据库结构与新版本代码保持一致，不会清空嘟文、账号或媒体数据。

不过，自动执行不代表不需要备份。数据库和媒体存储仍然要按照日常维护计划备份；涉及较大版本的升级，也不会直接交给这条自动流程。

对小站运营有什么意义

这套流程带来的变化不是“站长从此不用维护”，而是把容易重复和遗漏的步骤固定下来。

安全更新可以更快跟进

遇到只包含安全修复的补丁版本时，不需要重新手工准备整套构建命令。管理员确认发行说明后即可启动同一条流程。

自定义功能不再靠上线后发现问题

5000 字和 Explore 设置会在构建前接受兼容性检查。上游发生变化时，我们会先在 GitHub Actions 中看到失败，而不是等新容器启动后才发现后台字段或 Patch 缺失。

每次更新都有记录

成功构建后会保存对应的上游版本、镜像标签和本站定制内容。之后排查问题时，可以确认服务器更新来自哪个 Mastodon 版本。

维护中断更可控

版本检测或 Patch 检查失败时，生产服务器不会发生变化。只有镜像完整构建后，流程才进入部署阶段，减少了维护窗口中的临时操作。

自动化仍然保留人工边界

我们没有把更新设计成完全无人值守。

管理员仍需要：

  • 阅读 Mastodon 官方发行说明和安全公告。
  • 判断新版本是否需要额外维护步骤。
  • 处理 Patch 不兼容和构建失败。
  • 检查数据库、媒体存储和备份状态。
  • 在部署后确认网页、实时流和后台任务正常。

自动流程负责执行已经确定的步骤，站长负责决定这些步骤是否应该执行，以及失败时怎样处理。

一点站长记录

小站维护经常发生在大家看不到的地方。一次顺利更新背后，可能只是几分钟的短暂重启，也可能包含版本筛选、镜像构建、数据库迁移和兼容性检查。

把这些过程自动化之后，我可以把更多注意力放在真正需要判断的部分：这次更新有什么影响、社区正在遇到什么问题、哪些小修补仍然值得保留。

服务器花园仍然需要打扫，只是现在工具放得更整齐了。🌿

技术资料