Docker 桌面 - 关于性能不佳的文件共享通知

Gre*_*sey 55 docker docker-desktop

当我的 Docker 容器启动时,我收到以下通知:

Docker Desktop 检测到您将 Windows 文件共享到 WSL 2 容器中,该容器可能性能不佳。点击这里了解更多详情。

在此处输入图片说明

我的问题是:

  1. 这是什么意思?
  2. 什么是更好的做法/应该如何避免这种情况?
  3. 如果消息已关闭,或者我单击了“不再显示”,我如何才能获得此警告的详细信息?

如果需要,我很高兴分享 Dockerfile 或 Docker-Compose 设置,但我在 SO 上或通过 Google 搜索都找不到任何指向我任何方向的内容,所以我不确定从哪里开始。我假设问题出在 Dockerfile 中,因为这是我们运行COPY以移动一些文件的地方。

Docker 版本:Docker 桌面 2.4.0.0 (48506) 社区

操作系统:Windows 10 专业版(版本 10.0.19041)

Bil*_*ees 41

  1. 此错误意味着从 Linux 容器访问 Windows 主机文件系统上的文件将比访问 Linux 文件系统中已有的文件执行得慢一点。从 Linux 容器访问 Windows 文件就像访问远程文件共享上的文件一样。

  2. Docker 和 Microsoft 建议通过将源文件存储在 WSL2 发行版的文件系统(您可以将挂载绑定到容器)或构建容器映像以包含所有需要的文件而不是将文件存储在 Windows 文件系统中来避免这种情况。

  3. 如果您单击了“不再显示”,则可以通过使用 Docker 和 WSL 2进行开发来获取此消息的详细信息。

有关更多信息,Docker for Windows Best Practices说:

  • 如果原始文件存储在 Linux 文件系统中,Linux 容器只会接收文件更改事件(“inotify 事件”)。例如,某些 Web 开发工作流依赖 inotify 事件在文件更改时自动重新加载。
  • 当文件从 Linux 文件系统绑定挂载而不是从 Windows 主机远程安装时,性能要高得多。因此避免docker run -v /mnt/c/users:/users(从 Windows 挂载 /mnt/c 的地方)。
  • 相反,从 Linux shell 使用类似命令docker run -v ~/my-project:/sources <my-image>,其中 ~ 被 Linux shell 扩展为 $HOME。

Microsoft 的比较 WSL 1 和 WSL 2文章有一整节关于跨操作系统文件系统的性能,其开头段落说:

我们建议不要跨操作系统处理您的文件,除非您有特定的理由这样做。如果您在 Linux 命令行(Ubuntu、OpenSUSE 等)中工作,为了获得最快的性能速度,请将您的文件存储在 WSL 文件系统中。如果您在 Windows 命令行(PowerShell、命令提示符)中工作,请将文件存储在 Windows 文件系统中。

此外,Docker 博客文章Docker 桌面:WSL 2 最佳实践有一个“很棒的挂载性能”部分说:

您自己的 WSL 2 发行版和 docker-desktop 都在同一个实用程序 VM 上运行。它们共享相同的内核、VFS 缓存等。它们只是在不同的命名空间中运行,因此它们有完全独立运行的错觉。Docker Desktop 利用它来处理来自 WSL 2 发行版的绑定挂载,而无需涉及任何远程文件共享系统。这意味着当您将项目文件挂载到容器中时(使用docker run -v ~/my-project:/sources <...>),docker 将传播 inotify 事件并与您自己的发行版共享相同的缓存,以避免重复从磁盘读取文件内容。

不过有一点警告:如果您挂载存在于 Windows 文件系统中的文件(例如使用docker run -v /mnt/c/Users/Simon/windows-project:/sources <...>),您将无法获得这些性能优势,因为 /mnt/c 实际上是一个通过 Plan9 文件共享公开 Windows 文件的挂载点。

如果您希望您的主要开发工作流程在 Linux 中运行,那么所有这些建议都很棒。Docker 希望您“全力以赴”使用 Linux 容器。但是,如果您主要在 Windows 中工作并且只想将 Linux 容器用于特定任务,那么单击“不再显示”就可以了。正如微软所说,“如果您在 Windows 命令行中工作,请将您的文件存储在 Windows 文件系统中。”

我在 Windows 中使用我的主要开发文件夹运行,并将它绑定到一个 Linux 容器,该容器仅用于执行单元测试。所以我的完整构建在 Windows 中运行,然后我在 Windows 中运行我的所有单元测试,最后我也在 Linux 容器中运行我的所有单元测试。将 Linux 绑定挂载到我的 Windows 文件夹可以快速且非常适合这种情况,即 Linux 中的“dotnet test”调用只是从我的 Windows 卷加载和执行所需的 DLL。

对于那些认为必须在任何地方使用容器的人来说,这种设置听起来像是异端邪说,但我喜欢用于应用程序部署的容器。我不相信您也需要全力以赴并在容器内进行所有开发。我对 Windows(和 VS 2019)作为我的开发环境感到满意,然后我使用 Linux 容器进行应用程序测试和部署。因此,Windows/WSL2 文件系统性能对我的影响很小。