MiBeeHive：我给自己工作室造的「蜂巢」工具箱

做运维出身，后来转开发，维护的项目越来越多。各种中间件、数据库、监控组件……每次升级版本都是一场体力活：去官网找下载链接、比对版本号、手动下载到内网、再分发到各台机器。以前写了一堆 Shell 脚本定期拉取最新版本到局域网，能用但不好用——脚本散落在各处，加新软件得手写解析逻辑，出错了也没什么日志可查。

后来工作室的机器越来越多，装系统也成了问题。几十台 ARM64 小主机，一台台插 U 盘装？还是算了。加上日常打包的容器镜像管理，各种 Registry 来回同步……

索性用 Go 重写一套，把版本管理、无人值守装系统、容器管理全部做到一个工具里。这就是 MiBeeHive。

为什么做 MiBeeHive

说白了就是被逼出来的。我工作室的日常运维大概有这么几个痛点：

版本更新太麻烦。Prometheus 出新版了，VictoriaMetrics 出新版了，Grafana 出新版了……一堆组件都得跟上。以前用 Shell 脚本 + cron 定时从 GitHub API 抓 release，但每个软件源的解析逻辑都不一样，维护起来头大。而且脚本一旦出问题，你可能好几天都不知道新版本没拉下来。

装系统太低效。ARM64 设备不像 x86 有现成的 Cobbler/MAAS 方案，轻量级的 PXE 服务基本找不到。每次新来一批设备，不是手装就是写 SD 卡，效率极低。

容器镜像管理太分散。自己的项目打包成镜像后，推到 Docker Hub 又慢又不稳定（国内网络你懂的），想在内网搞个 Registry 做缓存和分发，但管理界面又是个问题。

文件共享太原始。内网传文件要么用 scp，要么搭个 NFS/Samba，配置复杂而且没有 Web 界面。就想简单地通过浏览器上传下载个文件。

找了一圈现成方案：Gitea Release 只管自己的仓库；Nexus/Artifactory 太重了，Java 系的，吃内存；各种 PXE 方案都是 x86 为主的；轻量 WebDAV 服务器倒是有几个，但功能太单一。

我的需求其实很简单：

• 一个二进制文件，下载就能跑
• ARM64 优先，资源占用要少（我的 NAS 只有 469MB 内存）
• Web 界面管理，不用 SSH 上去改配置
• 把版本管理、装系统、容器、文件共享都搞定

没有现成的，那就自己造。

MiBeeHive 是什么

MiBeeHive 是一个用 Go 写的轻量级工作室文件工具平台，名字来源于「蜂巢」——蜜蜂采蜜（Foraging）、筑巢（Provisioning）、分享（Sharing），正好对应三个核心模块。

整体架构

MiBeeHive 围绕三个核心模块展开，每个模块职责明确：

flowchart LR
    subgraph 源头
        SRC@{shape: hex, label: "6 种软件源"}
    end

    subgraph MiBeeHive
        FORAGE["采蜜<br/>版本管理"]
        PROV["筑巢<br/>系统安装"]
        SHARE["分享<br/>文件共享"]
        CTNR["容器<br/>Docker 管理"]
        DASH["仪表盘"]
    end

    SRC -->|"抓取"| FORAGE
    FORAGE --> DASH
    PROV --> DASH
    SHARE --> DASH
    CTNR --> DASH

    classDef src fill:#E3F2FD,stroke:#1565C0,color:#1565C0
    classDef mod fill:#FFF3E0,stroke:#E65100,color:#BF360C
    classDef hub fill:#E8F5E9,stroke:#2E7D32,color:#1B5E20
    class SRC src
    class FORAGE,PROV,SHARE,CTNR mod
    class DASH hub

采蜜从 6 种公开软件源抓取版本；筑巢提供 PXE 无人值守装系统；分享通过 WebDAV 共享文件；容器模块管理 Docker 和 Registry。仪表盘聚合所有模块状态。

再看内部层次，整个系统是一条简洁的数据链路：

