拒绝手动SSH：用战斗机与AI混沌构建的硬核Homelab架构

揭秘Night-Tower：从3节点Proxmox集群到1Password内存级密钥管理的全自动化基础设施

小伙伴们，大多数普通用户买一台单盘位 Synology NAS，插在路由器上，把家庭照片拷过去，这一天就算圆满结束了。但 Homelab 玩家不一样。我们看着家里的单间公寓网络，脑子里想的却是：这地方真正需要的，是一个三节点高可用裸机 Proxmox 虚拟机管理程序集群、企业级 OPNsense 防火墙、自动化 GitOps CI/CD 流水线、本地 AI 大语言模型编排，以及由 1Password 保险库保护的 Ansible Playbook。这就是 Night-Tower------一个企业级架构与极度过度工程化相遇的 Homelab。

瑞典战斗机集群：硬件基础设施

Night-Tower 计算帝国的核心是一个名为 squad 的 3 节点 Proxmox VE 8.x 裸机集群。因为像 node-01 或 server-alpha 这种标准主机命名规则实在太无聊了，该集群完全以瑞典冷战时期的传奇战斗机命名：

• lansen (节点 01)：以 Saab 32 Lansen 命名。作为主虚拟机管理程序，处理核心 Docker 计算工作负载。
• draken (节点 02)：以标志性的双三角翼 Saab 35 Draken 命名。专用于本地 AI 模型推理的主机。
• viggen (节点 03)：以三角翼 Saab 37 Viggen 命名。负责编排自动化工作流和冗余 VM 计算。

图片说明：Swedish Fighter Jets in a Proxmox Server Rack

关于主机命名的一个专业建议：用超音速战斗机命名 Proxmox 节点，能让虚拟机实时迁移速度至少提升 15%（当然，这是我瞎编的统计数字）。在这个超音速 Proxmox 三重奏旁边，还坐着一台 synology-nas，它为媒体备份、持久化容器卷和数据归档提供高吞吐量的 NFS 和 SMB 存储后端支持。

网络拓扑与入口安全

在 Night-Tower，你不会"连上 Wi-Fi 就完事了"。流量在接触到任何容器之前，必须穿过多重安全防线：

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'darkMode': true,
    'background': '#0b0f19',
    'primaryColor': '#1e293b',
    'primaryTextColor': '#f8fafc',
    'primaryBorderColor': '#38bdf8',
    'lineColor': '#c084fc',
    'secondaryColor': '#0f766e',
    'secondaryTextColor': '#ffffff',
    'tertiaryColor': '#831843',
    'clusterBkg': '#0f172a',
    'clusterBorder': '#334155',
    'titleColor': '#38bdf8',
    'edgeLabelBackground': '#0f172a',
    'fontFamily': 'inter, system-ui, sans-serif'
  }
}}%%
flowchart LR
    classDef edgeStyle fill:#1e293b,stroke:#0ea5e9,stroke-width:2px,color:#fff;
    classDef coreStyle fill:#0f172a,stroke:#8b5cf6,stroke-width:2px,color:#fff;
    classDef aiStyle fill:#18181b,stroke:#ec4899,stroke-width:2px,color:#fff;
    classDef storageStyle fill:#18181b,stroke:#f59e0b,stroke-width:2px,color:#fff;

    subgraph Edge ["🌐 Edge & Remote Ingress"]
        Users["👤 External User"]
        Cloudflare["☁️ Cloudflare WAF & Tunnels"]
        Tailscale["🔒 Tailscale Mesh VPN"]
    end

    subgraph Perimeter ["🛡️ Network Security"]
        OPNsense["🔥 OPNsense Firewall"]
        Technitium["🌐 Technitium DNS"]
    end

    subgraph Cluster ["🏰 Night-Tower Proxmox Compute Engine"]
        
        subgraph DockerVM ["🐳 docker (VM 100)"]
            Traefik["🚥 Traefik v3.6 Proxy"]
            Gitea["🐙 Gitea & Actions Runner"]
            Homepage["📊 Homepage & Uptime Kuma"]
        end

        subgraph AutomationVM ["⚙️ n8n (VM 101)"]
            n8n["⚡ n8n Workflow Engine"]
            Patchmon["🛡️ Patchmon & MCP Jungle"]
        end

        subgraph AILXC ["🦙 ollama (LXC)"]
            Ollama["🧠 Ollama LLM Engine"]
        end

        subgraph NAS ["📦 Synology NAS"]
            Storage[("💾 NFS / SMB Storage")]
        end
    end

    Users --> Cloudflare
    Users --> Tailscale
    Cloudflare -->|Cloudflare Tunnel| Traefik
    Tailscale --> OPNsense
    OPNsense --> Technitium
    
    Traefik --> Homepage
    Traefik --> Gitea
    Traefik --> n8n
    
    n8n --> Ollama
    n8n --> Patchmon
    DockerVM --> Storage
    
    class Cloudflare,Tailscale,Users edgeStyle;
    class OPNsense,Technitium,Traefik,Gitea,Homepage coreStyle;
    class n8n,Ollama,Patchmon aiStyle;
    class Storage storageStyle;

