n8n模板：Docker镜像升级前自动评估数据库迁移风险

原文要点

原模板为免费n8n工作流：每天06:30定时运行，请求自建What's Up Docker（WUD）实例的容器列表，筛出有待升级标签的镜像；从WUD链接模板识别GitHub仓库，解析当前与目标release tag；拉取目标版本发布说明并比较两tag间改动的迁移文件与SQL补丁；先按简单SQL规则把升级分为SAFE/CAUTION/DANGER/UNKNOWN，再让LLM（OpenAI兼容Chat Completions端点或Ollama）总结原因并给出预检SQL；最终把判定、摘要与GitHub compare链接推送到ntfy、Slack、Discord或自定义webhook。可选配置GitHub token避免匿名低限流。

这次做成什么

每天自动回答一个问题：今天这批待升级的镜像里，哪些动了数据库、升级前要先跑什么检查。练习用一条合成WUD容器与一段伪造迁移diff，验证规则分类与LLM摘要是否按预期产出通知。

准备什么

• 正在运行的What's Up Docker（WUD）实例及其base URL
• 可登录的n8n实例（Cloud或自托管），能访问WUD与GitHub
• LLM二选一：OpenAI兼容端点及API key，或本地Ollama端点
• （建议）GitHub personal access token，避免匿名拉取的低限流
• 通知渠道之一：ntfy主题、Slack webhook、Discord webhook或自定义webhook URL

具体怎么做

1. 填WUD地址

   导入模板后在Template Config里填WUD base URL。先在浏览器直接访问该地址的容器列表接口确认n8n所在网络能通，再手动执行一次工作流看是否拉到容器数据。

2. 配置LLM提供方

   在Template Config选provider：用OpenAI兼容服务就填endpoint、model和API key；用Ollama就填本地端点与模型名。原文未指定具体模型，填你账号里实际可用的即可。

3. 加GitHub token

   在Template Config填入GitHub token，避免抓取release与compare数据时撞匿名限流；只拉公开仓库给只读权限即可。

4. 选通知渠道

   四选一填目标URL：ntfy需topic（如启用鉴权再加Bearer token）；Slack/Discord填webhook地址；自定义webhook则按你的接收端约定字段。

5. 手动跑一次练习数据

   把计划触发先改为手动，用材料三的合成容器与伪造diff验证：规则分类是否命中、LLM摘要与预检SQL是否合理、通知里是否带GitHub compare链接。确认后再恢复每天06:30。

可直接复制的材料

{
  "rules": [
    {"level": "DANGER", "patterns": ["DROP TABLE", "DROP COLUMN", "TRUNCATE", "DELETE FROM", "ALTER TABLE .* DROP"], "reason": "存在不可逆或破坏性数据操作"},
    {"level": "CAUTION", "patterns": ["ALTER TABLE", "ADD COLUMN", "CREATE INDEX", "UPDATE .* SET", "INSERT INTO"], "reason": "结构变更或数据改写，需备份并预检"},
    {"level": "SAFE", "patterns": [], "condition": "noMigrationFilesChanged", "reason": "两版本间无迁移文件与SQL补丁改动"},
    {"level": "UNKNOWN", "patterns": [], "condition": "fetchFailedOrNoRepo", "reason": "无法识别仓库或拉取失败"}
  ]
}

你是数据库升级风险评估助手。输入：镜像名image、当前版本fromTag、目标版本toTag、规则初判等级ruleLevel与命中原因ruleReason、两版本间变更的迁移文件名列表migrationFiles、SQL补丁摘要sqlSnippets、发布说明摘录releaseNotes。
请输出JSON：{"summary":"不超过80字，说明这次升级对数据做了什么","riskAgree":true或false,"adjustedLevel":"SAFE/CAUTION/DANGER/UNKNOWN","precheckSql":["升级前建议执行的只读检查SQL，最多3条"],"notes":"给运维的一句话建议，含是否需要备份"}。
要求：precheckSql只允许SELECT语句；不确定时adjustedLevel保持UNKNOWN并在notes说明原因；不要编造迁移文件里不存在的表名。
只读检查只能引用升级前已经存在的表和字段；本次ADD COLUMN新增的字段不能出现在升级前查询中。

{
  "wudContainer": {"name": "vikunja-demo", "image": "vikunja/vikunja", "currentTag": "0.24.6", "updateTag": "0.25.0", "link": "https://github.com/go-vikunja/vikunja"},
  "migrationDiff": "+ ALTER TABLE tasks ADD COLUMN position double precision;\n+ UPDATE tasks SET position = id WHERE position IS NULL;\n+ CREATE INDEX idx_tasks_position ON tasks(position);"
}

输入与输出示例

本站采用PostgreSQL语法独立编写的虚构演示，非模板真实运行结果；查询只使用升级前已有对象。

输入

容器vikunja-demo从0.24.6升级到0.25.0，compare发现迁移改动：ALTER TABLE tasks ADD COLUMN position、UPDATE tasks SET position = id、CREATE INDEX idx_tasks_position。

对应输出

{"ruleLevel":"CAUTION","llm":{"summary":"新版本给tasks表新增position列并回填历史数据、建索引","riskAgree":true,"adjustedLevel":"CAUTION","precheckSql":["SELECT count(*) FROM tasks;","SELECT pg_size_pretty(pg_total_relation_size('tasks'));"],"notes":"大表回填UPDATE可能锁表，建议备份后低峰执行"}}，通知payload推送判定CAUTION、摘要与GitHub compare链接至ntfy主题homelab-updates。

做完检查这些

• 手动执行后能从WUD拉到容器列表，且只保留有待升级标签的条目
• 含ALTER TABLE的伪造diff被规则判为CAUTION，DROP TABLE判为DANGER，无迁移改动判为SAFE
• LLM返回的precheckSql只含SELECT语句且通知中附GitHub compare链接
• 通知成功送达所选渠道且包含判定等级、摘要与镜像名

容易卡住的地方

• WUD必须已部署且n8n网络可达，模板不含WUD本身
• 不配置GitHub token时拉release与compare易撞匿名限流，表现为UNKNOWN增多
• 原文支持Ollama或OpenAI兼容端点但未指定模型名，不要照抄别处模型名硬填
• 规则分类只是初筛，LLM也可能误判，DANGER/CAUTION升级仍应人工确认后执行
• 定时为每天06:30（模板时区），改时区后记得同步核对