flowchart LR
    REQ["HTTP 请求"] --> MW["中间件<br/>JWT / TLS / 限流"]
    MW --> HDL["Handler"] --> SVC["Service"] --> REPO["Repository"]
    REPO --> DB@{shape: cyl, label: "SQLite"}

    classDef layer fill:#FFF3E0,stroke:#E65100,color:#BF360C
    classDef store fill:#E8F5E9,stroke:#2E7D32,color:#1B5E20
    class REQ,MW,HDL,SVC,REPO layer
    class DB store

标准分层：Handler → Service → Repository → SQLite。前端 Preact SPA 通过 go:embed 嵌入二进制，部署只需一个文件。

用户和设备通过不同方式接入：

flowchart LR
    BR["浏览器"] --> API["REST API<br/>:9090"]
    PXE["PXE 设备"] -->|"网络启动"| PXES["PXE 端点"]
    DAV["WebDAV 客户端"] -->|"文件读写"| DAVS["WebDAV 服务"]
    DK["Docker CLI"] -->|"push/pull"| REG["Registry"]

    API --> CORE["MiBeeHive 核心"]
    PXES --> CORE
    DAVS --> CORE
    REG --> CORE

    classDef client fill:#E3F2FD,stroke:#1565C0,color:#1565C0
    classDef endpoint fill:#FFF3E0,stroke:#E65100,color:#BF360C
    classDef core fill:#E8F5E9,stroke:#2E7D32,color:#1B5E20
    class BR,PXE,DAV,DK client
    class API,PXES,DAVS,REG endpoint
    class CORE core

四种接入方式覆盖所有场景：浏览器管后台、PXE 装系统、WebDAV 传文件、Docker CLI 推拉镜像。

采蜜（Foraging）— 版本管理

这个模块解决的是「怎么把开源软件的最新版本快速拉到内网」的问题。

flowchart LR
    SRC["软件源"] -->|"定时调度"| SCHED["解析版本"]
    SCHED -->|"发现新版"| DL["下载队列"]
    DL -->|"SHA256 校验"| STORE@{shape: cyl, label: "本地存储"}

    classDef input fill:#E3F2FD,stroke:#1565C0,color:#1565C0
    classDef proc fill:#FFF3E0,stroke:#E65100,color:#BF360C
    classDef out fill:#E8F5E9,stroke:#2E7D32,color:#1B5E20
    class SRC input
    class SCHED,DL proc
    class STORE out

目前支持 6 种软件源：

• GitHub Releases — 最常用，通过 API 获取最新 release 资产
• Go Proxy — 直接拉取 Go 编译工具链
• HashiCorp — Terraform、Consul、Vault 等产品
• Grafana — Grafana、Loki、Tempo 等
• NPM — 前端工具链
• PyPI — Python 包

每个源都通过 Web UI 配置，支持 API Token 管理、定时调度、自动重试和完整性校验。以前要写 6 套 Shell 脚本的事情，现在在页面上点点就搞定了。

目前支持 6 种软件源：

• GitHub Releases — 最常用，通过 API 获取最新 release 资产
• Go Proxy — 直接拉取 Go 编译工具链
• HashiCorp — Terraform、Consul、Vault 等产品
• Grafana — Grafana、Loki、Tempo 等
• NPM — 前端工具链
• PyPI — Python 包

每个源都通过 Web UI 配置，支持 API Token 管理、定时调度、自动重试和完整性校验。以前要写 6 套 Shell 脚本的事情，现在在页面上点点就搞定了。

筑巢（Provisioning）— 系统安装

这个模块解决的是「批量给设备装系统」的问题。

sequenceDiagram
    participant CLIENT as ARM64 设备
    participant DHCP as DHCP 服务
    participant PXE as MiBeeHive PXE
    participant TFTP as TFTP/HTTP
    participant WEB as Web 管理界面

    Note over WEB,PXE: 1. 管理员通过 Web 配置安装模板
    WEB->>PXE: 创建 preseed/kickstart/autoinstall 配置

    Note over CLIENT,DHCP: 2. 设备网络启动
    CLIENT->>DHCP: DHCP 请求 (PXE)
    DHCP-->>CLIENT: 返回 PXE 服务器地址
    CLIENT->>PXE: 请求启动配置

    Note over PXE,TFTP: 3. 下发安装配置
    PXE->>CLIENT: 返回 bootloader + kickstart URL
    CLIENT->>TFTP: 下载内核和 initrd
    CLIENT->>TFTP: 下载 ISO（流式传输）

    Note over CLIENT: 4. 无人值守安装
    CLIENT->>CLIENT: 自动分区、安装、配置

