我用原生 Linux 容器替换了 Docker Desktop，从此再也没有回头

Docker Desktop 无疑很优雅。干净的界面、一键管理以及对复杂性的抽象使其对初学者非常友好，但这种抽象是有代价的。

在 Linux 上运行 Docker Desktop 几乎没有意义，因为 Docker Desktop 本身会启动一个隐藏的 Linux 虚拟机来运行。因此，你的容器并不是真正在你的机器上运行，而是在虚拟机中运行。那额外的一层不断消耗资源，使得故障排除变得非常困难，这就是为什么我决定转向原生 Linux 容器并且再也没有回头的原因。

Incus 不仅仅是“另一个 Docker 替代品”

它来自不同的容器传统

大多数 Docker 替代品都试图模仿 Docker。Podman 保持了熟悉的镜像和命令模型，nerdctl 为 containerd 提供了类似 Docker 的接口，而 Rancher Desktop 及类似工具将本地 Kubernetes 或容器运行时封装成更易于使用的形式。这些都是有用的工具，但它们仍然主要存在于应用容器世界中。

Incus 来自不同的血统。它是 LXD 风格系统容器模型的社区延续，这意味着它是围绕管理完整的 Linux 环境而构建的，而不仅仅是单进程的应用镜像。一个 Incus 容器可能感觉像一个轻量级的虚拟机。它有 init 系统、网络、存储、配置文件、快照和持久化身份。你可以通过 SSH 登录，安装软件包，运行服务，并将其当作一台小型机器来使用。

但很长一段时间，我不得不使用 Docker 来处理 OCI 应用镜像，使用 Incus 来处理系统容器和虚拟机，但后来 Incus 开始支持 OCI 容器，现在我可以使用它运行大多数容器。

OCI 支持改变了局面

现在你可以在 Incus 上运行 Docker 镜像

OCI 支持是使 Incus 作为 Docker Desktop 替代品变得更加有趣的部分。Docker 推广了这一工作流程，但镜像格式和注册表生态系统不再与 Docker Desktop 体验绑定。人们所说的“大部分 Docker 镜像”实际上是通过注册表分发的 OCI 风格镜像。

有了 Incus OCI 支持，我可以使用来自 Docker Hub 等注册表的镜像来拉取并运行应用容器。这意味着实际的差距变小了。当我需要持久化环境时，我可以运行一个普通的 Linux 系统容器，而当我只需要打包好的服务时，我可以运行一个 OCI 应用容器。

这是让我对 Incus 有所理解的转变，因为我的本地基础设施可以容纳两种类型的容器。当应用镜像已经是合适的单位时，我更喜欢 OCI 容器。这意味着 Nginx、Caddy、Redis、小型 web 应用、导出器、测试服务和预打包工具都可以作为 OCI 容器运行。开发机器、构建环境或服务主机可以作为系统容器运行。在需要单独内核或更强隔离边界的情况下，虚拟机仍然可用。

我不会说 Incus 是完美的一对一 Docker Compose 替代品，因为 Compose 在描述多容器应用堆栈方面仍然非常出色。好消息是，Incus 并不是试图以不同的标志成为 Compose。它更像是一个本地私有云，支持多种实例类型，这是一种不同的模型，需要一些适应，但好处是这种适应很快带来回报。

网页用户界面让 Incus 感觉就像本地云

它提供了可见性，而不会将所有内容都变成仪表板产品

Incus 命令行足够强大，你可以从终端管理所有内容。这就是我开始大部分日常工作流程的方式。有一段时间，我认为我不需要其他任何东西。

然后我开始使用网页界面。网页界面改变了 Incus 的使用体验。它可以在一个地方显示容器、虚拟机、网络、存储卷、配置文件和镜像。你可以查看正在运行的内容、检查配置、打开控制台、查看快照，并且无需运行五条命令然后在脑中拼凑输出就能理解环境的结构。此外，你只需几次点击就可以进行 GPU 直通。

Web 用户界面不能替代对系统的理解，但它非常擅长使系统可检查。Incus 给了我这一点，同时没有把 GUI 当作架构的中心。

我的日常工作流程变得更简单了

主机感觉更干净

在将更多工作迁移到 Incus 后，我注意到的第一件事是我的主机感觉干净了许多。我可以停止直接在笔记本上安装各种版本的数据库、语言运行时、消息队列和构建依赖。当然，这在 Docker 中也已经是如此，但 Incus 让长时间运行的开发环境感觉更自然。

例如，如果我想要一个基于 Debian 的开发环境，我不需要为了模拟一个普通系统而编写 Dockerfile。我可以启动一个 Debian 容器，安装我需要的东西，做一个快照，并保留它。如果我弄坏了什么，我就恢复快照。如果我想要第二个副本，我就克隆它。如果我需要在另一个发行版上测试，我就启动另一个镜像。

这对于基础设施编写和实验特别有用。当我测试 systemd 行为、网络工具、包管理器差异或服务配置时，系统容器比单进程的 Docker 容器更有意义。我希望环境的行为像一台小型 Linux 机器，因为文章或实验通常就是关于这个的。Docker 可以被推向那个角色，但总感觉有些不对劲。

人际网络不那么神秘

它仍然是在联网，所以它仍然可以惩罚你

容器网络是许多“简单”工具变得不再简单的地方。Docker Desktop 隐藏了很多这些细节，尤其是在非 Linux 平台上。在 Linux 上，这些魔法不那么必要，但习惯依然存在。你会发布端口、检查桥接、想知道使用的是哪个 DNS 路径，最终可能会阅读 iptables 或 nftables 规则，同时后悔之前的乐观态度。

Incus 网络感觉更直观，因为你可以创建托管桥接、将实例附加到网络、通过配置文件分配设备、使用代理设备，并以更接近常规 Linux 管理的方式检查配置。它并没有减少理解网络的必要性，这本身没有好处（我甚至会说“应该”），但它使模型更易于理解，因为容器被视为带有设备的托管实例，而不仅仅是具有端口映射的进程。

我为什么不回去？

我留下来和 Incus 在一起的原因不是意识形态。我不关心用一个徽标替换另一个徽标。我关心的是拥有一个快速、可检查、可脚本化且接近 Linux 的本地环境。Incus 在我需要小型 Linux 机器时提供系统容器，而在容器不够时提供虚拟机。这种组合很难被超越。

Docker Desktop 对许多人仍然有用，尤其是在 macOS 和 Windows 上，因为 Linux 容器无论如何都必须通过虚拟机。不过，在 Linux 上，我已经看不到在日常工作流程中携带那一额外层的意义了。原生 Linux 容器感觉更直接，而 Incus 让它们易于管理，同时不会让它们过于简单化。