AI开发配置系统（一）：告别手动Lucky配置：我为什么要自己造一个ConfigBridge
我是舸扬。记录 AI 探索日记与生活思考。在速成时代，坚持每篇文章都是一次深潜。行者开路，不随前尘。
当你有 10 个 Web 服务分布在 3 台服务器上，每个服务都需要 4 份不同的配置文件时，你还能忍受手动复制粘贴吗？这篇文章介绍我开发的项目 ConfigBridge——一个专治"多服务 × 多服务器"配置噩梦的管理系统。
TL;DR（太长不看版）
- 我的烦恼：十几个自建服务，分布在多台服务器上，每新增一个服务就要手动写 4 份配置文件
- 痛点一句话：配置文件太多、太分散、改一次要登录好几台机器
- 我造了个工具：ConfigBridge——只需填写「服务名 + 子域名 + 端口」，一键生成所有配置
- 效果：从 30 分钟重复劳动 → 3 秒钟一键搞定
我是谁，我在折腾什么
我是舸扬，一个 Homelab 玩家，我的"实验室"里跑着十几个自建服务：博客、笔记系统、密码管理器、RSS 阅读器、监控面板、媒体中心、个人网盘……
但我的服务器环境有点特殊：主力机只有 IPv6 公网地址。
在 2026 年，虽然 IPv6 普及率持续提升，但仍有大量用户的网络环境只支持 IPv4。还有的商业服务器（不想点名）开通 ipv6 的流量还要付额外费用，虽然不太贵，但是吃相实在不太好看。这意味着，如果我只部署在 IPv6 服务器上，相当一部分用户根本无法访问。
我的解决方案是经典的 FRP 穿透（FRP 是一种内网穿透工具，可以理解为「网络传话人」——当用户无法直接访问你的服务器时，FRP 帮你中转请求）：
- 服务器 A（IPv6 公网）：服务实际运行的地方
- 服务器 B（IPv4 公网）：FRP 中转站，专门帮 IPv4 用户「传话」
用户访问时：
- 支持 IPv6 → DNS 解析到 A → 直连（延迟最低）
- 不支持 IPv6 → DNS 解析到 B → FRP 帮忙转发到 A → 照样能访问
理论完美，但实际操作时，我陷入了配置地狱。
老朋友 Lucky：好用，但不够用
在开始自己造轮子之前，我用的是 Lucky——一款国产的反向代理工具。
/// Lucky UI ///
Lucky 的优点
- 上手快：图形界面，点点鼠标就能配置
- 功能全：反向代理、HTTPS 证书、DDNS（动态域名解析，让域名自动跟着 IP 变）一站式搞定
- 单机友好：如果你只有一台服务器，Lucky 真的很香
但，当我的服务越来越多时，问题来了
痛点 1：没有"模板"概念
每次新增服务，我都要从头填写：域名、端口、后端地址、SSL 配置……即使 90% 的配置都是重复的。
痛点 2：多机器？不存在的
Lucky 是单机工具。我的服务器 A 和服务器 B 各需要独立配置，没有任何联动。如果有多域名，也要分别配置。（注意看我这个图里的配置，每个服务我都手动配了两次，连复制功能都没有）
这意味着，新增一个服务我需要：
- 登录服务器 A，在 Lucky 里配置反向代理
- 登录服务器 A，手写 FRP 客户端配置
- 登录服务器 B，在 Lucky 里配置反向代理
- 登录服务器 B，修改 FRP 服务端配置
4 份配置，分布在 2 台机器上，每份都要手动写。
痛点 3：配置散落各处，无法集中管理
想看看现在部署了哪些服务？登上每台机器，打开 Lucky 后台，或者去 /etc/nginx/sites-available/ 里翻一翻。
想改个全局配置（比如换域名）？挨个机器挨个服务改。
我有 10 个服务，分布在 3 台服务器上。这是 30+ 次重复操作。
一个疯狂的想法：自己造一个
某天凌晨，我又新部署了一个服务，想着又要配置一大堆反向代理，脑子里冒出一个念头：
💡 如果有个工具，能让我只输入 服务名 + 子域名 + 端口，就自动生成所有需要的配置文件，该多好啊！
我想要的是：
- 模板化：写一次模板，复用 N 次
- 变量化：不同服务器用不同的变量值，但共享同一套模板
- 中心化：在一个地方管理所有服务和配置
于是，ConfigBridge 诞生了。
ConfigBridge 是什么？
ConfigBridge 是一个 Web 服务配置管理系统，专治"多服务 × 多服务器"配置噩梦。
/// ConfigBridge 管理界面 ///
核心理念
模板化 + 变量化 + 中心化- 模板化：用 Jinja2 语法（一种模板语言，用
{{ 变量名 }}的方式占位）定义配置模板，一套模板适配多种场景 - 变量化：通过变量系统，同一个模板在不同服务器上生成不同的配置
- 中心化：所有服务、服务器、模板、变量都在一个 Web 界面集中管理
产品定位
| 适合场景 | 不适合场景 |
|---|---|
| 多台服务器需要统一配置管理 | 只有一台服务器、几个服务 |
| 服务数量 10+ | 手动配置就能搞定的简单场景 |
| 需要 Nginx + FRP 等多种配置联动 | 只需要简单的反向代理 |
| 追求配置可复用、可追溯 | 不在意配置管理的临时项目 |
模块功能详解
好，接下来我带你逐一看看 ConfigBridge 的核心模块。如果你只想快速了解整体效果，可以先跳到后面的「我的典型使用场景」那一节，看完再回来细读也不迟。
1. 服务管理
功能：定义你的 Web 服务，设置基本信息，关联到目标服务器。
核心字段：
- 服务名称（如
nextcloud） - 子域名（如
cloud，最终拼接成cloud.example.com） - 端口（服务实际监听的端口，如
8080） - 关联服务器（这个服务要部署到哪些机器）
/// configbridge 服务详情 ///
每个服务只需要填这 4 个字段，剩下的交给模板和变量系统。
2. 服务器管理
功能：定义你的服务器，设置连接信息和环境特征。
核心字段：
- 服务器名称（如
server-a） - IP 地址 / 主机名
- SSH 凭证（SSH 是远程登录协议，让你用命令行连接服务器；这里填登录信息，用于后面的远程部署功能）
/// configbridge 服务器详情 ///
我这里在本地ssh设置里配置了免密登录，设置了别名，推荐这样设置，保证关键信息的安全。
3. 配置模板管理
功能：用 Jinja2 模板语法定义配置模板，一套模板适配多种场景。（前面提过，Jinja2 就是用 {{ 变量 }} 占位，生成时自动替换成真实值。）
模板类型：
- Nginx 反向代理模板
- FRP 客户端模板
- FRP 服务端模板
- 任何你需要的配置文件模板
我的 Nginx 模板示例：
/// configbridge nginx 模板详情 ///
4. 变量系统（四层优先级）
这是 ConfigBridge 最核心的设计——四层变量优先级系统。
为什么需要它？
问题：同一个服务，在不同服务器上的配置可能有细微差别。
比如：
- 在 server-a 上，
backend_port = 8080（服务实际端口） - 在 server-b 上，
backend_port = 8081（FRP 转发端口，不是原始端口！）
如果为每个场景单独写模板，模板数量会爆炸。
解决方案：四层变量覆盖
| 优先级 | 变量层级 | 查找逻辑示例（以 backend_port 为例） | 最终取值 |
|---|---|---|---|
| 1 (最高) | 服务-服务器变量 | nextcloud 在 server-b 上的特定配置：8081 | 8081 |
| 2 | 服务器变量 | server-b 上所有服务的默认值：(未定义) | - |
| 3 | 服务变量 | nextcloud 在所有服务器上的默认基准值：8080 | - |
| 4 (最低) | 全局变量 | 整个平台的默认兜底值：(未定义) | - |
/// 变量管理界面 ///
我的变量配置：
| 层级 | 变量 | 值 | 说明 |
|---|---|---|---|
| 全局 | base_domain | example.com | 所有服务共用的根域名 |
| 服务器 (server-a) | ssl_key_path | /root/cert | SSL 证书路径 |
| 服务器 (server-b) | frp_token | xxx | FRP 认证 token |
| 服务 (nextcloud) | is_webdav_config | true | 是否启用 WebDAV相关配置 |
| 服务-服务器 (nextcloud @ server-b) | backend_port | 8081 | 在 B 上用 FRP 转发端口 |
5. 一键生成
功能：点击按钮，自动为所有关联的服务器生成配置文件。
生成过程：
- 读取服务的基本信息（名称、子域名、端口）
- 获取该服务关联的所有服务器
- 对于每个服务器：
- 查找适用的配置模板
- 按四层优先级合并变量
- 渲染模板，生成最终配置
- 保存到本地目录
生成结果（以 nextcloud 为例）：
storage/
├── server-a/
│ ├── nginx/
│ │ └── nextcloud.conf ← IPv6 版 Nginx，listen [::]:80
│ └── frp/
│ └── nextcloud.toml ← FRP 客户端，localPort=8080
└── server-b/
└── nginx/
└── nextcloud.conf ← IPv4 版 Nginx，proxy_pass 端口=8081从 4 份手动配置，到 1 次点击自动生成，这就是 ConfigBridge 的价值。
我的典型使用场景
让我用一个完整的例子展示 ConfigBridge 如何工作。
场景
- 服务器 A：IPv6 公网，实际运行服务
- 服务器 B：IPv4 公网，FRP 中转
- 目标：部署 Nextcloud，让 IPv4 和 IPv6 用户都能通过
cloud.example.com访问
配置前（手动方式）
- 在 server-a 上写 Nginx 配置（IPv6 监听）
- 在 server-a 上写 FRP 客户端配置
- 在 server-b 上写 Nginx 配置（注意 proxy_pass 端口要改成 FRP 转发端口！）
- 在 server-b 上改 FRP 服务端配置
4 份配置，2 台机器，无数次 SSH。
配置后（ConfigBridge 方式）
- 在 ConfigBridge 中创建服务
nextcloud，填写：子域名cloud，端口8080 - 关联 server-a 和 server-b
- 选取每个服务器分别配置好的固定模板（我默认Frp端口和原端口一致）
- 点击 "生成配置"
3 秒钟，4 份配置全部生成，放在本地目录里等你取用。
更多功能
除了上述核心模块，ConfigBridge 还提供了一系列实用功能，让配置管理更加高效。
6. 远程部署
功能：通过 SSH 将配置文件自动推送到目标服务器，告别手动 SCP（SCP 是命令行传文件的工具，每次都要敲一长串命令，很烦）。
工作流程：
- 生成配置文件后，点击 "部署" 按钮
- 系统通过 SSH 连接到目标服务器
- 自动备份原配置文件到指定目录（防止误操作）
- 将新配置文件写入目标路径
- 可选执行重载命令（如
nginx -s reload。但我不一般不用自动重载，我一般会手动nginx -t检查一下，以防万一语法错误生成失败惹了大麻烦，别问我怎么知道的）
部署前再也不用担心"改错了回不去"——原配置文件自动备份，一键回滚。
7. 配置版本控制
功能：记录每次配置模板的变更历史，支持查看差异和一键回滚。
实际场景：
某天你改了 Nginx 模板，加了一行配置，结果服务挂了。
没有版本控制？只能靠记忆恢复，或者祈祷备份还在。
有 ConfigBridge？打开模板历史，看到所有版本，一键回滚到上一个稳定版。
版本信息包含：
- 修改时间
- 修改说明（可选填写）
- 完整模板内容
- 与上一版的差异对比
8. 批量操作
功能：一键为所有服务重新生成配置文件。
典型场景：
- 修改了模板，需要让所有使用该模板的服务同步更新
- 修改了全局变量（如
base_domain），需要重新生成所有配置 - 新增了一台服务器，需要为所有服务生成该服务器的配置
一键操作，批量搞定，再也不用一个一个服务点进去。
/// 配置批量生成部署 ///
/// 配置批量生成部署 ///
结语：从手动到自动，配置管理的效率革命
回顾这个项目的初衷：
我只是想让"新增一个服务"这件事，从 30 分钟的重复劳动，变成 3 秒钟的一键操作。
ConfigBridge 做到了。
而这套系统的诞生，离不开 AI 的辅助——我将在后续文章中详细讲述。
📚 AI开发配置系统系列导航
这是本系列的第一篇。
下一篇：AI开发配置系统（二）：我与AI的72小时：从零打造ConfigBridge
如果你也有"多服务 × 多服务器"的配置管理痛点，ConfigBridge 可能正是你需要的工具。
📌 项目信息
| 项目 | 详情 |
|---|---|
| 项目名称 | ConfigBridge 配置管理系统 |
| 解决问题 | 多服务 × 多服务器的配置集中管理 |
| 典型场景 | IPv6/IPv4 混合环境、FRP 穿透、Nginx 反向代理 |
| 技术栈 | FastAPI + Vue 3 + SQLAlchemy + Jinja2 |
🎯 如果这篇文章对你有帮助，欢迎点赞、收藏、转发！有任何问题或建议，欢迎在评论区交流。