Incus 脚本审阅与验收 · 第 2 / 8 篇
最容易误导人的部署结果，是六个实例都显示 Running，作者便宣布“一键成功”。但 Running 只说明实例在运行，不能证明根盘配额生效、SSH 可登录、DNS 正常，或者宿主机还有足够空间。这篇把部署拆成可解释的步骤。
为什么先限制操作系统和架构
现存脚本先检查 root、VERSION_CODENAME=bookworm 和 amd64。这不是为了让命令显得专业：仓库地址、软件包、内核能力及系统服务都依赖这些条件。其他发行版即使也有 apt，也不能直接视为同一环境。
部署前应保存下面的只读信息，作为以后排错的基线：
cat /etc/os-release
uname -r
dpkg --print-architecture
free -h
df -h /
ss -lntup
command -v docker
command -v incus
如果已经有网站、Incus 池或同名实例，不能把这台机器当成“全新宿主机”。现存脚本会修改已存在 vps1—vps6 的 CPU、内存、自启和 SSH 设置，还会移除名为 nat-tcp、nat-udp 的设备。因此，“不会删除已有实例”不等于“不会改变已有业务”。先清点设备和配置，再决定是否适用。
安装源为什么要校验密钥
脚本使用 Zabbly 的 Incus 6.0 LTS 仓库，保存仓库签名公钥，再比对完整指纹，并用 Signed-By 限定仓库所用密钥。这样做是把“从哪里安装”变成明确的信任选择。固定指纹也意味着仓库换钥时脚本应当停止，由维护者查证后更新，而不是删除校验绕过去。
选择 LTS 分支有助于控制功能变化，但没有把每个软件包锁定到某个具体构建。可复现记录仍需保存 incus version、已安装包版本和镜像指纹。images:debian/12 是别名，同一别名以后可能指向新镜像；重装得到 Debian 12，并不代表每次得到完全相同的软件包集合。
初始化要检查状态，不能只检查一个名字
代码通过是否存在名为 default 的池决定是否执行最小初始化。这是简化判断，不是完整的“是否初始化”判定：已有自定义池但没有 default 的主机，可能被误判；有 default 也不能证明 incusbr0 正确。人工检查应同时看池、网桥和 profile：
incus storage list
incus network list
incus profile show default
incus network show incusbr0
创建 tiny-vps 时，脚本将根盘与网卡放入同一个 profile。这样新实例可以复用统一模板。已有同名 profile 会被复用而不逐项核对，所以还需要检查实际展开后的配置。
为什么采用 Btrfs，哪些说法需要纠正
目标不是随意给根盘写一个 size 字段，而是选择能在目标环境中落实配额的存储后端。脚本创建 Btrfs 池并为根盘写入 size=3GiB。Btrfs 提供写时复制和 qgroup 配额，但官方文档也明确说明其配额有绕过与空间核算限制，不能把它描述成严格的租户安全边界。Btrfs 官方说明
原脚本注释把 dir 概括为不能执行配额，这个表述不能普遍沿用。当前 Incus 文档说明，底层 ext4 或 XFS 启用项目配额时，dir 也可支持配额。正确说法是：本方案不依赖普通目录后端的额外配额条件，而选择了单独的 Btrfs 池。Directory 驱动说明
12GiB 是共享池的大小配置，3GiB 是单个根卷的上限配置。镜像、快照、文件系统元数据和其他卷也可能占用池空间。df 显示、配额配置和真正写入边界是不同证据；不能用一行配置文本代替容量测试。
建好一台后先验证什么
incus config show vps1 --expanded
incus storage show incus-quota
incus storage info incus-quota
incus exec vps1 -- systemctl is-active ssh
incus exec vps1 -- getent ahostsv4 deb.debian.org
展开配置用于核对继承关系，存储信息用于观察池状态，容器内命令用于验证服务和解析。配额写入测试应在专门的可丢弃实例内、小步增加数据并观察宿主机剩余空间；不要为证明“限制有效”而在承载业务的 12GiB 池里一次写满。
本篇结论：部署顺序应是环境清点、信任源核对、初始化状态检查、池与 profile 核对、单实例验收、分批扩展。这里列出的是可验证步骤；现有材料没有提供六实例容量压力测试结果。