收官：6 台小鸡的现状、成本账与下一步

系列前四篇讲了选型、部署脚本、两次排障、运维三件套。这篇收官：现在是什么状态、花了多少钱、还有哪些坑没填——尤其是安全加固，这是目前最该做的事。

现状：如实汇报

• AndNode 年付机（2核/2G，Debian 12）上，3 台版部署脚本已真机跑过：存储池 incus-quota（btrfs 12GiB）、profile tiny-vps 就绪，vps1 已 launch，SSH 端口 2201 已映射到公网。vps2/vps3 是下一步。
• 6 台是目标拓扑，6 台版脚本与 3 台版同源（仅 COUNT 不同），跑之前请先看脚本输出的 PASS/FAIL 验收。
• 之前在 RackNerd 练手机上用 runman 开过 5 台 256MB 小鸡做实验，结论是 5 台同压母鸡 CPU 会跑满——这条教训直接决定了生产机小鸡只跑轻负载。
• 运维三件套（端口管理、重装菜单、Komari 批量管理）已编写完成，自带验收，以实际运行结果为准。

成本账

AndNode 这台年付 ¥144，6 台小鸡摊下来 ¥24/台/年。市面上这个价位能买到的"小鸡"要么是 NAT 的，要么没独立 SSH。而我的每台都是完整 Debian 系统容器、独立公网 SSH 端口、3GiB 磁盘配额上限。这就是折腾的回报：把一台机器的剩余价值榨干。

安全加固 TODO：最重要的一节

必须坦白说：当前方案有个明显短板——公网 SSH 密码登录。2201–2206 端口面向所有公网 IP，虽然密码是 32 位随机 hex（openssl rand -hex 16），但密码登录天生扛不住爆破扫描。以下按优先级排序，是下一步必须做的：

1. 换密钥登录：每台小鸡 ssh-copy-id 导入公钥后，把 PasswordAuthentication 设为 no。这是性价比最高的一步，做了之后爆破直接失效。具体就是改之前部署脚本写进去的那个文件：

# 先确认密钥能登录，再关密码（顺序反了就把自己锁外面）
# 203.0.113.10 是示例 IP，换成你宿主机的真实 IP
ssh-copy-id -p 2201 root@203.0.113.10
incus exec vps1 -- bash -c 'echo "PasswordAuthentication no" > /etc/ssh/sshd_config.d/00-incus-root.conf && systemctl restart ssh'

注意顺序：先确认密钥登录成功，再关密码。顺序反了，当前这条 SSH 断了就进不去了。

1. fail2ban：宿主机或小鸡里装 fail2ban，SSH 多次失败自动封 IP。密码登录阶段它是保命的：

apt-get install -y fail2ban
systemctl enable --now fail2ban  # 默认就带 sshd 规则

1. 收敛暴露面：云防火墙/安全组里只放行需要的端口；暂时不用的小鸡可以 incus stop，连端口映射一起省了。
2. Komari 异地告警：小鸡上都装上 Komari agent（本系列第四篇的批量管理器就是干这个的），CPU/内存/离线告警先配起来——6 台机器靠人巡检不现实。

另外提醒：/root/incus-vps-passwords.txt 和 /root/incus-reinstall-passwords.txt 是 0600 权限，但不要进任何网盘同步、不要截图发群，这是底线。

下一步规划

1. 落地 vps2/vps3，跑通 3 台版的完整验收；
2. 按需用端口管理器开业务端口（规划：vpsN 用 22000+N×10 段）；
3. 换密钥登录 + fail2ban，加固先行；
4. 考虑备份策略：btrfs 快照是最自然的选择，incus snapshot 一行命令，定期快照 + 异地同步。快照是写时复制，几乎不占额外空间：

incus snapshot create vps1 clean-debian   # 打快照
incus snapshot restore vps1 clean-debian   # 玩坏了秒回滚

比整机 dd 备份轻得多，适合"折腾前先拍个快照"的习惯。快照本身还在同一块盘上，重要数据还是要异地再备一份——快照防手滑，不防硬盘挂。 5. 这个系列本身就是文档沉淀——以后每折腾一个新东西，就按"为什么→怎么做→踩坑→效果"的结构写一篇。

成本账的另一面：时间

¥24/台/年是钱账，还有时间账。写这套脚本断断续续花了好几天，如果只是"开 6 台小鸡用一次"，手动敲命令更快。但脚本的价值在于复用：换一台机器、重装一次、帮朋友开一台，同一套脚本直接跑。运维自动化的 ROI 从来不在第一次，而在第 N 次。这也是为什么脚本里有那么多"防御性"代码——写的时候多花一小时，半年后重跑时省的是半夜爬起来排障的三小时。更别说这个系列文章本身：脚本和文档互相印证，下次我自己回看也看得懂。

写在最后

这个系列的 5 篇已经发在本站，配图是现画的 4 张技术插画，统一放在"Incus 实战"分类下。每篇文末都留了英文 slug 和一句话摘要，方便以后做系列归档页。

下一篇折腾（比如 btrfs 快照备份实战），会按同样的"为什么→怎么做→踩坑→效果"结构写——格式统一了，写起来快，读起来也省心。另外，文中所有公网 IP 都是 203.0.113.0/24 文档段示例，照着做时记得换成自己的。

系列导航

1. 《一台 2C2G 的 VPS，我把它切成了 6 台小鸡：为什么选 Incus？》——选型：Incus 6.0 LTS、btrfs 共享配额池、256MiB 规格的由来
2. 《从裸机到 6 台小鸡：我的 Incus 一键部署脚本全解析》——逐段讲脚本：指纹校验、proxy vs nat、断点续跑、9 项验收
3. 《小鸡连不上网？两次真实排障实录》——Docker FORWARD=DROP、apt 撞上 Fastly
4. 《小鸡运维三件套：端口管理、一键重装、批量监控》——pm_ 命名规范、rebuild 保配置、Komari 批量装
5. 本篇收官

折腾的终点不是"搭起来了"，是"讲清楚了"。这个系列的每一篇都只写我实际做过、实际验证过的东西——没跑过的，文章里都标出来了。如果你照着做，遇到不一样的结果，欢迎回来交流。

回头看：哪几个决定做对了

写完这个系列回头看，有几个决定现在觉得特别值：

1. 先拿练手机交学费：在 RackNerd 上用 runman 开 5 台做压测，才知道 6 台同压会抢 CPU——这个结论直接决定了生产机小鸡的轻负载定位。如果一上来就在生产机上莽，xboard 节点的质量就保不住了。
2. 脚本里写验收：9 项自动验收看起来啰嗦，但它把"我以为配好了"变成了"机器说配好了"。人和机器之间，信机器。
3. 排障沉淀进脚本：DOCKER-USER 规则和 ForceIPv4 如果只记在备忘录里，三个月后重装一次又要重新踩坑。写进脚本的才是真正的"解决"。
4. 诚实标注边界：没验证过的就写"以实际运行结果为准"。技术文章里最伤人的不是写错，而是让读者以为"作者都验证过了"。