当我意识到普通LXC容器已经足够时，我不再过度复杂化我的家庭实验室

每隔几个月，我就会说服自己，再多加一层精巧的设计会让我的家庭实验室更容易管理。我会测试一种不同的部署方式，自动化另一项维护任务，或者迁移某个服务，因为新的安排在纸面上看起来更整洁。有时候这确实有帮助。但其他时候，我最终只能盯着Proxmox里一个朴素的Linux容器发呆，纳闷自己为什么要花一下午去改进一个本来跑得好好的、没出过毛病的东西。LXC容器并不是我这套系统里最新或最有趣的部分，但它们一直是我的首选，因为我能快速理解它们，不用层层翻找就能修好它们，然后就不用再操心了。

普通容器让普通服务安安分分地做个普通服务

大多数家庭实验室服务不需要复杂的编排

我家庭实验室里的很多服务都只做一件事，也不想变成什么大工程。Pi-hole过滤DNS请求，而Uptime Kuma检查网络其他部分是否还在正常运行。它们就安安静静待在那儿，干自己的活儿，通常只有在有更新可用或别的地方出问题时才会引起我的注意。这些服务不需要复杂的部署流程。它们需要一个稳定的操作系统、一个网络连接、足够的存储空间，以及一种重启后能可靠恢复运行的方式。

LXC容器给了我这些，而不需要我换一套思路去理解这套设置。我在Proxmox中创建容器，安装软件，分配网络设置，然后就像对待一台小型Linux机器一样对待它。该在哪儿的东西都在哪儿。我不必记住某个配置文件是在应用程序内部、在映射目录内部，还是藏在另一个文件里、那个文件再告诉应用映射目录在哪。

几个月过去后，这一点更重要。我可能记得为什么安装某个服务，但并不总能记得设置它时所做的每一个决定。使用LXC，我可以打开一个shell并开始四处查看，而不必先重建部署过程。我发现，这往往比给一个可能永远不会从头重建的服务准备一份漂亮的可复用配置要有用得多。

LXC容器未必是每个应用的最佳选择。当一个服务只需要轻量级Linux环境、直接网络访问和简单维护时，用它们才最合适。围绕官方Docker镜像或几个相互连接的服务构建的应用程序，用Docker Compose来管理可能还是更省事。

LXC 自然地融入我管理 Proxmox 的方式

Proxmox 界面将日常维护集中在一处

在我的配置中，LXC 最大的优势并不是节省内存，尽管省内存也是好事。真正的优势在于，容器就住在我管理虚拟机、备份、存储和集群其他部分所用的那个 Proxmox 界面里。我可以查看某个服务是否在运行、检查它占用了多少内存，并打开控制台，而无需切换到另一个仪表板。这听起来好像没什么大不了，但等实验室里的服务多到一定程度，每多一个界面就多一个你会忘记去看的地方。

只要我不把每个服务都搞成一个基础设施大工程，我的家庭实验室就跑得更顺。

故障排查也更加直接。如果某个容器在更新后停止响应，我知道从哪里开始，因为容器就在那儿，跟其他东西放在一起。我可以检查它的资源、确认网络配置、重启它，或者打开控制台从客户机内部检查服务。不用花太多时间去想到底是哪一层出的问题。

备份也遵循同样的模式。Proxmox 可以将 LXC 容器纳入我已经依赖的定时任务中，所以不用给每个小服务单独搞一套备份流程。我仍然需要知道重要数据存放在哪里，而且没测试过的备份也就是纸上谈兵，看着安心而已。即便如此，把整个容器都备份下来，等于给自己留了一条好找、以后也好跟自己交代的恢复路子。

Docker 在处理某些工作负载时依然更清爽

应用套件受益于容器提供的打包方式

Docker 在我家里的实验环境中占有一席之地。许多项目发布官方镜像、提供 Compose 示例，并明确期望用户以这种方式部署软件。忽视这一点可能会把简单的安装变成白白多出一堆手动操作。当应用的开发者已经打包好依赖并记录了预期路径时，我更愿意利用这些成果，而不是自己从头把同样的东西拼一遍。

