feat: install nodes and the backend from a static compose file; remove dead code [CI]
ci/woodpecker/push/main-amd64-build Pipeline was successful
ci/woodpecker/push/main-amd64-build Pipeline was successful
Agent, Probe and Backend now start from one static compose.yaml plus a local
.env: the panel (or the release assets, for the very first Backend) provides
the file, the panel's command writes the public values into .env, checks the
file's SHA-256 and runs compose up. Updating is compose pull && compose up -d.
The image is chosen by the CI channel (:latest, or MOSHIRO_VERSION in .env),
not by the panel; the previous one-line script stays as a fallback.
- packaging/compose/{agent,probe,backend}/compose.yaml are the single source,
embedded in the Backend and served at /install/compose/{file}; the root
compose.yaml moved there. Releases also carry them and list them in the
signed SHA256SUMS.
- The container entrypoint defaults the node name to the host name.
- Join token creation returns a compose block (.env, url, hash, per-platform
commands); the admin dialog leads with it.
- Remove code with no references (HotLayer members, LiveHub.SubscriberCount,
QueryService.ParseParams, ReleaseService.Forget, a few constants) and reduce
the install-code lookup to the role it is for.
This commit is contained in:
justme committed
1 parent
e014a19554
commit
12be44645f
31 files changed
+492
-176
No files matched your search
+36
-25
@@ -42,19 +42,27 @@ Backend 使用 OCI 标准镜像，通过 `registry.oeo.one/moshiro/moshiro-backe
|
||||
|
||||
**前端内嵌在 Backend 里**：CI 构建 Backend 前先构建 `web/display` 和 `web/admin`，`Backend.Api` 把两个 `dist` 嵌进程序，展示端在 `/`，管理端在 `/admin/`，所以面板的域名（如 `https://mo.oeo.one/admin/`）打开就是管理端，passkey 才能绑定在这个域名上（浏览器只允许页面的来源与 RP 域名一致，本机 `localhost` 上的页面注册不了绑定 `mo.oeo.one` 的 passkey）。本地没有构建前端时不嵌入，Backend 只提供 API。文件是启动时读进内存的白名单，请求时不访问文件系统；带 `..`、反斜杠、`%`、控制字符或空段的路径一律 404，缺失的文件（带扩展名）404，只有无扩展名的路径回退到入口页；`/api`、`/openapi`、`/install`、`/healthz` 下没有匹配到的路径仍是后端的 JSON 404。页面带 CSP（脚本只许同源）、`nosniff`、`X-Frame-Options: DENY`，入口页 `no-cache`，哈希文件名的资源 `immutable`，不嵌入 source map。部署时设置 `MoShiro__PublicUrl=https://<面板域名>`（`deploy-node.sh backend --public-url …`），WebAuthn 的域名和允许的来源由它派生。
|
||||
|
||||
在部署目录保存此仓库的 `compose.yaml`，可选设置 `MOSHIRO_CLAIM_CODE`（认领码，不设置就随机生成并写进后端日志）和 `MOSHIRO_VERSION`，然后启动：
|
||||
**用 compose 部署**（Docker 和 Podman 通用，需要 `docker compose` 或 `podman compose`）：compose 文件是静态的，在仓库的 `packaging/compose/backend/compose.yaml`，每个发布版本的 Gitea Release 里也有一份 `moshiro-compose-backend.yaml`（第一次部署时还没有面板，就从这里下载）。镜像用 `:${MOSHIRO_VERSION:-latest}`：
|
||||
|
||||
```sh
|
||||
docker compose up -d
|
||||
mkdir moshiro-backend && cd moshiro-backend
|
||||
curl -fsSL https://git.oeo.one/justme/MoShiro/releases/download/<版本>/moshiro-compose-backend.yaml -o compose.yaml
|
||||
cat > .env <<'EOF'
|
||||
MOSHIRO_PUBLIC_URL=https://panel.example.com # 面板对外的地址；passkey 绑定在这个域名上，改了会让已注册的 passkey 失效
|
||||
# MOSHIRO_CLAIM_CODE= # 认领码，不写就随机生成并打印在日志里
|
||||
EOF
|
||||
podman compose up -d # Docker 用 docker compose
|
||||
```
|
||||
|
||||
**更新**：先备份数据卷，再 `podman compose pull && podman compose up -d`。新版启动时自动迁移数据库，但**旧版不认比自己新的数据库**：想回滚要先恢复备份，只改 `MOSHIRO_VERSION` 不够。Backend 能指挥所有节点，更新它尽量用宿主机更新器（见下文「Backend 签名更新」，清单有发布签名，更新前自动备份，不健康自动回滚），或者在 `.env` 里把 `MOSHIRO_VERSION` 固定到经过核对的版本或 digest。
|
||||
|
||||
**首次认领（没有默认管理员）**：面板里还没有任何用户时，打开 `/admin/` 会进入认领向导：
|
||||
1. 填认领码（首次启动时随机生成并写进后端日志，`journalctl -u moshiro-backend` 或 `docker logs`；也可以用 `MoShiro__ClaimCode` / `MOSHIRO_CLAIM_CODE` 指定）、管理员的用户名和密码；
|
||||
2. 注册你的第一把 passkey；
|
||||
3. 用它给操作员集合签名，建立信任根。
|
||||
谁先打开页面谁就能当管理员，所以认领码只有能看到后端日志的人拿得到；创建完第一个管理员，码作废、入口关闭（再提交返回 409）。认领码比较不分大小写、忽略分隔符；失败按来源地址限流。向导可以中途离开，passkey 和信任根之后随时在「用户 → 我的 Passkey」和「系统 → 信任」里补；没有 passkey 也能用密码登录管理。
|
||||
|
||||
Compose 将容器端口只绑定到宿主机 `127.0.0.1:8080`，适合由同机 HTTPS 反向代理转发；数据保存在命名卷 `moshiro-backend-data`（Docker 和 Podman 通用，`podman compose` 也可以用同一份文件）。首次启动成功创建管理员后，改密应在管理端完成。
|
||||
Compose 将容器端口只绑定到宿主机 `127.0.0.1:8080`，适合由同机 HTTPS 反向代理转发；数据保存在命名卷 `moshiro-backend-data`（Docker 和 Podman 通用）。首次启动成功创建管理员后，改密应在管理端完成。
|
||||
|
||||
Backend 的 NativeAOT 发布默认启用 `SqliteStaticLink`，支持 Linux glibc/musl、macOS、Windows 的 x64/arm64 RID；跨平台构建使用 `-p:UseAotAnywhere=true`。SQLite 源码版本、下载年份和 SHA-256 统一配置在根目录 `Directory.Packages.props`，构建会校验下载文件并按 RID 缓存原生对象。普通 JIT 开发构建仍使用 NuGet 原生库。发布 Backend 时设置 `-p:OpenApiGenerateDocuments=false`，API 文档在普通开发构建中生成。
|
||||
|
||||
@@ -215,7 +223,28 @@ OpenWrt 默认不带 OpenSSL：`opkg install libopenssl3`（较新的快照和 2
|
||||
|
||||
镜像和 Compose 配置共用。普通用户执行 Podman 即为 rootless，使用命名 volume 不需要 `keep-id` 或手动 `chown`。Agent 的配置、原有身份和缓存保存在 `moshiro-agent-config`，Probe 保存在 `moshiro-probe-config`，更新状态使用独立的 `moshiro-<role>-status` volume，在业务容器内只读。不会重新生成已有身份。更新/重建容器不删除 volume；不要使用 `compose down -v`，该参数会删除数据。
|
||||
|
||||
**一行安装（Docker 或 Podman，Agent 和 Probe 共用）**：管理端「添加 Agent」「添加 Probe」生成加入令牌之后，给出一行命令，面板地址、一次性代码、信任根指纹和属主都已经填好，没有要自己替换的占位符；节点名字默认取主机名。命令先下载静态安装脚本、核对它的 SHA-256，一致才执行：
|
||||
**compose 安装（Agent 和 Probe，推荐）**：管理端「添加 Agent」「添加 Probe」生成加入令牌之后，给出一段命令（面板地址、一次性码、信任根指纹和属主都是公开的值，没有私钥）：建一个目录，把参数写进 `.env`（权限 600），下载面板提供的静态 compose 文件、核对 SHA-256，一致才启动：
|
||||
|
||||
```sh
|
||||
mkdir -p moshiro-probe && cd moshiro-probe && cat > .env <<'EOF'
|
||||
MOSHIRO_SERVER=https://panel.example.com
|
||||
MOSHIRO_JOIN=jt_…
|
||||
MOSHIRO_GENESIS=…
|
||||
MOSHIRO_CONTROLLERS=…
|
||||
MOSHIRO_IMAGE=registry.oeo.one/moshiro/moshiro-probe
|
||||
# MOSHIRO_NAME=节点名字（不写就用主机名）
|
||||
EOF
|
||||
chmod 600 .env && curl -fsSL 'https://panel.example.com/install/compose/probe.yaml' -o compose.yaml && echo "<sha256> compose.yaml" | sha256sum -c - && podman compose up -d
|
||||
```
|
||||
|
||||
- compose 文件是静态的（`packaging/compose/agent|probe|backend/compose.yaml`，作为嵌入资源打进 Backend，由 `/install/compose/{agent,probe,backend}.yaml` 原样提供，不含任何一次性的值）。镜像是 `${MOSHIRO_IMAGE}:${MOSHIRO_VERSION:-latest}`，由 CI 渠道决定，**不由面板决定**；`MOSHIRO_IMAGE` 取自面板的 `MoShiro__NodeImageRegistry` 和 `MoShiro__ImageNamespace`（默认 `registry.oeo.one/moshiro`，开发镜像 `moshiro-dev`）。
|
||||
- 只读根文件系统、丢掉全部能力、`no-new-privileges`、命名卷；Linux 上用宿主网络（Agent 对外暴露端口，也靠它识别本机公网地址，并只读挂载 `/proc`、`/sys`、`/` 读主机指标）。**Agent 的 compose 只适用于 Linux**；Probe 在 macOS 和 Windows（Docker Desktop）上没有宿主网络，面板给的命令会在 `.env` 里写 `MOSHIRO_NETWORK_MODE=bridge`。
|
||||
- 身份和配置在命名卷 `moshiro-<role>-config` 里：镜像入口脚本（`packaging/container/entrypoint.sh`）第一次启动用 `MOSHIRO_SERVER`、`MOSHIRO_JOIN`（和信任根指纹、属主）注册并写配置，之后重启、换新镜像重建容器都不需要再给参数，所以注册成功之后可以把 `.env` 里的 `MOSHIRO_JOIN` 删掉。缺了信任根指纹或属主就不注册（只有还没有信任根的老面板才用 `MOSHIRO_ALLOW_NO_OWNER=1`）。
|
||||
- Podman 的开机自启要靠 `podman-restart.service`（`systemctl enable --now podman-restart`；rootless 用 `--user`，并 `loginctl enable-linger`）；Docker 用 compose 里的 `restart: unless-stopped`。
|
||||
- **更新**：`podman compose pull && podman compose up -d`（Docker 用 `docker compose`），只重建镜像变了的容器，身份和配置不动，节点几十秒内重连。想固定版本，在 `.env` 里写 `MOSHIRO_VERSION=0.3.3`；想要更严，写成 `MOSHIRO_VERSION=0.3.3@sha256:<digest>`，digest 取自面板信任页或签名清单（那里有发布签名）。回滚就是改回旧版本再 `up -d`。
|
||||
- **信任**：compose 来自面板或 CI 渠道，面板被攻破也改不了镜像地址；但客户端不再验发布签名，拉取靠 TLS 加「注册表可信」这个假设（文档里本来就把 CI、Gitea、注册表放在可信范围内）。这条路没有管理端的「更新」列和确认更新按钮，那些依赖宿主机更新器；要有签名验证的更新，用下面的部署脚本。
|
||||
|
||||
**一行安装脚本（备用，Docker 或 Podman，Agent 和 Probe 共用）**：管理端的弹窗里折叠着一条旧的一行命令，先核对脚本哈希再执行，脚本向面板取签名清单、用内置发布公钥验签、按 digest 拉镜像：
|
||||
|
||||
```sh
|
||||
f=$(mktemp) && curl -fsSL 'https://panel.example.com/install' -o "$f" && echo "<sha256> $f" | sha256sum -c - >/dev/null \
|
||||
@@ -223,12 +252,7 @@ f=$(mktemp) && curl -fsSL 'https://panel.example.com/install' -o "$f" && echo "<
|
||||
# Windows（PowerShell）：irm 'https://panel.example.com/install.ps1' 下载后用 Get-FileHash 核对，不一致就 throw，再带同样的环境变量运行
|
||||
```
|
||||
|
||||
- 脚本是静态的同一份（`packaging/install/install.sh` 和 `install.ps1`，作为嵌入资源打进 Backend，原样返回，不替换任何值），所以它的 SHA-256 在一个版本内固定；角色、面板地址、代码和属主走环境变量。脚本向面板取该角色已签名的发布清单（凭一次性代码），用内置的发布公钥验签，再按清单里的 digest 拉镜像；代码不存在、已吊销、已过期或用完了取清单都是 404。缺了 `MOSHIRO_GENESIS` 或 `MOSHIRO_CONTROLLERS` 就不装（只有还没有信任根的老面板才用 `MOSHIRO_ALLOW_NO_OWNER=1`）。
|
||||
- 脚本检测 Docker 或 Podman（连不上就自动用 sudo），拉镜像，起容器 `moshiro-<role>`：只读根文件系统、丢掉全部能力、Linux 上用宿主网络（Agent 对外暴露端口，也靠它识别本机公网地址），macOS 和 Windows 上 Agent 发布 7443、7444 端口；注册成功（日志出现 `link up`）才算装好。
|
||||
- 身份和配置在命名卷 `moshiro-<role>-config` 里（持久化）：镜像入口脚本（`packaging/container/entrypoint.sh`）第一次启动用 `MOSHIRO_SERVER`、`MOSHIRO_JOIN`、`MOSHIRO_NAME` 注册并写配置，之后重启、换新镜像重建容器都不需要再给参数。卷名和部署脚本一致，以后可以直接切到脚本方式。
|
||||
- 环境变量：`MOSHIRO_NAME=名字`（想自己定，或者提示名字被占用）、`MOSHIRO_ENGINE=docker|podman`、`MOSHIRO_DRY_RUN=1`（只打印 run 命令）。Podman 会顺便启用 `podman-restart`，容器开机自启。
|
||||
- 镜像地址由 Backend 的 `MoShiro__NodeImageRegistry`（默认 `registry.oeo.one`）和 `MoShiro__ImageNamespace`（默认 `moshiro`，开发镜像 `moshiro-dev`）拼出；私有仓库先 `docker login` 或 `podman login`。
|
||||
- 更新：拉新镜像、删掉旧容器、重新执行安装命令（卷保留）；要自动更新（签名清单）用下面的部署脚本。
|
||||
脚本是静态的（`packaging/install/install.sh` 和 `install.ps1`，嵌入 Backend，不替换任何值），所以它的 SHA-256 在一个版本内固定；角色、面板地址、代码和属主走环境变量。环境变量 `MOSHIRO_NAME`、`MOSHIRO_ENGINE=docker|podman`、`MOSHIRO_DRY_RUN=1`（只打印 run 命令）；Podman 会顺便启用 `podman-restart`。
|
||||
|
||||
**用脚本部署和更新（rootful Podman 或 Docker，推荐）**：`packaging/container/deploy-node.sh` 可以重复运行，每次都会拉取镜像并固定到 digest、把配置迁移到当前版本需要的样子（例如旧的 `listen.bind` 为 `0.0.0.0` 的 Agent 改成 `::`，这样 IPv6 线路才能建立）、重装单元和更新器，然后重启节点；已有的身份不会动，更新策略沿用上次的。
|
||||
|
||||
@@ -247,24 +271,11 @@ sudo sh deploy-node.sh backend --channel dev --public-url https://<面板域名>
|
||||
sudo sh deploy-node.sh agent
|
||||
```
|
||||
|
||||
Agent 的 `public_host` 和 `ipv6_host` 由 Agent 上报自动识别（需要宿主网络，脚本和 Compose 默认如此，监听 `::`），IPv6 不用额外配置。下面是不用脚本的手动步骤。
|
||||
|
||||
在 `packaging/compose/agent` 下首次注册，并写配置（下列 `podman` 可替换为 `docker`）：
|
||||
|
||||
```sh
|
||||
podman compose run --rm --entrypoint /usr/local/bin/fleet-enroll agent \
|
||||
--server https://<backend> --join <token> --name <name> --identity-dir /etc/moshiro/agent-id
|
||||
podman compose run --rm -T --entrypoint /bin/sh agent -c 'cat > /etc/moshiro/agent.json' <<'JSON'
|
||||
{"fleet":{"server":"https://<backend>","identity_dir":"/etc/moshiro/agent-id"},"listen":{"bind":"::"}}
|
||||
JSON
|
||||
podman compose up -d
|
||||
```
|
||||
|
||||
Probe 在 `packaging/compose/probe` 下，和 Agent 一样先用 `fleet-enroll` 注册：`podman compose run --rm --entrypoint /usr/local/bin/fleet-enroll probe --server https://<backend> --join <probe 令牌> --name <name> --identity-dir /etc/moshiro/probe-id`，再写 `probe.json`（`{"fleet":{"server":"https://<backend>","identity_dir":"/etc/moshiro/probe-id"}}`），然后 `podman compose up -d`。已有部署迁移时，应把原配置与身份原样复制进 volume，不重新注册。要换密钥就在面板吊销再重新注册。Docker 与 Podman 各自管理 volume，切换引擎不会自动共享数据。
|
||||
Agent 的 `public_host` 和 `ipv6_host` 由 Agent 上报自动识别（需要宿主网络，脚本和 Compose 默认如此，监听 `::`），IPv6 不用额外配置。
|
||||
|
||||
纯 Compose 使用 `compose pull && compose up -d` 更新镜像；面板自动更新使用下述 systemd 单元和更新器。Rootless Podman 使用 `moshiro-<role>-rootless.service`，安装到 `~/.config/systemd/user/`，镜像文件为 `~/.config/moshiro/<role>.image`；rootful Podman 使用 `moshiro-<role>-container.service`，Docker 使用 `moshiro-<role>-docker.service`，安装到 `/etc/systemd/system/`，镜像文件为 `/etc/moshiro-update/<role>.image`。所有单元均使用相同的配置和状态 volume 名称。自动启动分别使用 `systemctl --user enable --now <unit>` 或 `sudo systemctl enable --now <unit>`。Rootless 在退出登录后继续运行需管理员执行一次 `loginctl enable-linger <用户名>`。
|
||||
|
||||
Backend 用根目录的 `compose.yaml`（见上文「Backend 容器」），数据库和原始数据在命名卷 `moshiro-backend-data` 里。首次安装 Podman 与用户 subuid/subgid 映射需要管理员权限，之后普通用户运行无需 sudo。
|
||||
Backend 用 `packaging/compose/backend/compose.yaml`（见上文「Backend 容器」），数据库和原始数据在命名卷 `moshiro-backend-data` 里。首次安装 Podman 与用户 subuid/subgid 映射需要管理员权限，之后普通用户运行无需 sudo。
|
||||
|
||||
已在 Fedora CoreOS 的 SELinux Enforcing 环境、Podman 6.0.2 rootless 下用同一份 Compose 实测：Agent 注册、宿主指标、Probe 登录和 TLS 连接正常，IPv4/IPv6 ICMP 目标任务收到有效回包，容器保持 `cap_drop: ALL`，未添加 NET_RAW。Linux ICMP 优先使用 datagram ping socket，不依赖外部 ping 程序；需要 `net.ipv4.ping_group_range` 包含容器映射后的 GID（测试环境为 `0 2147483647`）。宿主禁止普通用户 ping 时，需管理员配置该范围；例如 rootful Docker 的用户 GID 1654 可设置 `sysctl -w "net.ipv4.ping_group_range=1654 1654"`。rootless 应使用映射后的宿主 GID，不能直接套用容器 GID。单加 `cap_add: NET_RAW` 不保证非 root 用户获得有效 capability。有原始套接字权限的部署仍保留原有 Ping 回退路径。其他操作系统继续使用 System.Net.Ping。ICMP 目标任务当前由 Agent 执行，Probe 没有独立目标任务入口。
|
||||
|
||||
|
||||
Reference in new issue
Block a user