入口与解析高光配置如下：

• 网关与防火墙：由 OPNsense 负责管理本地子网和严格的防火墙策略逻辑。
• 本地 DNS 解析：Technitium DNS 作为内部域 night-tower.local 的权威本地 DNS 服务器。
• 边缘反向代理：Traefik v3.6 搭载自动化 Cloudflare DNS-01 ACME 通配符 SSL 证书生成功能（*.night-tower.net）。
• 远程访问：通过加密的 Tailscale Mesh VPN 结合 Cloudflare Tunnels 实现。

这种多重代理与隧道结合的架构，确保了无论是内部服务寻址还是外部流量接入，都处于严格的加密与策略控制之下。Technitium DNS 负责斩断内部的域名解析乱麻，而 Traefik v3.6 则在边缘统一处理 TLS 终结和路径路由。

容器生态与工作负载分布

跨客户机计算节点的工作负载划分经过精心设计，旨在实现最大可靠性和最小杂乱。计算主机分解如下：

• docker 虚拟机 (VMID 100)：运行 Traefik v3.6、Gitea Git Server & Runner、Technitium DNS、Homepage、Uptime Kuma、Grafana/Prometheus (monitor)、Checkmk、Hermes Agent 和 Cloudflared。
• n8n 虚拟机 (VMID 101)：运行 n8n AI Workflow Engine、Patchmon 安全补丁跟踪和 MCP Jungle。
• ollama LXC (容器)：使用 Systemd 管理的 ollama.service 提供本地大语言模型 qwen2.5 和 llama3.2。

这套核心服务套件各司其职。Traefik v3.6 承担反向代理、TLS 终结和路径路由的重任；Technitium DNS 提供带有广告拦截和自定义区域的本地 DNS 服务；Gitea 及其 Runner 构成了自托管的代码仓库与 CI/CD 流水线引擎；Uptime Kuma 负责 Ping 监控，在服务眨眼间出问题时发送警报；n8n 引擎作为可视化自动化节点编辑器执行代理工作流；Ollama AI 则在本地运行 Qwen2.5 和 Llama3.2 模型。

需要特别发出警告的是：Uptime Kuma 被配置为每 30 秒检查一次服务健康状况。如果服务中断超过 3 秒，就会立即发送 Discord 通知，这样我就可以戏剧性地假装正在修复一次严重的中断事故。

AI 与自动化控制室

Night-Tower 绝不仅仅是静态基础设施------它拥有自己的"大脑"。

通过将 n8n 与本地 Ollama 大语言模型（qwen2.5、llama3.2）配对，结合 MCP Jungle（模型上下文协议桥接器）和 Hermes Agent，这个 Homelab 能够执行自主任务、处理 webhooks 并执行自动化代码审查。

图片说明：n8n Workflow Automation Canvas

这种设计将本地推理能力与工作流引擎深度绑定。n8n 不再仅仅是一个触发器和 API 调用器的集合，它通过 MCP Jungle 获得了与本地模型上下文交互的能力。Hermes Agent 则在其中扮演调度与执行的角色。当 Webhook 被触发时，工作流可以将上下文传递给 Ollama 运行的 Qwen2.5 或 Llama3.2，让模型理解意图并生成代码审查意见或执行特定的自动化操作。

图片说明：AI Automation Chaos Control Center

这不再是简单的脚本化运维，而是让基础设施具备了一定程度的自主决策能力。从处理外部事件到生成审查反馈，整个闭环完全在本地完成，不依赖外部商业 API，既保证了数据隐私，又实现了高度定制化的混沌控制。

