> For the complete documentation index, see [llms.txt](https://freebsd-journal-cn.bsdcn.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://freebsd-journal-cn.bsdcn.org/2026040506-gai-jin-ruan-jian-zhi-liang/packaging-cloudinit.md). # 打包、CloudInit，以及重温“好的、坏的和丑陋的” * 原文：[Packaging, CloudInit, and Revisiting “The Good, The Bad, and The Ugly”](https://freebsdfoundation.org/our-work/journal/browser-based-edition/improving-software-quality/packaging-cloudinit-and-revisiting-the-good-the-bad-and-the-ugly/) * 作者：**Tom Jones** ## 专访 Baptiste Daroussin **Tom Jones：** 你从 1998 年起就在用 FreeBSD，2010 年成为提交者。跟你当年在桌面上开始用它的时候相比，这个项目有哪些变化？ **Baptiste Daroussin：** 我觉得变化不大，不过项目里有很多人拧着我的胳膊，把我拉成了提交者。1998 年我从一台笔记本开始。我试的第一件事是从 Ports 构建 OpenOffice。我记不清当时它已经进了 Ports，还是很快就要进去。有人跟我说：“嘿，你要是疯到想在 FreeBSD 上把 OpenOffice 跑起来，就该加入这个项目。”十年后我确实加入了。 2010 年，我记不清是谁邀请我去 BSDCan 做演讲。那时我已经在做 pkgng。我必须把这项工作在 BSDCan 上讲出来，就这样直接参与到项目里。 **TJ：** 那么 pkg 最初进入项目时，叫 pkgng？ **BAPT：** 对，我最初管它叫 pkgng。我抱怨当时没有任何东西能直接当作二进制软件包使用，而我的一位朋友（Emile Heitor ）正在为 NetBSD 做 pkgin。我先把他那个工具移植到 FreeBSD，能用。很快我就撞上了 pkgin 之下那些软件包工具的限制。 于是我和 Julien Laffaye（他当时已经是提交者）开始做自己的项目。最初只是我俩私下试试，看从零做一套东西到底有多复杂。与此同时，我们不断给基本系统里的包安装工具打补丁，推动改进。我很快发现，这件事并没有多难。最后我做出了一套能用的东西，发邮件告诉他们：“嘿，它跑起来了。”他们因此邀请我去加拿大讲讲我的成果，我就加入了项目。 **TJ：** 那时你想到 15 年后自己还在做 pkg 吗？ **BAPT：** 显然没想到。pkg 的搭档 Poudriere 从最开始就在，因为我需要点东西来快速测试 pkg、快速构建软件包，好验证 pkg 本身。现在它由 Bryan Drewery 照看。我很高兴自己不用同时管这两样，但我还在做 pkg，它还是挺有意思的。事情多得做不完。我当初设想的，到现在连一半都没做完。 **TJ：** 也就是说，还有很多活要干？ **BAPT：** 是的。回头看历史，大约十年前，我在 BSDCan 2015 上讲过如何让 PkgBase 成为现实。而我们直到现在才真正动手。 我有很多针对软件包的安全计划正在慢慢落地，比如默认禁止任何随机的 root 脚本运行，这样一切都能被审查。现在所有脚本都是某个随机 Port 里的某个人放进去的，显然是“极其小心”（才怪）。这是我非常讨厌的一点。所以我们现在有了可以在同一个地方审查的触发器，也有了沙箱化的脚本。所有跑在 Lua 里的东西都在 Capsicum 之下沙箱化，这同样限制了你能做的事。我的长期目标是有一天让软件包里的任何脚本都无法以 root 身份运行。我不确定自己能否做到，但仍在朝这个方向努力。 **TJ：** 你觉得让更多人参与软件包开发的障碍是什么？ **BAPT：** 不知道。大概多少跟我有关。我们有八个人有合并权限，但没人愿意动手。这是高度复杂的软件，尽管乍看之下很简单：不过是在文件系统上解包 tar 而已，能出什么错？你不必把它做复杂。你也不必做完整套，只是一点小任务而已。 可它随后就变得非常复杂：如果你想支持升级，又想加入人们想要的灵活性，最终就会得到一个复杂的求解器；说实话，连我自己都看不懂它。我们为此用了 SAT 求解。那是 Vsevolod Stakhov（他也是 FreeBSD 提交者）在编程之夏期间做的。他大概至今比我更懂它，只是他已不再活跃于这个领域。 另一个问题是，这类软件需要清晰、长远的视角，而我极不擅长写路线图。有人想加入时，会担心自己改动的方向跟我心里的设想不符，这种担心会挡住他们贡献的脚步。不过我们的贡献者仍比其他子系统多，所以归根结底，我大概还没那么糟。 **TJ：** 你提到 PkgBase 是十年前的目标。你觉得软件包工具链是主要障碍，还是说走向真正的软件包另有其他因素？ **BAPT：** 我认为是其他因素。现在回头看，pkg 的待办清单确实很长，但当时没人有动力去做。这是个先有鸡还是先有蛋的问题。没人愿意去做 PkgBase 系统本身。项目里有过一阵子想做的意愿，但没人愿意投入精力把它做完。 真正的动力出现在一年半以前。是我投入精力做出了最初的软件包和最初的框架，结果什么也没发生。后来 OCI 那批人贡献了一点动力，他们非常想在 FreeBSD 基础上做极小的 OCI 镜像，于是又推了一把。最近，Ed Maste、Kyle Evans 和 Mark Johnston 做了很多推动，再往后 Lexi 也做了大量工作。 我老是忘掉这件事：我在源码树里搭起构建软件包的最初框架之后，manu@ 做了海量工作，因为那时他有动力。起初他为此拿到了报酬，这对起步很有帮助。他有动力去构建一些需要 PkgBase 的设备。他现在的公司也想从另一套基本系统打包方案迁移到这套。 基本系统打包之所以复杂，是因为我们得让整个项目走上同一条路线。过去还有过更多尝试。在 pkg 之前，我记得有家公司在做基本系统打包。他们在某处做过演讲，用的还是旧的包安装工具。后来我在 2015 年开始谈这件事时，一家俄罗斯公司把这家公司的成果接过去，改成了当时的 pkgng。接着 iX Systems 提出了一种机制，严格来说并不是真正的软件包，而是把现有的集合变成包——也就是 FreeBSD 基本系统、FreeBSD 内核源码等等。粒度细了一些，但也细不到哪去。 **TJ：** 你觉得这里有没有给 FreeBSD 的项目教训——我们该如何对待这类牵动全系统的大改动？ **BAPT：** 我想过这个问题，但问题在于我们大多是志愿者。如果某家公司不是因为有巨大需求而从头到尾推动这项工作，并给参与者足够的时间，那它就行不通。我们就是这样一个项目。iX 是这样，那家俄罗斯公司也一样。他们做出了对自己可用的东西，却始终没有足够时间完成它。 我理解这一点；我不是要怪他们，他们在工作时间里必须转去做别的事。所以，花时间把所有关联和流程都妥当整合，实在太难。通常只有一个英雄能把它推到终点。我很高兴 PkgBase 没有落到那个下场。 **TJ：** 软件就是这样。 **BAPT：** 是啊，是啊。 **TJ：** 有很多东西对公司的出货产品来说够好了，对 FreeBSD 来说却不够好。 **BAPT：** 一点没错。 **TJ：** 有时感觉我们的标准高到代码进不来。 **BAPT：** 我不确定标准是不是太高。人们总这么说，但我看过一些开源项目，它们往往比我们更难贡献。比如跟 Linux 内核或其他操作系统打交道，代码往往更难进去。做那些操作系统的公司多得多。可你看 Linux，很多公司什么都没往上游提，因为门槛太高，但最终贡献量依然很大。 门槛本身没问题；问题是，你怎么说服人们去做超出他们最初设想范围的事情？比如：是的，这对服务器有好处，但想想桌面用户会怎样……“我不在乎桌面用户。我该为此付员工工资吗？”这就是我们面临的问题。我待过的每家公司，无论是哪个操作系统、哪个开源项目，都有这个毛病。 问题始终一样：就我与那些贡献过代码的公司打交道的经验来说，只要你在项目里认识能帮你的人，把东西送进 FreeBSD 比其他领域更容易。问题在于人太少，想找到能带你的人并不容易。 **TJ：** 项目成员有没有办法让自己对企业更方便接触？ **BAPT：** 对公司来说这是个热门话题，因为基本上到处是 Linux，人们期望从它那里获得所有技术，所以我不知道你能怎么改变。如果谈的是贡献，那该改变的不是项目成员是否更容易被企业接触。当然，那样也有用，但更应该改变的是公司的文化。 就像我说的，我合作过的每家公司，要么有一个英雄式的人物把一切都往上游送，要么就是坐拥一大堆补丁，也许某天会贡献出去。我现在在 OVHcloud 做的就是这件事：确保哪怕一开始看起来更难，也先跟社区一起做，而不是堆自家补丁。一旦习惯了、在社区里参与得足够深，事情就会变得更容易、更简单。另一个好处是，升级不再是一场噩梦——不必再变基并重新测试你攒下的所有补丁。 在我之前待过的一家公司，因为我们跟某个开源项目（不是 FreeBSD）建立了关系，得以进入许多补丁的评审路径，或者至少能及早得到通知，从而对它们发表意见。虽然团队依然很小，但正因为如此，每次大版本升级都能基本无缝，心里踏实。 这很容易，只因为我们身处社区；反过来说，我们也因此不得不做很多事。现在新版本发布前，我们得把所有补丁变基。而它偏偏在你忙着路线图里某个重要项目时到来，你根本没空理会。于是你往后拖，半年后就得迈一大步。所以可以说项目变得更容易接触了，但这取决于对面那批人的心态。 **TJ：** 你提到了 OVH，这正好可以引出 FreeBSD 15 里另一个工具：你的 CloudInit 工具 NuageInit。 **BAPT：** 对，它在 14 里就有了，从 14.3 开始比较好用。我加入 OVHcloud 时，那里没有可用的 FreeBSD 镜像，这让我很难受，因为以前是有的，而我自己就是客户。据我所知，过去公司里总有个 FreeBSD 的人来处理这件事，但除了有客户提出需求，我们实在没时间维护这些镜像。 我发现 FreeBSD 提供的镜像几乎能在裸机上开箱即用，靠的是“自带镜像”功能——基本上你只要把 raw 镜像写到裸机磁盘上，然后启动。我还发现他们为裸机的“自带镜像”做的一件事就是使用 CloudInit。 他们实现 CloudInit 的方式，不是虚拟机或云环境里那种精致的网络手段。他们用的是一个机制：给机器挂一块磁盘，启动时磁盘里就带着数据。所以本质上就是把 CloudInit 配置放在磁盘上。看到这个之后，我想到：如果你想开箱即用地安装 FreeBSD，而不借助 mfsBSD 之类需要 qemu 并覆盖磁盘的手法，那就得有一个能用的 CloudInit 镜像。 我必须有一个能用的 CloudInit 镜像。我看过官方的 CloudInit，完全不喜欢，因为它太庞大了。它对 FreeBSD 的支持很脆弱，我不怪他们——要把 FreeBSD 专有的东西塞进去得花很多功夫。它太大，因为它需要 Python 和相关工具，而基本系统里没有 Python。我想要能在基本系统里运行的东西。做出一个足以引导机器的实现，应该不难。NuageInit 就是这么写的，我只实现了我们裸机使用所需的最低限度。 后来我发现有客户希望在我们的公有云上使用原生镜像。我看了一下那是什么：它是一个 OpenStack。所以它也遵循 CloudInit，只是默认从网络而不是从磁盘获取配置。它也能从磁盘工作，但用户得自己找到那个选项，而且默认不开。我给 NuageInit 加上了从网络获取配置的能力，于是我们提供了这个镜像。我想我们从六月起就在公有云上提供原生镜像了。 接着 VPS 团队来找我，希望向 VPS 客户提供 FreeBSD。他们自己做完了工作，做了大量测试，还提供了很多 bug 修复（由我提交入库）。 看来大家还挺喜欢 NuageInit，因为现在有很多人给它加功能。FreeBSD 15.0 里的版本，我不会说它完整——能加的东西还有很多——但已经足够完善，几乎到处都能用。任何基于 OpenStack 的环境它都能跑。 **TJ：** 你在 2018 年的 EuroBSDCon 上讲过“[FreeBSD 项目：好的、坏的和丑陋的](https://papers.freebsd.org/2018/bsdcan/daroussin-introducing_freebsd_in_new_environment/)”。对照其中的“坏”和“丑陋”，你觉得我们现在做得怎么样？ **BAPT：** 我觉得我们在变好。网络和 Wi-Fi 曾经很难啃。即便我不同意所采取的方法，也得承认它现在运行良好，而且我正在用它。你做了另一条路线的方案，它也同样能用。这又把我们带回了曾经的位置，好坏都算上。同一个问题我们有两套方案，就像我们有三个防火墙一样。这大概也是我们喜欢 FreeBSD 的部分原因。你知道，这让它显得有人情味：大家口味不同。有些地方我们无法就方案达成一致。那好，我们就有两套方案，而且有人愿意维护。没关系，这让它像个家庭。 我觉得蓝牙依然头疼。能用，但还是头疼。回头看我当年列为“丑陋”的清单：默认 CSH，这个我处理了。我有 CSH，但我处理了。现在默认是 sh。防火墙和邮件，我想我们搞定了。Vi 后来升级了。所以还算可以。 PXE 启动仍然是个问题，尽管我们改善了很多。我记得当时在 Gandi 的工作场景。我们需要部署一些开发机。至于存储设备，我们把所有 Linux 机器都用 PXE 启动，而 FreeBSD 在这件事上很痛苦。我们没法用 iPXE，只能绕道 MFS 镜像之类的东西，非常麻烦；而在 Linux 上就很容易。好在十年之后，Warner 在几个月前终于修好了：内核支持 iPXE Memdisk，于是我们可以直接从 iPXE 启动一个裸 FreeBSD 镜像。我在 OVH 也这么用，因为你可以提供自己的 iPXE 脚本来启动裸机。这很棒。我们花了十年才修好，但没关系。 说到“坏”的一面，我提过缺少开箱即用的云镜像。这个问题已经解决，现在我们有了。我们在本地 FreeBSD 更新镜像方面仍有问题，这大概能靠转向 PkgBase 解决，最新的基础设施讨论帖里也谈到了。我还不知道发布工程团队会怎么做，但一切都会符合 CDN 规范。只要符合 CDN 规范，我们就能提供一套在本地做镜像的机制。对拥有大量 FreeBSD 的公司来说，每次更新都能从自家镜像获取，是件令人高兴的事。 我们没有 bhyve 前端。今年有一些 GSoC 代码在为 QEMU 添加 bhyve 后端。所以，一个与 QEMU 对齐的前端对 bhyve 会很有用。我还提过 bhyve 缺失的另一项功能：实时迁移。我们现在有了直通，但仍没有实时迁移。而这正是 bhyve 在企业里的主要问题。如果你是提供虚拟机的云公司，这事很关键，因为它把硬件问题抽象掉了。你需要在客户察觉不到的情况下迁移机器。所以，没有它，笔记本上无所谓，在企业里就没法用。 我还提过缺少动态 CPU，这一点我们仍然没有。这有点意思，因为我觉得当年那个用例放到今天已经不太成立了。不过当时在 Gandi，我们提供一些云服务，可以在不重启虚拟机的情况下动态增加 CPU 核心。这在 Linux 上可行，在 FreeBSD 上不行，必须重启。但我不确定今天人们还这样使用虚拟机。 NFS 被我列为“丑陋”。当时我所在的公司被它折腾得很惨，但（就我们那种负载而言）它在其他操作系统上同样丑陋。pmcstat 的界面依然丑陋，但能用。Sanitizer 在改进，但还不够好。启动加载器里的 Forth，我们修好了。旧的 GDB 也修好了。所以，“丑陋”和“坏”的部分大多已经解决。 **TJ：** 对 Linux 来说，有一套清晰的工作流：生成补丁、干活、拿脚本跑一遍，然后照着建议改。而我们提交补丁的方式有无数种，检查的地方也有无数个。几乎成了一种心照不宣的处境：你得找到赞助人，找到愿意帮你的人；而在联系赞助人之前，你根本没办法知道自己的东西有没有达到最低质量标准。源码管理团队将来也许能处理这件事。 **BAPT：** 他们大概能做到。这需要跟 Linux 的工作方式良好配合，同时保留我们那种家庭式的做法，而不是高度结构化的流程。这正是我当初加入 FreeBSD 的原因，也是我在 Linux 上工作、为 Linux 社区贡献的原因。它很乱，但我们可以很轻松地跟任何人交谈，感觉像个家庭。我加入这个项目，说到底是因为我发现这里更容易把事情做成。 我可以犯错，没关系。我知道有些非常有才华的人能审阅这些工作，我可以直接找他们。所以，当你的第一个补丁就有名人过来参与讨论时，那种感觉令人兴奋。我曾为一家公司做贡献，我们在 Linux 上贡献了某个子系统的相当一部分。那大概更专业，但更痛苦，也更无趣。 **TJ：** 我发现从 Linux 那边看，存在一些不成文的利益关系；如果某个关键位置上的人不想要某样东西，你永远等不到答复。也许每个开源项目或多或少都有这种情况。 **BAPT：** 一点没错。 **TJ：** 在你的 EuroBSDCon 演讲里，你问过那些酷炫的周边在哪——“我们够酷了吗？” **BAPT：** 我觉得我们还不够酷。很少有新人在进入公司时说：“哦，你们用 Linux，但我一直在用 FreeBSD。” 我们需要说服的不是公司改用 FreeBSD，而是学生、年轻人、系统管理员，以及一般的开发者。要让他们看到在 FreeBSD 上工作很酷，等他们进入公司时会带着这种印象：“用 FreeBSD 做这件事很容易。”如果确实如此，公司自然会跟上。这件事我们完全没做好。我当学生时我们非常酷：笔记本上装 FreeBSD 比装 Linux 酷得多。用 Linux 时，别人会说“嘿，你挺有意思”，但笔记本上跑着任何 BSD，你就是硬核玩家。 **TJ：** 你觉得第一步该做什么？ **BAPT：** 另外，当年的 FreeBSD 在大学里影响很大。校园里通常总有系统管理员，正是他们在孩子们的脑子里灌输“FreeBSD 很酷”的想法。我们丢掉了这个位置，所以这里可能也有先有鸡还是先有蛋的问题。我真的不知道。 在 FreeBSD 里，我们有一件事做得很好，其他 BSD 也许会因此批评我们，那就是我们善于追赶 Linux。Linux 做出好东西时，我们总能在某个时候提供兼容性，或者赶上足够相似的实现，从而不在这场游戏里落后。但有一件事我们没做到：讲清楚如何用 FreeBSD 的方式做事。你怎么用 FreeBSD 的方式去做一件事，而不是照搬 Linux 的做法？ 这很有意思，因为在我合作过的所有公司里，每次我都部署了 FreeBSD。而且大多数时候，我总能找到一套比 Linux 上的对应方案更容易实现、更容易维护的系统。这一点我们真该大力宣传、沟通，并通过教程之类的方式展示出来，因为我们在“基于 Linux 做设备”方面确实很强。 看看 Linux 上构建嵌入式镜像的框架，比如 Buildroot。这类框架有两三个。拿它们跟用 Poudriere 镜像做同样的事情比一比：在 Buildroot 里做镜像，比用 Poudriere 镜像难上十倍。我当时就是这么给公司提供镜像的。 **TJ：** 你觉得我们缺的是培训材料，还是说这是全方位的问题？ **BAPT：** 我认为是全方位的问题。我们没有好好沟通的习惯。我看过互联网上大多数教程，发现人们总在说：“嘿，我在 Linux 上见过这么做，你看，我在 FreeBSD 上也能这么做。”这很好，可如果 Linux 也能做同样的事，我为什么要用 FreeBSD？要知道我们与许多系统不相上下、能做同样的事，这一点很重要，别误会我的意思。但我们还应该讲：“这就是我如何在十分钟内构建一个基于 FreeBSD 的镜像。” 我们不肯花时间去沟通。 我写过一个 MAC 内核模块，之后《FreeBSD 期刊》联系我，说：“嘿，写篇文章吧，讲讲你在做什么、有多复杂，会很有价值。”我说：“好啊，我想写。”可我没时间——我没去挤时间。这也是我现在接下这次访谈的原因。如果现在不做，一年半以后也永远不会做。问题就在这里。 **TJ：** 在项目层面，我们在很多方面落后于业界的最新水平。我们有一些 CI，但没有兼容 GitHub Actions 的流水线。我们零散地有一些。我还想知道我们是不是也缺别的东西，比如增长黑客，以及做开发者关系、把 FreeBSD 作为系统管理员平台来推销的人。 **BAPT：** 我同意。我个人在维护 SourceHut 上的 CI，已经一年没更新了，而且我自己付 SourceHut 订阅费，就为了在 FreeBSD 上跑 CI。所以还是那句话：如果想让这件事可行、变简单，我们就得更好地传播“如何轻松做到”的知识。我搭它大概只花了几个小时。我有一套基于 PkgBase 的简易做法，能让 CI 开箱即用，而不是像别处那样写复杂的脚本。我们有知识，却没有分享出去。 **TJ：** 感谢你抽时间，我不想占你太多时间。还有什么我们没谈到、你想补充的吗？ **BAPT：** 很高兴你提起我当年做的“好的、坏的和丑陋的”，因为我能看到我们已经修掉了 99% 的“坏”和“丑陋”。所以这个项目的状况比我有时以为的要好，这很不错。 **TJ：** 也许三年后你该再做一次那个演讲，梳理一下我们的进展。通过播客和会议，我做了很多布道工作。不过我不想跟任何人争论。 **BAPT：** 这就是我不想把人“转化”成 FreeBSD 用户的原因。我希望他们为了 FreeBSD 本身而来，明白自己要去哪里。我不希望他们把 Linux 的用法照搬到 FreeBSD 上，因为我觉得那不好。我希望他们理解其中的差异、FreeBSD 能提供什么，以及在很多情况下为什么它比他们手上的东西更有用。有些情况下如果并非如此，那也没关系。但我们确实需要让人们知道，FreeBSD 的价值在于它的灵活性。 *** **Baptiste Daroussin** 是 OVHcloud 的 Unix 系统工程师，自 2010 年起是 FreeBSD 开发者。 **Tom Jones** 是 FreeBSD 提交者，热衷于让网络栈保持高速。 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://freebsd-journal-cn.bsdcn.org/2026040506-gai-jin-ruan-jian-zhi-liang/packaging-cloudinit.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.