Vibe DevOps实践: 使用Codex升级Immich

19 Dec 2025

这次迁移+升级 Immich，我把 Codex 当成远程运维搭档：让它帮我拆步骤、校验、排障、补齐风险点。最终跑通后，我把这套方法提炼成一套能复用的运维思路：Vibe DevOps，适用于任何自托管服务的迁移与升级。

已对域名、IP、口令、Token 等敏感信息脱敏；路径/变量请按你环境替换。

1) 这次要解决什么

• 旧 NAS → 新 NAS 的完整迁移
• 跨大版本升级（存在官方 upgrade path）
• 尽量缩短停机窗口
• 最终可运维（自启/自愈/可回滚）

2) 实战案例：Immich 迁移 + 升级（Codex 介入点）

这次我按“先恢复可用、再补齐”的思路推进，并让 Codex 在关键节点介入：

2.1 资产盘点（Codex 先输出风险清单）

• 版本信息与官方升级路径（跨大版本不可直升）
• 数据位置（媒体/数据库/配置/缓存）
• 反代、证书、DNS、端口依赖

2.2 迁移策略（Codex 给出“可回滚”步骤）

• 媒体库先预同步，避免切换窗口被拖慢
• 数据库先 dump 兜底（永远优先）
• 过桥版本启动一次完成 schema 迁移

2.3 Immich 关键升级路径（真实踩点）

• 旧版本 → 过桥版本（成功启动一次）
• 过桥版本 → 目标版本（完成大版本升级）
• 实例：v1.131.x → v1.132.3 → v2.3.1

这一步最容易翻车，Codex 帮我在升级前就锁定了“必须过桥”的规则。

2.4 迁移执行要点（可复用）

• 预同步时避免 --delete，缩短停机
• 切换后只补不删，避免阻塞服务恢复
• 验证点固定：健康状态 / 版本信息 / 日志异常

2.5 运维固化（让“迁移”变成“长期可维护”）

• systemd 开机自启
• 容器 restart: always
• 健康检查与自动重启

3) Vibe DevOps：把运维变成“可验证节奏”

我把这次经验总结成一套节奏化的操作方式：

• 拆小步：每一步都能回滚或重复执行
• 先校验：每一步都有明确验证命令与指标
• 先恢复可用：先上线再补齐，避免长时间停机
• 先固化流程：最终产出 SOP，降低下次成本
• 持续对话：Codex 提供“提示/验证/排障”循环

这套方法不仅适用于 Immich，也适用于你维护的任何服务。

4) Codex 的具体用法（可直接复用）

• 先让它给风险清单（升级路径、回滚点、依赖项）
• 每一步要验证命令（健康检查、版本、日志）
• 遇到错误先定位（网络/权限/版本/数据）
• 最终产出 SOP（下次直接复用）

5) 结论

这次迁移/升级最大的收获不是 Immich 本身，而是：

• 用 Codex 把复杂运维拆成了“可验证流水线”
• 形成了一套可迁移到任何服务的操作模板（Vibe DevOps）

如果你也要迁移/升级任何自托管服务，建议按同样的节奏：

1) 先盘点 2) 先备份 3) 先预同步 4) 走升级链路 5) 再切换验证 6) 最后运营化

这套流程 + Codex，基本可以把“高风险”变成“可控”。