为什么我的家庭服务器选择 FreeBSD
Aumont.fr
为什么我的家庭服务器选择 FreeBSD
Page date: "2024-11-19T00:00:00.000Z" Page dateModified: Is dateModified defined: false 7 min read. 19 Nov 2024
Linux 作为桌面系统相当不错：#
在 2024 年，GNU/Linux 作为一个桌面环境已经相当出色，你几乎可以毫无问题地运行任何东西。即使你是一个游戏玩家，也已经取得了巨大的进步，这尤其要感谢 Valve/Steam。
我每天在我的笔记本电脑上使用 EndeavourOS，它是一个很棒的发行版。
一切都运行良好。
就像 Windows 用户一样，我并不关心某个特定服务是如何启动的，内存是如何管理的等等。我只想安装/删除程序，使用 Wifi、蓝牙设备、Web 应用程序、各种远程控制工具和一些 markdown / txt 编辑器，并能够访问 shell。
作为笔记本电脑用户，其他的对我来说并不重要。
所以是的，Linux 绝对是一个很棒的桌面操作系统。
但作为服务器操作系统却一团糟：#
像其他系统管理员一样，我的公司/客户在需要使用 Linux 时会使用 RHEL 或 Centos。老实说，经过几十年的管理、故障排除和解决问题，我仍然不明白这个工厂是如何运作的。
而且我已经阅读了大量的 RedHat 文档 / KB。
warning SystemD.TLDR：主要问题是 SYSTEMD，次要问题是抽象层的堆叠，比如 docker / kubersomething，大多数时候的使用原因不明，“只是因为它是现代的”。
不要保持简单，让我们做一些复杂的事情：#
看起来这是一种新的口头禅！新的“微服务”生活方式产生了大量的日志，当你在生产中遇到问题时，这些日志根本无法调试。
另一点：systemD 管理的一切（即整个系统）使事情变得复杂。
像设备挂载这样简单的事情，你可能认为应该完全由 /etc/fstab 处理，但实际上可以被 systemd 选项绕过。
复杂的东西 = 高概率的失败 = 在生产中进行故障排除时遇到的复杂问题
如果你是 2024 年的后端/系统产品/负责人/开发人员，请记住这些话！
warning 提醒：换句话说：因此，整体系统可靠性是每个组件的个体可靠性的乘积。因此，系统中的组件越多（冗余除外），至少有一个组件发生故障的可能性就越大，从而降低整体系统可靠性。
以 GNU/Linux 日志管理这个简单系统为例：#
正如你所看到的，在 SystemD/Linux 上，日志管理相当简单。
当你的某个服务不再跟踪时，最简单的方法是重启所有东西 (journalct, syslog, rsyslog, syslog.socket ... 谁知道)。
此外，在过载的 systemd 上，journalctl 消耗一个核心 100% 的情况也很常见。祝你好运，试图缓解这种情况。
我也可以问你同样的问题，当你想处理 Debian 上的软件包时，应该使用哪个正确的工具？ apt，aptitude，apt-get？
我们也可以讨论网络配置，可以使用 nmcli 完成，也可以通过更改配置文件完成......这在桌面环境中并不重要。但是在服务器配置中，当 3 年后你必须重新安装机器时，这很重要。
是的，Debian... 😁 #
请不要跟我说 SystemD/Debian...
很久以前，像很多人一样，我是一个 Debian 的系统管理员家庭用户。我使用 “几乎” 是 RIP OpenVZ 的 paravirtualisation 解决方案来运行我的服务。当时，Docker 才刚刚开始出现。
它在 2.8 Kernel（Debian 8 或更早的版本）中得到了完美的支持，但由于某些原因，Debian 项目选择不将 OpenVZ 作为上游解决方案包含在下一个 Debian 版本中。继续使用 OpenVZ 的唯一方法是... 将其内核降级以继续利用可移植性？！！如果你想继续使用 OpenVZ，你必须使用 Devian，真是个笑话。
所以我必须重做我所有的“架构”，将我所有的服务重新部署到一个新的容器解决方案中？重写/测试备份脚本等等... 谢谢你，再见 Debian！
甚至无法进行滚动升级的专业发行版 (Rhel / Rocky)：#
对于一个专业的发行版来说，这可能是最大的笑话：如果你想从一个主分支跳到另一个主分支，你必须重新安装所有东西（或使用像 leap 这样的工具）。
是的，我知道，你可以用 Debian/Fedora/Arch（它们是滚动发行版）来做到这一点。
FreeBSD 😎 #
一切都很简单，一切都有文档记录，一切都很有意义。好吧，事情可能有点“老派”，并且使用旧的 Unix 方式来做事。
但这正是我们在生产中所喜欢/需要的：简单和稳定！
自从 9.x 版本发布以来，我就一直在我的个人服务器上运行 FreeBSD，到目前为止，一次又一次的升级都没有破坏性的变化！一切从一开始就运行良好。
当然，我已经多次更换了物理服务器，并且不得不处理灾难恢复的情况。每次，重启服务的操作都被证明是简单而有效的。
从灾难中恢复（宏观计划）：#
基本上你必须：
- 恢复你的
/home或/root - 恢复
/etc/rc.conf - 恢复你的防火墙配置
/etc/pf.conf - 恢复你所有在 jail 中运行的服务
Et voila.
优点：#
- 这可能是最重要的一点：FreeBSD 上的所有东西都很简单。
- 所有程序的配置文件都位于
/usr/local/etc中 - 内存/CPU 占用量最小
- 默认情况下，日志由 newsyslog 管理，而不是迷宫般的系统。
- Jails 非常强大，可以管理大量的服务，而且自 FreeBSD 6.x 以来就一直存在......这是一个 FreeBSD 的原生工具。有几个包装器 iocage/bastille/ezjail ... 但基本上这仍然是一样的：jail，你可以轻松地从一个包装器迁移到另一个。构建简单的网络设置或复杂的安全设置。在 jail 中挂载 NFS 共享...... 你不必在 lxd, lxc, docker, containerd 之间做出选择...
- 使用
Bhyve进行虚拟化非常出色且强大：后续会发布关于这个主题的文章。 - 整个系统配置都在
/etc/rc.conf中完成 - 可用的防火墙解决方案非常棒 (Packet Filter)。
- pkg 用于管理软件包，仅此而已。
- 当你运行操作系统的大版本升级时，你不必祈祷。
- 网络堆栈 快速而高效。
- ZFS 在 FreeBSD 上更高效（插入来源）。
缺点：#
- 可能需要几个不眠之夜才能让像蓝牙这样的东西工作......
- 你需要更具冒险精神才能运行完整的桌面环境（即使它可以工作！）。
- 管理事物的方式仍然有点 Unix 老派？但这最终是个问题吗？
FreeBSD 最大的问题：开发者只使用 Docker 部署开源软件的坏习惯 😈 #
在开源世界中有一种新的时尚。开发者认为 Docker 是新的事实标准，并且只建议使用 Docker 安装工具。大多数时候，他们不提供任何文档来以裸机方式安装他们的软件。
最好，他们提供一个 .rpm 或 .deb 包，用于在非 docker 操作系统上安装。但大多数时候，这是一个 docker file。
更糟糕的是，现代应用程序通常将运行代码所需的代码和数据库直接部署在 docker compose 文件中。
这些人什么时候认为运行 10 个不同的数据库与我托管 10 个应用程序相关？
幸运的是，FreeBSD 社区是坚定而有能力的，并且总是会尝试为 FreeBSD 创建一个包 😇
已识别的使用 docker 部署模式非常糟糕的软件：#
note 注意：如果列表增长，可能会将本章更改为专用页面。
- Immich：至少有一份文档可以部署在 TrueNas 上，但这只是一些截图，没有任何关于如何手动部署的信息（此外，这个应用程序还部署了 PostgreSQL ... 伙计，我已经有一个共享的 MariaDB 了，我只想将你的应用程序部署到我的数据库中，而不是引导其他大量的组件）： 在 FreeBSD 上部署的复杂程度：中等/困难（可能可以通过花费一些周末时间来完成）。
- BunkerWeb：这应该是一个强化过的 Nginx，在 Github 上 没有任何文档 可以从源代码部署/构建应用程序，使用 docker / kub / rpm / .deb 或什么都没有。 在 FreeBSD 上部署的复杂程度：困难，我试图读取 .deb 上的文件，这是一堆 Python 脚本，安装了许多 lua/rpm 模块...... 为什么部署一个带有 Lua 脚本的 Nginx 如此复杂？
- Silverbullet：天啊，我喜欢这个应用程序 😍 我每天都使用它作为我的笔记花园。我稍后可能会创建一个关于此应用程序的页面。我最近创建了一个 init 脚本来启动它，并且运行良好。在 FreeBSD 上部署的复杂程度：简单 列表待续...