Ubuntu在Windows 10上：Docker vs WSL

Question

我了解目前有两种不同的方式可以在Windows 10上运行Ubuntu：

1. 使用Windows子系统Linux（WSL）。 2. 在Windows 10上安装Docker，并使用一个带有Ubuntu的容器。

然而，我找不到一个易于理解的解释它们之间（特指应用程序方面）的区别，以及各自的优缺点。

我找到了一篇关于在WSL上使用Docker的帖子：通过（Windows Linux子系统）和Docker使用Ubuntu。 但是我说的是直接在Windows 10上使用它。所以我会感激任何关于这两种方式的信息。

- alvgom

---

我对其中任何一种都不是专家，无法写出一个答案，但我的选择是Docker。原因是Docker意味着虚拟化，所以事情应该只需要工作。另一方面，WSL充满了错误。它可以用于基准测试、娱乐和大部分开发；但如果你要部署一些严肃的东西，这不是你的选择，至少现在还不是。 - Hi-Angel

Answer 1

更新于2020/02/18以反映WSL2引入的更改

嗨！我是微软的产品经理，负责WSL和命令行。

WSL允许您在Windows上直接运行原生、未修改的Linux ELF-64二进制文件，并使您能够在Windows“主机”操作系统上运行您喜爱的Linux工具。

WSL1采用了一种方法，在NT内核顶部添加了一个与Linux系统调用兼容的层，允许Linux二进制文件在NT上运行，并与主机操作系统共享相同的底层文件系统、网络、进程列表等。

而即将发布的WSL2则在真正的Linux内核中以轻量级虚拟机的形式运行发行版的二进制文件，该虚拟机只分配应用程序所需的内存，并将释放的内存返回给主机操作系统。这提供了100%的Linux兼容性，使您的Linux工具能够以接近本机性能运行，并从主机获取所需的最小资源，确保您的计算机运行快速流畅。

在WSL2之前，可以在WSL1中运行Docker客户端，使用它来驱动在本地主机上运行的基于Hyper-V的Docker for Windows，或者管理远程Docker服务器。但由于许多技术原因，无法在WSL1上运行Docker Engine。

然而，在WSL2上您可以做同样的事情，但是如果您喜欢的话，您还可以在WSL上运行Docker引擎本身。这是Docker在Windows桌面上运行的首选和未来路径。

要了解更多关于WSL的信息，请查看这里的视频和文档：https://aka.ms/learnwsl

- Rich Turner

---

我认为这个答案是指WSL，WSL 2运行一个定制的Linux内核，与Windows进行交互。我相信这个定制的Windows Linux内核是在虚拟机中运行的。 - Jordan Stewart

是的。刚刚发布了一条更新，以更好地反映我们的WSL2现实 :) - Rich Turner

我不确定这个回答了主要问题：在WSL2上运行Linux与通过Docker运行Linux有什么区别？ - a06e

Answer 2

我了解目前有两种不同的方法在Windows 10上运行Ubuntu。那么，它们之间有什么区别（特别是应用程序方面），以及各自的优缺点呢？

在提问时，实际上有三种方法可以在Windows 10上运行Ubuntu：

- WSL上的Ubuntu（当时版本为1） - 使用带有Hyper-V后端的Docker Desktop中的Docker容器 - 虚拟机中的Ubuntu

目前，又新增了两个选项：

- WSL2上的Ubuntu - 使用带有WSL2后端的Docker Desktop中的Docker容器

这五个选项目前都可行，并且在某些情况下仍然非常有用。所有这些选项都允许未经修改的ELF64二进制文件在Ubuntu生态系统中运行。

使用WSL2后端的Docker Desktop中的Ubuntu：

最适合以下场景： - 基于Ubuntu构建/开发Docker容器（或任何其他基础镜像，但此问题特别涉及Ubuntu）。 - 需要或最适合在Ubuntu上运行的作为容器分发的单一用途工具。

弱点：