我的媒体服务是最明显的例子。Jellyfin 和我的各种媒体库管理工具用 Docker 容器来跑很合适，因为它们的端口、存储路径和依赖关系可以在一个地方定义。更新镜像通常比改手动安装更省事，后者往往会在之后发现某个依赖包底层悄悄变了。当多个服务属于同一个更大的套件时，Compose 也让我一眼看清整体情况。

Docker 对于短期测试也很方便。我可以启动某个东西，把它指向临时存储，判断它是否有用，然后删掉它，不会留下太多残留。一个全新的 LXC 容器也能完成同样的工作，但它要更多配置步骤，并且会给我留下另一个需要命名、配置并最终清理的容器实例。对于一次性实验和已经围绕容器镜像设计的应用，Docker 通常是最省心的选择。

抽象越多，需要排查的地方可能也越多

当存储和网络变得令人困惑时，便利性就会消退

麻烦就出在我只是因为有个现成镜像就用 Docker。一个基本的服务可能突然牵扯到绑定挂载、内部路径、桥接网络、转发端口以及散落在 Compose 文件里的环境变量。熟悉了部署之后，这些其实都不算难。恼人的是当我几个月后回来时，不得不回忆应用怎么看到主机、主机怎么看到应用，以及到底哪个路径才是真的。

存储一直是最耗我时间的地方。Docker 会让应用程序的文件看起来像藏起来了一样，因为容器内显示的路径可能与宿主机上的路径几乎没有相似之处。当应用程序无法读取目录或写入配置文件时，我必须先把两个方向的映射关系都捋一遍，才能轮到查权限问题。这种隔离可能很有用，但并非没有代价。

网络同样可能很绕。LXC 容器可以在我的网络上拥有自己的地址，这样识别和访问起来都方便。Docker 服务可能共享宿主机的地址、暴露多个端口中的一个，或者挂在一个我建完就再也没管过的内部网络上。这些选择确实很强大，但一旦有什么东西不响应了，一个小错误就有更多地方可以藏。

更简单的基础设施让我需要记住的东西更少

可预测的维护比令人印象深刻的部署方法更重要

这就是为什么我不断将某些工作负载迁回普通的 LXC 容器。我并不是要抛弃 Docker、虚拟机或者以后出现的什么新技术。我只是不想在那些工具解决不了实际问题的地方硬用它们。当一个服务只需要一个适度的 Linux 环境和网络上稳定的位置时，用 LXC 通常就能搞定，而且不用记那么多东西。

随着我的实验环境越搭越大，这种差异变得更加明显。每种部署方式都自带一套命令、更新习惯、存储布局和故障模式。我可以把所有这些都记录下来，但文档并不能让复杂性消失。它只是让我以后出问题时更容易找到头绪。

LXC 还让我做日常维护时没那么犹豫了。当我知道可以打开容器的 shell、检查其软件包，并且在搞砸时还能回退到 Proxmox 备份时，我就更敢去更新容器了。而对于一个我平时很少动的环境，我更可能推迟更新，因为我不想打乱那一堆挂载、变量和网络配置。对于一个本应平淡无奇的服务来说，这买卖不划算。

一个好的家庭实验室不需要一个完美的平台

我不认为家庭实验室里的每个服务都应该遵循一种部署理念。Docker 非常适合封装好的应用及相关技术栈，而当我需要更强的隔离或不同的操作系统时，虚拟机还是派得上用场的。普通的 LXC 容器正好填补了中间那一大块，很多小型服务其实就该放在这里。它们轻量、易于备份，而且我对它们足够熟悉，排查故障时不用先回想自己当初到底想搞什么花样。

回归 LXC 并不是在否定其他工具。这是想把复杂性花在真正值得的地方。当我不把每个服务都搞成一个基建项目时，我的家庭实验室反而跑得更好。对于那些只需要安安静静跑着、有备份、自己还能看明白的系统来说，一个普通容器通常就够了。