文章

keelOS：Docker 可以一条命令搞定一个应用，虚拟机也可以一键安装么？

2026-09-30 · Wanpeng Qian

Docker 为什么一条命令就行

docker run -d -p 80:80 nginx，一秒钟后浏览器里就有一个网站。这一条命令背后是五件事同时成立：镜像有一个公共的仓库；镜像是分层的，下载只拿没有的层；应用把自己要的配置声明在外面（端口、目录、环境变量）；数据和程序是分开的（volume）；升级就是换一个镜像再跑一次。容器本身不是重点，这五件事才是。

但是虚拟机一样都没有。装一台邮件服务器的虚拟机：下 ISO，建机器，选内存和盘，装系统，装软件，改十几个配置文件，开端口，申证书。熟练的人半天，不熟练的一周，升级的时候再来一遍，而且升坏了退不回去。所以家用和小办公室的服务大多跑在容器里，虚拟机只给 Windows 和那些非得要一整台机器的东西。

可是虚拟机有容器没有的东西：自己的内核，硬隔离，任何操作系统，直通的硬件，带内存的快照。一台小办公室的邮件服务器、一台 NAS、一台软路由，其实都更适合是一台完整的机器。问题从来不是虚拟机不好，是没有人把那五件事给虚拟机做齐。

Docker 也不是万能药。它 2013 年从 dotCloud 这家 PaaS 公司里长出来，要解决的是"开发机上能跑、服务器上也得能跑"：把一个应用连同依赖打包，在开发、测试、部署之间搬来搬去不走样。它的前提是所有容器共用主机的内核：隔离是软的，内核的漏洞就是所有容器的漏洞；只能跑 Linux；直通一块网卡、一个 HBA 给容器很别扭；带状态的服务（邮件、数据库）得自己操心数据放哪、怎么备份。容器当年胜在轻，因为那时一台机器跑不起几台虚拟机。今天家用的机器也有 16 核、64 GB，虚拟机的开销已经不是问题（内存里一半是零页，keelOS 会把它们收回去），剩下的差距只是好不好用。

别人试过的

"一键装一台虚拟机"不是新想法，已经有二十年的尝试，每一家都做对了一部分。

有两件事没有人在虚拟机上做全：配置和数据从镜像里分出来（cloud-init 做了前一半），和升级是换镜像而不是在机器里改。这两件恰好都是存储层的事，有 ZFS 就不难。

设想：小办公室装邮件服务器的一天

把目标写成一个场景，比写成功能列表更容易看出哪里难。一家十个人的公司，一台 keelOS 机器，要一个自己的邮件服务器。

1. 网页上打开"应用"，选"邮件服务器"。页面写着它是什么（比如 Postfix + Dovecot + Rspamd + 一个网页邮箱）、要多少内存和盘、谁维护、上次更新是什么时候。
2. 点"安装"。一页表单：域名、第一个管理员邮箱和密码、邮件存在哪个池、要多大。其他的都有默认值。
3. 下载。镜像从 keelOS 的仓库来，几百 MB，校验和和签名在本地核对。如果这台机器已经装过同一个基础镜像（比如同一个 Debian），只下差的那一层。
4. 开机。第一次开机时表单里的东西送进 guest，里面的初始化脚本生成配置、建管理员、申请证书。这一步大概一两分钟。
5. 页面上出现"就绪"，旁边是还要做的两件事：DNS 里加哪几条记录（页面把值给写好），路由器上开哪几个端口。这两件在机器外面，谁也替不了。
6. 三个月后上游出了安全更新。页面上邮件服务器旁边多了一个"有更新"。点一下：新镜像下来，开一台新机器接上同一块数据盘，老机器停掉但保留。不好用就点"退回"，老机器回来。

每一步都能指出是谁在做：第 1–3 步是仓库和签名，第 4 步是镜像作者写的初始化脚本，第 5 步是人，第 6 步是 ZFS。

模板长什么样

把 Docker 的五件事搬到虚拟机上，每一件都有一个现成的落点。镜像的分层不用自己发明：ZFS 的快照和克隆就是分层，增量 send/receive 就是"只下没有的层"。

模板本身是一个小文件加一个镜像：基于哪个基础镜像、应用层的版本、要多少内存和 vCPU、哪些盘是数据盘、安装时要问用户哪几个问题、开机时执行什么。keel 今天的模板（windows11、freebsd、windowsxp 这些）已经是这样的 JSON，只是还没有"应用层"和"问题"这两段。