• 几乎任何其他事情。这并不是一件坏事 - Docker是一个很棒的容器化工具，但容器并不意味着以一般意义上的“运行Ubuntu”。

  首先（也可能是最重要的），容器是在叠加文件系统中构建起来的，每次进行更改时都会添加一层。因此，每次sudo apt update && sudo apt upgrade都会在旧版本之上生成一个全新的层。这将是一种非常浪费资源的方式来运行“通用使用”的系统。

  通常情况下，每次需要对底层系统进行更改时，都会重新构建容器。

  此外，当您在Windows上运行Docker桌面时，几乎总是会使用WSL2后端。在这种情况下，直接在WSL2上使用Ubuntu效率更高。

摘要：

• 使用WSL2后端的Docker桌面工具是使用Docker构建容器的绝佳工具。
• 它将WSL2子系统的低资源利用率与创建可重现、快速启动的Ubuntu（或其他）容器的能力相结合。
• 不建议在Windows（或任何其他地方）下运行通用Ubuntu系统。

WSL2上的Ubuntu

最适合：

• 开发任务，包括GPU计算
• 命令行Linux工具和shell
• 系统管理任务，如ssh客户端、Ansible、AWS/Azure/Google Cloud管理等。
• 通过WSL互操作混合和匹配Windows和Linux工具。

弱点：

• 如果您需要频繁访问无法移动到Ubuntu/WSL2文件系统的Windows驱动器上的文件，因为WSL2在访问Windows文件时速度较慢。
• 您需要访问物理硬件。
• 您正在使用的应用程序（或您正在遵循的指示）使用Systemd，在WSL（1或2）中不容易支持。
• 您需要从其他设备/计算机访问在Ubuntu中运行的服务。例如，在WSL2中运行Web服务器将需要设置某种类型的端口转发才能访问该服务。
• 您需要访问桌面环境（Gnome、Xfce4等）。

摘要：

• 在WSL2虚拟机下运行一种“容器”
• WSL2虚拟机运行由Microsoft提供的真实Linux内核
• 内核是开源的
• 您可以从源代码构建自己的内核
• 主要是一个以命令行为主的环境
• 在Windows 11上，支持开箱即用的图形化Linux应用程序
• 在Windows 10上，可以通过额外的配置运行图形化Linux应用程序
• 启动速度快，资源使用率低
• 附注：可以直接在WSL2上的Ubuntu上运行Docker Engine，但推荐的方式仍然是使用Docker Desktop。

虚拟机中的Ubuntu

最适合：

• 模拟具有自己的网络堆栈、虚拟硬件、控制台等的“真实”计算机
• 需要或通过Systemd简化的服务或任务
• 运行完整的桌面环境，特别是Gnome，因为它大量使用Systemd。
• 学习工具，如Grub、磁盘分区、网络和其他与真实或虚拟硬件更好配合的工具。

弱点：

• 你需要与Windows工具（如PowerShell）进行集成。
• 你希望从Windows内部快速访问Ubuntu。WSL的快速启动和资源利用率较低，更适合快速启动Ubuntu环境。

总结：

• 在虚拟机中运行是在Windows上运行Ubuntu的几十年来的方法，早于这里介绍的所有其他方法。
• 它提供了虚拟硬件，使得Ubuntu在几乎所有情况下都能按预期运行。
• 有趣的一点是：实际上，你可以在WSL2中运行诸如QEMU/KVM之类的虚拟机中运行Ubuntu，只要你的系统支持嵌套虚拟化，并且性能相对较好。

在WSL1上的Ubuntu

最适合：

• 没有支持虚拟化的CPU的系统 - WSL1仍然可以提供以本机ELF64二进制文件运行的Ubuntu发行版，性能相对合理，无需虚拟化支持。
• 访问Windows驱动器上的文件。对于此项任务，性能大约比WSL2快10倍。
• 需要对Windows驱动器上的文件进行inotify支持的任务，因为WSL2目前不支持此功能。

弱点：

• 你运行的应用程序需要“较少使用”的内核功能。由于内核系统调用被“翻译”为Windows API，因此并不支持所有功能。WSL1不支持Cgroups、命名空间和其他功能（但在WSL2和所有其他方法中都支持）。

• 你使用的应用程序（或遵循的指南）使用Systemd，在WSL（1或2）中不容易支持。

• 你需要访问桌面环境（Gnome、Xfce4等）。

总结：

