适用于 Linux 的 Docker Desktop 的常见问题解答
为什么适用于 Linux 的 Docker Desktop 运行 VM?
适用于 Linux 的 Docker Desktop 运行虚拟机 (VM) 的原因如下:
确保 Docker Desktop 跨平台提供一致的体验。
在研究过程中,用户希望使用 Docker Desktop for Linux 最常被引用的原因是为了确保 Docker Desktop 的一致性 在所有主要操作系统中实现功能对等的经验。利用 VM 可确保 Linux 用户的 Docker Desktop 体验紧密相连 与 Windows 和 macOS 的匹配。
利用新的内核功能。
有时我们想利用新的操作系统功能。由于我们控制着 VM 内部的内核和操作系统,因此我们可以立即向所有用户推出这些内容,即使是有意坚持使用机器操作系统的 LTS 版本的用户。
增强安全性。
容器镜像漏洞会给主机环境带来安全风险。有大量非官方镜像无法保证针对已知漏洞进行验证。恶意用户可以将镜像推送到公共注册表,并使用不同的方法诱骗用户拉取和运行它们。VM 方法可以缓解这种威胁,因为任何获得 root 权限的恶意软件都仅限于 VM 环境,无法访问主机。
为什么不运行无根 Docker?虽然这样做的好处是表面上限制了对 root 用户的访问,因此在 “top” 中一切看起来都更安全,但它允许非特权用户获得他们自己的用户命名空间并访问不希望被非特权用户使用的内核 API,从而导致漏洞。
CAP_SYS_ADMIN
提供功能奇偶校验和增强安全性的优势,同时对性能的影响最小。
Docker Desktop for Linux 使用的 VM 使用
VirtioFS,
这是一种共享文件系统,允许虚拟机访问位于主机上的目录树。我们的内部基准测试表明,通过为 VM 分配正确的资源,使用 VirtioFS 可以实现接近原生的文件系统性能。因此,我们调整了适用于 Linux 的 Docker Desktop 中 VM 可用的默认内存。您可以使用 Docker Desktop 的 Settings > Resources (设置资源) 选项卡中的 Memory (内存) 滑块来调整此设置。
如何启用文件共享?
适用于 Linux 的 Docker Desktop 使用 VirtioFS 作为 默认(也是目前唯一)机制,用于在主机之间启用文件共享 和 Docker Desktop VM 的 Docker Desktop VM 中。
为了不需要提升的权限,如果没有
不必要地限制对共享文件的操作,Docker Desktop 运行
用户命名空间(请参阅 )中的文件共享服务 () 配置了 UID 和 GID 映射。因此,Docker
Desktop 依赖于主机配置为使当前用户能够使用
从属 ID 委派。要做到这一点(请参阅 )
和 (请参阅 ) 必须存在。仅限 Docker Desktop
支持通过文件配置的从属 ID 委托。Docker Desktop 将
当前用户 ID 和 GID 设置为 0。它使用第一个条目
对应当前用户 in 和 to set
容器中 ID 大于 0 的映射。virtiofsd
user_namespaces(7)
/etc/subuid
subuid(5)
/etc/subgid
subgid(5)
/etc/subuid
/etc/subgid
容器中的 ID | 主机上的 ID |
---|---|
0 (根) | 运行 DD 的用户的 ID(例如 1000) |
1 | 0 + / 中指定的 ID 范围的开头(例如 100000)/etc/subuid /etc/subgid |
2 | 1 + / 中指定的 ID 范围的开头(例如 100001)/etc/subuid /etc/subgid |
3 | 2 + / 中指定的 ID 范围的开头(例如 100002)/etc/subuid /etc/subgid |
... | ... |
如果 和 缺失,则需要创建它们。
两者都应包含格式为 - 的条目。例如,要允许当前用户
要使用 100 000 到 165 535 的 ID:/etc/subuid
/etc/subgid
<username>:<start of id range>:<id range size>
$ 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
在这种情况下,如果共享文件位于 Docker Desktop 容器内
由 UID 为 1000 的用户拥有,则它在主机上显示为拥有
UID 为 100999 的用户。这有一个不幸的副作用,即防止
在主机上轻松访问此类文件。通过创建
一个具有新 GID 的组并将我们的用户添加到该组,或者通过设置递归
ACL(请参阅 ),用于与 Docker Desktop VM 共享的文件夹。chown
setfacl(1)
Docker Desktop 将 Linux 容器存储在何处?
Docker Desktop 将 Linux 容器和镜像存储在 Linux 文件系统中的单个大型“磁盘镜像”文件中。这与 Linux 上的 Docker 不同,后者通常将容器和镜像存储在主机文件系统上的目录中。/var/lib/docker
磁盘镜像文件在哪里?
要查找磁盘镜像文件,请从 Docker Desktop 控制面板中选择 设置,然后从 Resources 选项卡中选择 Advanced。
Advanced (高级) 选项卡显示磁盘镜像的位置。它还显示磁盘镜像的最大大小和磁盘镜像占用的实际空间。请注意,其他工具可能会根据最大文件大小而不是实际文件大小来显示文件的空间使用情况。
如果文件太大怎么办?
如果磁盘镜像文件太大,您可以:
- 将其移动到更大的驱动器
- 删除不必要的容器和镜像
- 减小文件允许的最大大小
如何将文件移动到更大的驱动器?
要将磁盘镜像文件移动到其他位置:
选择 设置 ,然后从 资源 选项卡中选择 高级。
在 Disk image location(磁盘镜像位置)部分中,选择 Browse(浏览)并为磁盘镜像选择新位置。
选择应用并重新启动以使更改生效。
请勿直接在 Finder 中移动文件,因为这可能会导致 Docker Desktop 丢失对文件的跟踪。
如何删除不必要的容器和镜像?
检查是否有不必要的容器和镜像。如果您的客户端和守护程序 API 运行的是 1.25 或更高版本(使用客户端上的命令检查您的客户端和守护程序 API 版本),您可以通过运行以下命令来查看详细的空间使用信息:docker version
$ 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
在此示例中,磁盘的实际大小为 KB,而磁盘的最大大小为 GB。2333548
64
如何减小文件的最大大小?
要减小磁盘镜像文件的最大大小:
在 Docker Desktop 控制面板中,选择 设置 ,然后从 资源 选项卡中选择 高级 。
Disk image size (磁盘镜像大小) 部分包含一个滑块,允许您更改磁盘镜像的最大大小。调整滑块以设置下限。
选择应用并重新启动。
减小最大大小时,当前磁盘镜像文件将被删除,因此,所有容器和镜像都将丢失。