一次非常典型、运维化的基础设施重构

我有一台服务器，名叫：

jp-iij

因为距离最近，于是用作了跳板机。

我在上面跑了几个项目：

/opt/status-web
/opt/traffic-web
/opt/traceroute-web

这些项目都需要从 jp-iij 这台机器，去免密登录其他的好多台服务器。

于是我就给每一个项目的文件夹里，都放了一个 hosts.txt

今天，我花了一些时间，把 hosts.txt 唯一化了。

表面上看，只是改了几个 hosts.txt。

但本质上，这已经从管理几台 VPS 逐渐进入管理小型基础设施的阶段。

一、建立唯一真源

真正的问题，并不是 hosts.txt 放在哪里。

而是，谁才是真正有效的 hosts.txt

于是，我建立了唯一真源(Single Source of Truth)

/opt/cluster/hosts.txt

并把它定义为：全局唯一有效的 hosts 配置。

从这一刻开始：

新增机器
删除机器
更换 IP

都只需要改一次 hosts.txt

二、为什么放在 /opt/cluster

我把它放在了：

/opt/cluster/

这个目录。

因为 /opt，通常用于放置自定义的系统级应用和基础设施组件。

而 cluster 这个名字，代表：

集群
基础设施
配置中心
运维控制

而不是某个单独项目。

于是 /opt/cluster 变成了整个 VPS 集群的配置中心。

三、从多副本，到软链接

于我先采用了一个过渡方案：软链接（symlink）

例如：

/opt/status-web/hosts.txt
    ↓
/opt/cluster/hosts.txt

这样：

老代码不用改
项目还能继续运行
但实际上已经开始共享同一个配置文件

这是非常典型的兼容式重构思路。

而不是一次性全部推翻重写的高风险方式。

四、最终：代码直接引用中央配置

随后，我开始逐个项目重构。

例如，原本代码里是：

HOSTS_FILE="hosts.txt"

现在改为：

HOSTS_FILE="/opt/cluster/hosts.txt"

从此开始：

项目不再维护自己的 hosts
项目不再依赖软链接
项目开始“依赖基础设施配置”

这一步的意义非常大。

因为配置开始脱离项目本身。

项目本身，只负责应用逻辑。

而基础设施配置，则由统一配置中心管理。

这已经非常接近现代运维 / DevOps里的核心思想。

五、为什么还需要多地备份

紧接着，我又想到一个问题：

如果只有一个 hosts.txt，会不会丢？

这就开始进入容灾（Disaster Recovery）思维了。

于是，我没有重新回到多个活跃副本，

而是一个真源 + 多地同步备份。

也就是，真正编辑的：

/opt/cluster/hosts.txt

自动广播到其它 VPS：

/opt/cluster/hosts.txt

但只有 jp-iij 是主真源。

其它机器：

只是同步副本
不作为编辑入口
不作为配置来源

六、sync-hosts.sh：我的第一个配置分发系统

最后，我写出了：

/opt/cluster/scripts/sync-hosts.sh

它会：

遍历 hosts.txt
自动 SSH 登录
自动创建目录
自动 SCP 分发

本质上，它是一个极简配置分发系统。

虽然只有十几行 Bash。

但它已经具备：

中央配置
多节点广播
自动同步
分布式备份

这些真正运维系统里的核心思想。

七、我现在真正拥有的东西

现在，我的结构已经变成：

/opt/cluster
├── hosts.txt
├── files/
├── scripts/sync-hosts.sh
└── backup/

现在，我已经拥有：

Tailscale 内网
SSH 免密
跳板机
集群节点
配置中心
配置广播
多地备份
基础设施标准化

这些东西组合起来，已经非常接近真正的小型 SRE / 运维体系了。