• WSL1提供了与Windows相似的紧密集成水平，对于某些任务仍然是首选。
• 虽然它作为“翻译层”运行（有点像“反向Wine”），但兼容性水平仍然相当高——它支持约85%的系统调用，涵盖了约98%的常见开发工具。
• 由于它不支持用于容器化的Cgroups、命名空间和其他内核功能，Docker将无法直接在WSL1上运行。

使用Hyper-V后端在Docker Desktop中的Ubuntu

最适合：

• 在极少数只能运行Hyper-V而无法运行WSL2的系统上开发使用Ubuntu的Docker容器。这种情况非常罕见。

不太适合：

• 任何其他场景。我真的不知道有人会在除了某些原因导致WSL2无法工作时，使用这种情况进行Docker测试以外的其他用途。

- NotTheDr01ds

---

这个回答对于@RichTurner提供的更技术性的概述增添了很多价值，涉及到了优点、缺点和应用场景。在理想的情况下，这两个回答可以合并成一个被接受的回答。 - undefined

Answer 3

没错。你没有提到的一件事是，即使使用快速的SSD/大量内存/8核鲲处理器，WSL在io方面仍然相当慢。这个问题在2019年1月依然存在。我刚刚在我的工作站上进行了测试，使用了三星的SSD，只获得了97.6MB/s的速度。

如果直接在裸机上运行Ubuntu LTS，这台电脑将会达到几倍的速度。别提当你尝试将WSL与VSCODE结合使用时遇到的无尽问题了。

我要把Windows 10从这里擦掉，安装Ubuntu 18.04LTS。

- mangoTango

---

你不需要有毒，尤其是在最后。相反，请告诉我们你为了研究你所面临的问题的原因做了什么努力，以及这些问题是否已知，并且是否有人正在修复它们。虽然我相信他们正在处理。你不需要卸载Windows，只需安装Hyper-V管理器和快速安装Ubuntu，你就可以在虚拟Linux桌面内工作了，从而获得一个Linux开发环境。否则，继续使用WSL并等待问题解决。97 MB/s并不慢。 - Paul-Sebastian Manole

据我所知，速度问题与Windows文件访问子系统有关，目前正在进行一种解决方法。 - Paul-Sebastian Manole

WSL看起来还是有点慢。但它的启动速度非常快，可以使用常见的Linux命令行工具。映射Linux和Windows文件系统似乎有些复杂。 - Jordan Stewart

速度明显变快了。但是我尝试使用Miniconda并安装软件包，速度还是有点慢。 - mangoTango

Answer 4

WSL的一个最大问题是IO，特别是在挂载不同文件系统时。例如，将文件放在Windows中并通过Docker Compose进行映射会非常慢。使用WSL + Docker的另一种方式是将文件移动到该机器上并进行远程连接，就像Visual Studio Code使用Remote-WSL插件一样（https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-wsl）。这样，您可以摆脱不必要的挂载点带来的额外开销，实际上，它们只是网络共享。

- GabrielO

---

你是不是想在另一个WSL问题上回答？这看起来与这个特定问题没有任何关系。这个问题不是在寻找一个“解决方案”，而是要求对各种选项进行“解释”。 - NotTheDr01ds

关于主要请求的最后一段（“所以我将感激任何关于这两个问题的信息。”），我试图提出另一种实现相同目标但副作用较少的方法。换句话说，我正在扩大调查范围，并提供一个经过测试的解决方案的额外好处。刚刚编辑了答案以使其更清晰。谢谢！ - GabrielO

好的 - 谢谢你的解释！ - NotTheDr01ds

@NotTheDr01ds - 你介意取消那个踩的评价吗？谢谢。 - GabrielO

我从来没有给它点过踩。对于一个我觉得不合适的回答，尤其是针对一个新用户，我是不会点踩的。我猜可能是有人在“首次回答”审核队列中进行了评审。你知道吗，我会给你一个“欢迎来到AU”的赞，虽然在问题上显示为“0”分（直到你有足够的声望来查看赞和踩），但你会注意到你的声望现在应该是9（我猜的）——原本是“1”，然后加上我给的+10赞，再减去（我想是）-2的踩。 - NotTheDr01ds

谢谢，非常感激。 :) - GabrielO