核心能力：

• PXE 服务 — 设备插上网线开机就装，不用 U 盘
• OS 模板生成 — 支持 Debian preseed、RHEL kickstart、Ubuntu autoinstall，在 Web 上填表就行
• ISO 管理 — 自动发现主流发行版的最新 ISO，流式下载，省磁盘
• 配置预览 — 生成模板后可以直接预览完整配置文件，确认没问题再部署

以前装 10 台机器得折腾一天，现在配置好模板，开机就装，基本不用管。

分享（Sharing）— WebDAV 文件共享

这个最简单也最实用：一个 WebDAV 服务器，匿名只读 + 管理员读写，支持 HTTPS。

内网传文件再也不用 scp 了，浏览器直接拖拽上传，或者用 WebDAV 客户端挂载为本地磁盘。Windows Explorer、macOS Finder、Linux 的 davfs2 都能直接连。

容器管理

这个是后来加的模块。自己的项目打包成镜像后，需要一个地方管理和分发。

• Docker 容器的增删改查、启停、日志查看、资源统计
• 多 Registry 支持，镜像同步
• Tag 保留策略，自动清理旧版本
• 应用模板，一键部署常用服务

仪表盘

所有模块的聚合视图：

• 系统状态：CPU、内存、磁盘实时图表
• 模块卡片：各模块的关键指标一目了然
• 活动时间线：最近的抓取、下载事件
• 快捷操作：常用功能一键直达

技术选型

选技术的时候有几个硬性约束：

1. 单二进制：ARM64 小主机上不想装 Java Runtime、Node.js 之类的东西
2. 低内存：目标设备只有 469MB RAM
3. 纯 Go：不依赖 CGO，交叉编译方便
4. 不引入重框架：不用 chi/gin/echo，不用 npm，不用 cron 库

最终方案：

前端用的是 Preact + HTM 的组合，不用 JSX、不用编译、不用 npm，直接写 JS 就行。整个前端 38 个模块，打包后嵌入 Go 二进制，部署时只需要一个文件。

实际部署

我这边用一台 ARM64 小主机跑的，469MB 内存，32GB 存储。跑 MiBeeHive 本体大概占 30-40MB 内存，非常轻量。

systemd 服务配置：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

[Unit]
Description=MiBeeHive
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=mibeehive
ExecStart=/opt/mibeehive/mibeehive
WorkingDirectory=/opt/mibeehive
Restart=on-failure
RestartSec=5

# 安全加固
NoNewPrivileges=true
ProtectSystem=strict
ReadWritePaths=/opt/mibeehive
PrivateTmp=true

[Install]
WantedBy=multi-user.target

保存到 /etc/systemd/system/mibeehive.service，systemctl enable --now mibeehive 就完事了。

关于「蜂巢」这个名字

MiBeeHive，“Mi” 是我 Mickey 的缩写，“Bee” 来自 Mi-Bee Studio，“Hive” 是蜂巢。三个核心模块的名字也都和蜜蜂有关：

• Foraging（采蜜） — 从各种软件源「采」最新版本回来
• Provisioning（筑巢） — 给新设备「筑」好运行环境
• Sharing（分享） — 蜂巢里的资源「分享」给所有人

虽然有点中二，但好记。

开源地址

MiBeeHive 已经开源，感兴趣的可以下载试玩：

• MiBeeHive：https://github.com/Mi-Bee-Studio/MiBeeHive （AGPL-3.0 许可证）

文档比较全，架构、部署、API 参考都有。

写在最后

这个项目本质上就是我自己为了解决个人日常问题而造的工具。个人精力有限，前期基本只会围绕我自己遇到的实际需求来迭代，不会刻意追求功能全面。

如果你刚好也有类似的需求，可以下载试试看，觉得有用就好。