适用于 Linux 的 Docker Desktop 常见问题解答

为什么 Docker Desktop for Linux 运行虚拟机？

Docker Desktop for Linux 运行虚拟机 (VM) 的原因如下：

1. 确保 Docker Desktop 提供跨平台一致的体验。

   在研究过程中，用户想要 Linux 版 Docker Desktop 最常提到的原因是确保在所有主要操作系统上具有一致的 Docker Desktop 体验和功能平等。使用 VM 可确保 Linux 用户的 Docker 桌面体验与 Windows 和 macOS 的体验非常匹配。

2. 利用新的内核功能。

   有时我们想利用新的操作系统功能。因为我们控制虚拟机内的内核和操作系统，所以我们可以立即将它们推广给所有用户，甚至是那些有意坚持使用 LTS 版本机器操作系统的用户。

3. 以增强安全性。

   容器镜像漏洞给宿主机环境带来安全风险。有大量非官方镜像无法保证能够验证已知漏洞。恶意用户可以将映像推送到公共注册表，并使用不同的方法诱骗用户拉取并运行它们。 VM 方法减轻了这种威胁，因为任何获得 root 权限的恶意软件都被限制在 VM 环境中，而无法访问主机。

   为什么不运行无根 Docker？虽然这样做的好处是表面上限制了对 root 用户的访问，因此“top”中的一切看起来都更安全，但它允许非特权用户获得CAP_SYS_ADMIN自己的用户命名空间并访问不希望被非特权用户使用的内核 API，从而导致 漏洞。

4. 提供功能平等和增强安全性的优势，同时对性能的影响最小。

   Docker Desktop for Linux 使用的虚拟机使用 VirtioFS共享文件系统，允许虚拟机访问位于主机上的目录树。我们的内部基准测试表明，通过为虚拟机分配正确的资源，VirtioFS 可以实现接近本机文件系统的性能。

   因此，我们调整了 Docker Desktop for Linux 中虚拟机可用的默认内存。您可以使用Docker Desktop 的“设置” > “资源”选项卡中的“内存”滑块来调整此设置以满足您的特定需求。

如何启用文件共享？

Docker Desktop for Linux 使用 VirtioFS作为默认（也是当前唯一）机制来启用主机和 Docker Desktop VM 之间的文件共享。为了不需要提升权限，同时又不会不必要地限制对共享文件的操作，Docker Desktop在配置了 UID 和 GID 映射的virtiofsd用户命名空间（请参阅 参考资料）内运行文件共享服务 ( ) 。user_namespaces(7)因此，Docker Desktop 依赖于配置的主机来使当前用户能够使用从属 ID 委派。为此，必须存在/etc/subuid(参见subuid(5)) 和/etc/subgid(参见)。 subgid(5)Docker Desktop 仅支持通过文件配置的从属 ID 委派。 Docker Desktop 将容器中的当前用户 ID 和 GID 映射为 0。它使用/etc/subuid和中当前用户对应的第一个条目来/etc/subgid为容器中大于 0 的 ID 设置映射。

如果/etc/subuid和/etc/subgid缺失，则需要创建它们。两者都应包含 - 形式的条目 <username>:<start of id range>:<id range size>。例如，允许当前用户使用 100 000 到 165 535 之间的 ID：

$ grep "$USER" /etc/subuid >> /dev/null 2&>1 || (echo "$USER:100000:65536" | sudo tee -a /etc/subuid)
$ grep "$USER" /etc/subgid >> /dev/null 2&>1 || (echo "$USER:100000:65536" | sudo tee -a /etc/subgid)

要验证配置是否已正确创建，请检查其内容：

$ echo $USER
exampleuser
$ cat /etc/subuid
exampleuser:100000:65536
$ cat /etc/subgid
exampleuser:100000:65536

在这种情况下，如果在 UID 为 1000 的用户所拥有的 Docker Desktop 容器内编辑共享文件chown，则该文件在主机上显示为 UID 为 100999 的用户所拥有。访问主机上的此类文件。通过使用新的 GID 创建一个组并向其中添加我们的用户，或者为setfacl(1)与 Docker Desktop VM 共享的文件夹设置递归 ACL（请参阅 参考资料），可以解决该问题。

Docker Desktop 在哪里存储 Linux 容器？

Docker Desktop 将 Linux 容器和映像存储在 Linux 文件系统中的单个大型“磁盘映像”文件中。这与 Linux 上的 Docker 不同，后者通常将容器和镜像存储在/var/lib/docker主机文件系统的目录中。

磁盘镜像文件在哪里？

要找到磁盘映像文件，请从 Docker 仪表板中选择设置，然后从资源选项卡中选择高级。

“高级”选项卡显示磁盘映像的位置。它还显示磁盘映像的最大大小以及磁盘映像消耗的实际空间。请注意，其他工具可能会根据最大文件大小而不是实际文件大小来显示文件的空间使用情况。

如果文件太大怎么办？

如果磁盘镜像文件太大，您可以：

• 将其移动到更大的驱动器
• 删除不需要的容器和镜像
• 减小文件的最大允许大小

如何将文件移动到更大的驱动器？

要将磁盘映像文件移动到其他位置：

1. 从“资源”选项卡中选择“设置”，然后选择“高级”。

2. 在“磁盘映像位置”部分中，选择“浏览”并为磁盘映像选择一个新位置。

3. 选择“应用并重新启动”以使更改生效。

不要直接在 Finder 中移动文件，因为这可能会导致 Docker Desktop 丢失文件的跟踪。

如何删除不需要的容器和镜像？

检查是否有不需要的容器和镜像。如果您的客户端和守护进程 API 运行的是 1.25 或更高版本（使用docker version客户端上的命令检查您的客户端和守护进程 API 版本），您可以通过运行以下命令查看详细的空间使用信息：

$ docker system df -v

或者，要列出图像，请运行：

$ docker image ls

要列出容器，请运行：

$ docker container ls -a

如果存在大量冗余对象，请运行命令：

$ docker system prune

此命令将删除所有已停止的容器、未使用的网络、悬空图像和构建缓存。

根据磁盘映像文件的格式，回收主机上的空间可能需要几分钟的时间：

• 如果文件名为Docker.raw： 主机上的空间应在几秒钟内回收。
• 如果文件被命名为Docker.qcow2：几分钟后，后台进程将释放空间。

仅当删除图像时才会释放空间。当正在运行的容器内删除文件时，不会自动释放空间。要随时触发空间回收，请运行以下命令：

$ docker run --privileged --pid=host docker/desktop-reclaim-space

请注意，许多工具报告最大文件大小，而不是实际文件大小。要从终端查询主机上文件的实际大小，请运行：

$ cd ~/.docker/desktop/vms/0/data
$ ls -klsh Docker.raw
2333548 -rw-r--r--@ 1 username  staff    64G Dec 13 17:42 Docker.raw

本例中，磁盘的实际大小为2333548KB，磁盘的最大大小为64GB。

如何减小文件的最大大小？

要减小磁盘映像文件的最大大小：

1. 从 Docker 仪表板中选择“设置”，然后从“资源”选项卡中选择“高级”。

2. 磁盘映像大小部分包含一个滑块，可让您更改磁盘映像的最大大小。调整滑块以设置下限。

3. 选择应用并重新启动。

当您减小最大大小时，当前磁盘映像文件将被删除，因此所有容器和映像都会丢失。