配置怎么送进 guest 是唯一需要定的地方。云上用 cloud-init 读一个 metadata 服务，家里没有；但 cloud-init 也认一块标有 cidata 的小盘（NoCloud）。keel 开机时生成这块盘，里面是表单的答案，现成的 Debian 和 FreeBSD 云镜像不改就能吃。Windows 有同样的东西（unattend.xml），只是慢一些。

升级怎么做到随时、可退

升级是这件事里真正有价值的部分，也是所有前人没做全的部分。规则只有一条：不在老机器里升级，开一台新的。

1. 仓库里有了 [email protected]，页面上标"有更新"，附变更说明。
2. 点了以后：增量下载新的应用层（基础镜像没变就不下）；给数据盘拍一个快照；从 [email protected] 克隆一台新机器，接上同一块数据盘和同一份配置；老机器停、新机器开，中间十几秒。
3. 新机器第一次开机时模板的升级脚本跑一遍（比如数据库的 schema 迁移）。成功就报"就绪"。
4. 不成功，或者用了两天发现不对："退回"。新机器停，数据盘回滚到第 2 步的快照，老机器开。老机器一直没动过，所以一定能开。
5. 用了一周没问题，老机器和那个快照自动删掉。

这就是容器的"换镜像再跑一次"，多了一步数据盘的快照，换来的是容器没有的"两天后还能退"。代价是模板作者得守一条约定：所有会变的东西都在数据盘和配置里，系统盘里什么都不留。这条约定容器世界已经守了十年，作者们习惯了。

基础镜像的安全更新也是同一条路：debian-13 出了新的快照，所有建在它上面的应用都标"有更新"，一台一台换，每一台都能退。不想管的用户可以设成夜里自动换、开机自检不过就自动退。

keelOS 已经有的地基

到 2026-09-30 为止，这件事需要的底层已经在 keel（keelOS 的管理程序）里了：

• 模板：keel vm create --template windows11 这样的 JSON 模板，写好了 CPU、内存、盘的类型、固件、显卡、最小要求；用户自己的模板放在 dataset 的 .templates/ 里就能覆盖内置的。
• 镜像目录和克隆：zones/vm/images/<uuid> 是镜像，@final 快照给克隆用；非管理员的令牌建机器时只能从 image_dirs 里选盘，这就是"应用商店只能装商店里的东西"的权限模型。
• 每台 guest 一棵 dataset，盘可以是子 zvol：数据盘和系统盘分开、各自快照，今天就能做。
• API 和令牌：网页、命令行、MCP 走同一套 REST API，权限到"只能开关机""只能建机器"这个粒度。商店就是网页里多一页。
• 主机升级不停 guest：应用升级和主机升级互不干扰，不用凑维护窗口。

还没有的三样：模板里的"问用户什么"和开机时把答案送进去的那块小盘；一个能增量下载、能验签的镜像仓库；"有更新 → 克隆新版 → 退回"这一套流程。三样都是现有东西的组合，没有需要发明的部分。

还没想好的，和市场空间

技术上的路是清楚的，没想好的是人的部分。

• 谁做模板。 一个好的邮件服务器模板是几周的工作，而且要有人长期跟着上游出更新。Docker Hub 的经验是官方镜像少而精、社区镜像参差不齐。keelOS 自己先做十来个小办公室最要的（邮件、文件共享、密码库、网盘、备份、软路由、Home Assistant），再开给别人。
• 怎么信任。 一台虚拟机里能藏任何东西。镜像签名只证明"是谁做的"，不证明"里面干净"。可能的办法：模板必须是可重建的（从基础镜像 + 一个公开的构建脚本生成，谁都能自己跑一遍对比）；默认的网络策略只开模板声明的端口。
• 怎么收费。 可能是 Unraid 那样的系统授权，模板免费；也可能是商业模板分成。还没定，也不急着定。
• Windows 应用。 很多小办公室的软件只有 Windows 版。技术上同一套机制能用（keelOS 上 Windows XP 到 11 都能跑），但授权不允许分发装好的镜像，只能分发"把用户自己的 ISO 自动装完"的模板。

市场空间在哪：家用和小办公室今天在两个极端之间没有选择——要么全上云，每月付钱、数据在别人手里；要么自己装，靠一个懂的人，他走了就没人敢升级。中间那层"一台自己的机器，装和升级像手机装 app"，容器商店已经证明有人要（Unraid、CasaOS、群晖的套件中心），但它们都停在容器。虚拟机版本的商店能装容器装不了的东西，而 keelOS 已经把虚拟机最让人嫌麻烦的两件事——主机升级要停机、内存不够分——去掉了。这就是为什么值得做。

← 文章 · 为什么选 keelOS