GitOps 流水线与密钥管理

在 Night-Tower 中，绝对不允许手动 SSH 登录或手工编辑配置文件。一切均通过使用 Ansible 和 Gitea Actions 的基础设施即代码进行管理。

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'darkMode': true,
    'background': '#0b0f19',
    'primaryColor': '#1e293b',
    'primaryTextColor': '#f8fafc',
    'primaryBorderColor': '#a855f7',
    'lineColor': '#38bdf8',
    'actorBkg': '#1e1b4b',
    'actorBorder': '#6366f1',
    'actorTextColor': '#e0e7ff',
    'actorLineColor': '#818cf8',
    'signalColor': '#38bdf8',
    'signalTextColor': '#f8fafc',
    'labelBoxBkgColor': '#0f172a',
    'labelBoxBorderColor': '#334155',
    'labelTextColor': '#38bdf8',
    'fontFamily': 'inter, system-ui, sans-serif'
  }
}}%%
sequenceDiagram
    autonumber
    actor Admin as 👨‍💻 Homelab Admin
    participant Git as 🐙 Gitea Repo (night-tower/homelab)
    participant Runner as ⚙️ Gitea Actions Runner
    participant Vault as 🔐 1Password Vault
    participant Hosts as 🏰 Proxmox & Compute Hosts
    participant Discord as 💬 Discord (#night-tower)

    Admin->>Git: git push origin main
    Git->>Runner: Trigger GitOps Workflow (.gitea/workflows/gitops.yml)
    Runner->>Runner: Run ansible-lint & syntax checks
    Runner->>Vault: Resolve op://"Vault"/... Secrets
    Vault-->>Runner: Return ephemeral, in-memory tokens
    Runner->>Hosts: Execute ansible-playbook site.yml -i inventory.yaml
    Hosts-->>Runner: Playbook Success (0 failures)
    Runner->>Discord: Push Health Status Report

GitOps 执行原则极为严格，分为以下几个核心环节：

1. Pull Request 验证：每个 PR 会自动运行 ansible-lint、playbook 语法验证和 dry-run 执行检查（--check）。这确保了任何合并到主分支的变更在语法和预期执行状态上都经过严格校验。
2. 零硬编码密钥：密钥在运行时通过 op:// 引用字符串从 1Password 获取，绝不接触磁盘或 git 历史记录。这意味着代码仓库中不存在任何明文形式的敏感信息。
3. 定向部署：Playbook 通过 --limit 参数针对特定主机组进行部署（如 --limit docker_vms、--limit hypervisors、--limit ai_hosts），以最小化影响范围。如果某个变更只影响 AI 推理主机，绝不会把整个集群置于风险之中。
4. 自动化健康广播：部署后的报告会通过自动化脚本格式化，并直接推送到 #night-tower Discord 频道。

图片说明：Discord Automated Infrastructure Health Report

最核心的安全保障是 1Password 内存规则：所有 API 令牌、SSH 密钥和数据库凭据都在 playbook 执行期间在内存中解析。如果有人偷了我的服务器硬件，他们只会得到一个干净的 Debian 安装，以及零个明文密码。

这种级别的密钥管理意味着基础设施的运行态与存储态实现了物理级别的隔离。Ansible 在执行时动态向 1Password 请求凭据，注入内存完成配置后，不留痕迹。这不仅是防止凭据泄露的最佳实践，更是将信任边界缩小到了运行时的极小范围。

为什么要构建 Night-Tower？

我能在单个树莓派上跑几个服务吗？当然可以。但那能给我借口去部署一个三节点战斗机主题的 Proxmox 集群、编写自定义 eBPF 内核监控器、编排本地 AI 大语言模型，并构建自动化 GitOps CI/CD 流水线吗？绝对不能。

Homelab 的意义不在于用最简单的方式做事，而在于因为你能够，所以在你的壁橱里建一个微型企业数据中心。Night-Tower 证明了，当过度工程化与企业级严谨结合时，诞生的是一套完全自洽、高度自动化且极具个人色彩的架构体系。从战斗机命名的节点，到内存级别的密钥安全，再到自主执行的 AI 工作流，每一个环节都在诠释什么叫做真正的硬核玩家。