甲骨文1次镜像更新，让工程师把自己锁在门外4小时

47%的Homelab玩家会在第一年遭遇"自我锁死"——这个数字来自Reddit r/selfhosted的年度调查，但大多数人不会公开谈论它。不是因为尴尬，而是因为解释清楚需要画一张依赖关系图，而那张图看起来像个笑话。

今天这个故事的主角，是一位把"自托管一切"执行到极致的工程师。他的K3s集群跑在甲骨文云的免费VM上，用Terraform管理，Ansible配置，ArgoCD做GitOps，Forgejo托管代码，Keycloak管身份，Headscale做VPN。一套标准的云原生自托管方案，优雅、现代、完全开源。

问题只有一个：这套系统的"根"在哪里？

答案是没有根。Forgejo的代码库托管着ArgoCD的配置，ArgoCD部署着Forgejo；Keycloak给Forgejo做身份验证，但Keycloak的主题文件又存在Forgejo里。Headscale让kubectl能连进K3s，但Headscale本身也是ArgoCD部署的。

用作者自己的话说：「这是乌龟驮着乌龟往下掉，而且每只乌龟还得负责照顾其他乌龟。」

甲骨文的一次常规更新，成了第一张倒下的多米诺

2024年某天，Oracle发布了新的Ubuntu Minimal镜像。作者的Terraform配置里，镜像源指向的是latest标签——一个常见但危险的做法。terraform apply执行时，检测到镜像变化，平静地销毁了旧VM，创建了新的。

没有告警。没有确认提示。就是一个常规的周五下午，一切突然归零。

新VM启动后，cloud-init按剧本跑完了：重装K3s，拉起一个空白的ArgoCD。然后停住了。因为下一步需要Ansible playbook来配置ArgoCD，让它知道去哪里拉应用配置——而那个配置指向的是Forgejo，Forgejo还没部署，因为它等着ArgoCD来部署它。

更糟的是：Ansible playbook确实活着，作者把它放在了OCI对象存储里。但kubectl进不去K3s——Headscale还没跑起来，而Headscale是ArgoCD负责部署的。远程访问的钥匙，锁在需要钥匙才能打开的房间里。

作者后来回忆：「我有一台运行中的K3s节点，和一个空白的大脑。」

四小时的"注释-部署-取消注释"地狱

修复过程没有优雅可言。作者被迫修改Ansible playbook，让ArgoCD临时指向GitHub而不是Forgejo——这意味着把私有配置公开到第三方平台，违背了自托管的初衷。

但这只是开始。每修复一个服务，就暴露一个新的循环依赖：

ArgoCD需要Forgejo → 先注释掉Forgejo配置，部署基础服务 → Forgejo需要Keycloak做OIDC → 注释掉OIDC，让Forgejo裸跑 → Keycloak需要Forgejo托管主题文件 → 手动把主题塞进去，或者暂时用默认主题 → 恢复OIDC配置，发现Headscale的ACL规则引用了还没创建的Keycloak组...

「大部分是注释掉配置、部署、取消注释、重新部署，」作者写道，「每次提交都是一次猜谜：这次会炸掉什么？」

四小时后的稳定状态，被作者用一条注释标记下来：「趁这玩意儿还没再炸，赶紧拆了它。」

GitOps的致命假设：总得有个"外面"

这个故事的核心矛盾，是GitOps模式的一个隐性前提：Git仓库必须在集群"外面"。不是物理位置的外面，而是管理边界的外面——一个即使集群全毁、也能独立访问的权威源。

但当你的Git仓库（Forgejo）和被Git管理的集群是同一个东西时，这个前提就崩塌了。你得到了自洽，但失去了容灾能力。像一个人把自己的备用钥匙锁在了需要备用钥匙才能打开的房子里。

作者提出的解决方案很朴素：自引用系统必须有一个逃生舱口。

具体到他后来的架构：独立的/data挂载，容器化部署，一个叫做"steward"的轻量级初始化工具——能在两分钟内把裸VM拉到一个"足够可用"的状态，不需要依赖集群本身的服务。Git仓库的权威副本放在外部（哪怕是另一个云厂商的对象存储），集群内的Forgejo只是镜像。

这些都不是新技术。K3s的嵌入式etcd备份、Velero的灾难恢复、甚至最原始的rsync到另一台机器，都是同一个思路的变体。但知道和做到之间，往往隔着一次4小时的锁死体验。

作者在文章结尾给自己留的便签，或许值得所有自托管玩家抄下来：「优雅是运行时的奢侈品，逃生舱口才是基础设施的刚需。」

你现在检查自己的Homelab，能指出那个"如果一切都炸了，我从哪开始恢复"的起点吗？还是说，你的乌龟 stack 也在互相驮着往下掉？